I am writing a library which contains a domain model and uses the Bean Validation API. My goal is to have minimal amount of dependencies. Hence, without CDI, Java EE and Spring. Allowed Dependencies are to APIs only like JSR-349 and JSR-330 API.
I can not make any assumptions about how my library is going to be used. It might be within a container or as desktop application. Forcing the library user to have an CDI, Spring, or validation implementation is not an option.
Right now, I use the bean validation API to allow the user of my library to validate the model itself. But I would also like to use Method Validation in some cases.
My questions are:
What options do I have if I want to use method validation within a
library project?
Do I have to ship my library with an aspectj runtime dependency?
Does it make sense to use Method Validation in a domain model?
How is your library going to be used? Chances are that applications using it are running within CDI, Spring or another kind of container anyways, then delegating method validation to the same would be sensible.
If you really want to go for your own solution, it really depends on how the instances of your domain model are created. If you have interfaces and the user obtains instances via a factory, you might have a look at JDK dynamic proxies. Alternatively, you could check out Javassist or Cglib if you don't work with interfaces but with classes. That'd still require that your domain model nodes are obtained via a factory in order to return properly proxied instances.
Whether it makes sense or not surely depends on your specific model and its use cases. When it comes to validation of a model, property (and class-level) validation surely is the more common case, but if you provide business methods on your model and want to validate their parameters or return values, it may make sense.
1) without CDI I would recommend apache BVal or any jsr303 specific implementation that does not require being container managed.
Since the jsr targets the java-ee platform it seems some container must manage it. what container you choose depends on the extra dependencies that must be shipped with the application.
Bval itself does not require anything other some core apache helper libraries.
2) Bval and other implementations of the jsr303 spec will need some kind of java ee container. It is a backing principle behind java ee. If no java-ee enviroment is present, bval will require a di framework to hook into.
If guice is chosen as the container; it uses cglib for its bytecode and it uses aop alliance interfaces for its aop (implemented internally with the help of cglib).
Spring does require aspectj.
If CDI is chosen, it would depend on the CDI implementation used.
3) If you are attempting to simply do method level validation, it does make sense to simply do the validation by hand in the class setter/getter itself. Specially if you want to remain platform independant.
Method level validation through the use of third party libraries only makes sense when you are using third party containers. If you are trying to have a base simple java se application, it does make a great deal of sense to put the validation in the data objects themselves and have your exception handling strategy take care of issues to the user.
The answer to three will always be rather subjective, but if you really are not looking to use a mass amount of frameworks, I don't think its bad practice to do the validation in the methods themselves.
Related
What is the correct way to get a service, hopefully using Declarative Service if possible, when you don't know the attributes of the service to request until after runtime?
The use case is analogous to having 3 bundles providing services version 1.0, 2.0 and 3.0 but not knowing which one will be consumed until the user chooses one in the UI. If the user chooses 2.0 the consumer will consume the stuff from bundle 2.0
We are using BND annotations, so something with them would be ideal, but i have a feeling that we need to use the OSGi API directly instead of using annotations or declarative services injection.
Finally, if it is relevant, this is more to get different versions of a resource (XML schema) rather than about different behaviour/implementations. The idea was that the service would be providing its internal resource, which would be different in each version, even though the code in the service itself would be the same
I've worked in a similar system before and we had our own "routing" system. Basically when you register the services add the version number in the meta-data. Then in this routing mechanism pick the correct service. Your services will need to implement a common interface and in the router inject a List of them.
The declarative model of the Declarative Services specification is a build-time model, not a run-time one. To do run-time dependency management, you either need to do it yourself with a ServiceTracker, or use a different dependency management solution.
As one of its authors, I have a preference for the Apache Felix Dependency manager [1] which allows you to "declare" dependencies in Java code (at run-time, for example based on a choice made by a user in the UI like you say).It does not use Bnd annotations, but the code still allows you to use a declarative style and provides features like injection and/or callbacks.
Another solution that allows this is Apache Felix iPOJO [2].
[1] http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager.html
[2] http://felix.apache.org/documentation/subprojects/apache-felix-ipojo.html
Spring Framework provides a wonderful abstraction layer for low-level resource access in Java (the Resource and ResourceLoader interfaces). I'm developing a library which should not be dependent on Spring, and am looking for an equivalent for this capability in a stand-alone Java library. Anyone familiar with one?
Why not just use the one from Spring by itself? It doesn't look like it has any dependencies on the rest of Spring.
Edit
Not sure I understand the problem - you want something that does exactly the same thing, but doesn't come from Spring? Is it a licensing issue?
You only need half a dozen classes from it, if you don't want to add them as an extra jar, move them to your own namespace (good idea anyway, in case you do use Spring at some point, after all) and distribute with your library. Again, assuming your licensing allows it.
If licensing isn't the problem, can you be more specific about why you can't use the Spring implementation in your own library?
You can use Jsr-303 (DI) to match your requirments. The most known implementation is Google Guice. It's a javaEE standard (maybe JavaSE).
we have a frontend application that that uses Swing. We use Spring framework, but currently it is used just to autowire few beans...
What are reasonable next steps to use Spring more often?
Is it worth for non web application?
What would be advantages and disadvantages?
The advantages of using Spring (or any other dependency-injection) framework, is that you get a (hopefully) loosely coupled system, i.e you classes does not create instances of their collaborators, so you can easily change the implementation.
This is widely known as the Inversion-of-control principle (IoC, also the I in SOLID), and this is a good principle to follow. This means that spring is not limited to web applications, but can be used in any application that want to use an IoC-container (which is basically what spring-core is).
Disadvantages:
This really depends on how you look at things. There is more code (you have to define a entry-point for the injected collaborators), but that also makes the code more testable (the entry-points are seams which you can use to inject mocks and stubs in testing).
Also, you can't look at the code and immediately see which implementation of the collaborators that are used. But that also makes for good code, since you depend on interfaces, not implementations.
You get more config: either in an xml-file (old-style spring), or with annotations. Up until recently you had to rely on non-standard spring annotations to inject (#Autowired) resources, but now you can use the standard java dependency injection annotations, which means that you can switch out spring as your IoC-container without changing your code.
There are probably alot more advantages and disadvantages to using spring in your application, but this should get you started on deciding if using Dependency Inversion is a good thing for your application
More to the point of your question about Swing and Spring. In an application I have been working on we have been using spring to wire up the whole application. The different dialogs get their logic injected (no application logic should (in my opinion) be located together with gui logic). We are using JPA/hibernate as the database-layer, so we use spring spring to create and inject the entitymanager to our DAOs, and set up transactional settings.
I've written swing UI's that are backed by spring.
cons
the startup can be slower but you have to have a large app for that to happen.
and a splashscreen is a good idea in those situations.
its easy to "overbean" or over-zealously make everything a bean, which gets messy.
pros
spring works fine behind a GUI.
it provides a lot of services you can use
the obvious dependency injection and decoupling
a global event system, simpifying some of your own event listeners, for events that will only ever be fired by one source
resource accessing
database access is eays in 2 tier apps
rpc for 3 tier apps is easy
There are other services the spring application context provides, but that I haven't used.
If you go this direction, also look into the java-based configuration for spring, which is new in 3.0. I find that helpful as well, as it makes my spring configuration type-safe.
One disadvantage of using Spring in a Swing application is that Spring DI will make startup slower.
well one would be , if you ever decide to migrate to a web app , all you need ( well almost) to change would be the views. That's the beauty of MVC applications.
For instance, I am using JSF + custom framework developed in our company. Now I want to use a third party validation framework that can be used as an plug-in and it should not create any dependency what ever may be the technical stack.
So my question is does spring provide any framework of that sort or if it's available how can I use that?
I am expecting a validation framework something like, which is configurable through XML.
Spring does have a validation framework, but if you want minimal dependencies, then I'd suggest that you go with a Bean validation provider. It's a new(ish) official validation standard, defined in JSR-303.
There are several implementations at the moment. I'd give Hibernate Validator a look.
I disagree. Hibernate Validator is an awful piece of software (at least the versions that were current about a year ago). Spring Validation is a nice piece of software, that goes together well with the BeanWrapper interface.
But it's true: Spring Hibernate resides inside the Spring Context jar, which is unnecessary overhead. Hopefully there will be a separate version sometime.
I started experimenting with Spring Roo just recently. It does a very nice job helping one build a domain model with integrated persistence rather quickly. As it adds persistence functionality in aspects, I started think about the following question:
Roo adds finders (load an instance of a class from the database which meets variable criteria) in an aspect to the actual class/entity. In DDD this is IMHO the responsibility of repositories. Repositories are explicit classes which show up in the design. Of course as an aspect the repository functionality is hidden in an entity and is pretty much invisible.
So here is the question: Is an aspect a real substitute for a explicit repository class? Are there any downsides to the Roo AOP approach?
Adding finders to your domain classes feels more natural from a user's point of view but it mingles your layers. Grails uses the same approach by adding static finder*() save(), ... methods.
Apart from the aestetics it might have practical drawbacks when not used in web application setting:
Your domain classes are now tied to your database. If you transfer these objects to rich clients via RMI or HttpInvoker the client cannot and often may not use the find* methods because there is no session / database connection available on the client.
I generally prefer allowing domain classes to reference service layer interfaces to prevent an anemic domain model (http://martinfowler.com/bliki/AnemicDomainModel.html). This has its own set of drawbacks but at least provides a clear boundary. On the client the concrete implementation behind a service interface can then just proxy all method calls to the server (or just use a synamic proxy with spring remoting or sth similar).
So to answer your question: It might be a substitute but you should be aware of the possible negative consequences which make your domain classes (i.e. your core business logic) less portable between systems.
This depends on how complicated your applications persistence layer is and how much control you have over it. If your application is simple enough to be implemented via JPA, then it all could be handled via Roo aspects. However if you are mapping legacy tables or need advanced DB stuff, then you may find yourself in a situation where Spring-JDBC is the only way out and in these cases a repository/dao model may still be useful.
I consider it logical inconsistent (and a break of layer responsibility) to be mixing two persistence models and so as most of my applications requires such advanced DB constructs I stick strictly with a repository model.
I think adding repository methods to domain objects is bad design. The right place would be static methods in the domain class. But domain objects and their management are two different things that should be separated. I would prefer domain objects and repositories.
I guess the motivation was to achieve something Rails/Grails like with Java.