I am making a web service with Java EE 6. From what I understand you can annotate either the local interface with the #Path/#GET etc. annotations or the no-interface bean. I wonder if it is common to make two interfaces; one for the web services with the annotations and another one for the local interface? Or do you just add them on the local interface?
If I understand your question, your asking if you should define an interface just for specifying the annotations. I'm not sure what the advantages would be of doing this, unless you had a really complex project and foresee yourself replacing the Web service annotations with another library. This library would have to be on its virtual deathbed in terms of future support, or there would need to be clear evidence that our CTO would be changing technologies for me to consider this strategy.
For most projects, this seems to be somewhat of an overkill, especially if you already have an interface defined for your controller that you can add those annotations to. As a colleague on your project, I wouldn't want to have to check 3 different files for annotations for 1 class, unless there was a very compelling reason to do so.
With that said, if you wanted to add the annotations to your interface or your subclass, this is supported in this example. However, I think you would want to be sure to create a clear standard, either all your REST annotations are on the interface or all of your annotations are on the subclass. Mixing and matching them could get confusing for someone new to the project.
Without actually seeing your code and how complex it is, I can't tell you which method would be best for your project. The important thing is to balance consistency with flexibility. In summary, Java gives you plenty of rope, which equals flexibility, but you can also hang yourself with that rope if you're not careful. :)
Related
I have DAO interface and DAOImpl class on my Spring boot REST API project. But some of my teammates were telling me that it is not necessary to have an interface in REST API.
Their argument is if the code is shared as a .jar file (eg. Database Driver jar file) then it is necessary to have an interface. Since jar is added in the classpath and the end user can override the methods defined in the jar file. Whereas REST API's are deployed in servers and can be consumed by any programming language via HTTP
I know there is no concrete answer for this. But I just want to know the advantages/disadvantages of having an interface in REST API / Microservice
The advantage of using an interface is when you use a service that is common by all your Rest API like the security service with spring-security.
"interface" is NOT specific to REST API (or) Spring, it is one of the Object oriented principle, in Java programming terms, it is "interface".
Your friends are partially true.
In general "interface" are used to define the "protocol" and let the implementation be specific to "implementer".
Now the counter argument I can make is, what if your company wants to standardize the process between "departments" (or) "projects", specific to this DAO business specification (forgot about sharing as .jar or something else)?
Interface is the best practice in this situation and it takes 1 minute to implement.
Once I did a hiring test to a company in UK and i got this feedback:
"And the dreaded Impl classes…"
At this point I started questioning the use of interfaces in microservices where everything is accessed through HTTP. After putting some thoughts into this I realized I never had a situation where Interfaces were really helpful in this situation.
I built a few personal projects without them (unless it's required by Spring) and I liked it. Being able to change services without painting them red by the IDE was a big plus.
Also, it's less code to maintain. I would vote up for it for new projects.
I'm looking for a way to add certain functionality to JAX-RS resources in an OSGI environment. Annotations seem to be a clean way to do this and I've seen it done in the Spring framework (no experience). Annotations such as #Transactional, or (what I wanted to do, requires a permission flag to be set on a user) #Permission(CREATE). However, I'm a bit stuck on how to do this in an OSGI environment.
The normal way(is it?) to go about adding aspects would be to register an aspect service that wraps the original service. If I looked it up correctly, JAX-RS resources are tracked and hooked up to an HttpService. JAX-RS resources do not implement an interface and proxies would need to be dynamically created.
How would I dynamically generate OSGI aspect services/resources that effectively hide the original resource from the JAX-RS tracker that hooks it to the HttpService? I have zero experience with existing AOP frameworks and barely any knowledge of AOP itself.
It is very common in the Java EE and Spring world to use interceptors and define additional behavior based on annotations. There are some solutions in OSGi as well, there is an RFP to support EJB annotations.
However, I have a different opinion. Although this looks cool, it is also magical. See the "Why not annotations, interceptors and other magic?" chapter of this README file where I wrote down my reasons. This project implements the logic that you would like to achieve with #Transactional annotation, but it only uses functional interfaces.
I think it is better to think in lambda expressions to achieve the goal you want (see the java 8 example behind the link). If it is not Java 8, you can still use anonymous classes (see jave 7 and above example behind the link). Your code will look more ugly with anonymous classes, but it will be very clear, what your code does.
Others might not like my answer. Three years ago I was one of the biggest fan of annotation scanning, weaving and interceptors. After a couple of headaches, I became an enemy of this "magical" concept.
I have a module1 (GUI) and a module2 (Ordering).
From module1 I need to access the OrderingService found in module2.
I can of course create an OrderingService interface and an OrderingServiceImpl as a concrete implementation. This is a good practice in relation to Dependency Inversion Principle (DIP).
From my knowledge in Java I can benefit from module decoupling (I can change OrderingServiceImpl but module1 will not be affected and RECOMPILED) and I can use dependency injection in Spring to automatically use the right implementation. Regarding TDD I don't think you really need to create a OrderingServiceMockImpl because you can use a Mocking framework to mock the concrete class OrderingServiceImpl.
When we only have a single concrete implementation is module decoupling the only real benefit? I see in practice a lot of developers that always create an interface but don't really use more then one concrete implementation and I'm trying to figure out if there is something more to it or not.
I can't just accept the concept create interfaces "hoping" you will benefit from them later on. Isn't more pragmatic to change the code to an interface when you really have two different implementations?
Also I would also like to understand this from a PHP point of view, because code compilation is not an issue in dynamicly typed languages.
The benefit of using interfaces is to let you work on smaller pieces of your system independently, in terms of testing, of course, but also in terms of the amount of details you need to concentrate on to write the code and to understand it when you look at months later. In some languages there are code management benefits too but this is not the primary motivation for using interfaces.
Let's change your example a little bit, because I would never start with the UI. Assume I am building the OrderingService which need a repository for storing and retrieving orders.
I would always create an interface for that repository, even if it is totally unlikely that I will ever have two implementations for it. The reason for creating it, that I do not need or want real data access at this stage of the development. What I do is "programming by wishful thinking". I imagine there would be this magic contraption that makes it possible to store and retrieve my orders. I specify how I imagine this as an interface. In my tests I mock the interface and can build the OrderingService without even touching anything DB related yet.
I do the same with other dependencies that are adapters to the "outside world" (repositories, clients for calling other services, event publishers, etc).
I am current using Seasar2 Framework on a project that I am in. The framework is quite popular here in Japan but I am having problem in finding English documentations. Even on their official English translation site, they just discuss that the framework use Dependency Injection and AOP.
I was intrigued with the way they use it in one of their component S2Dao. Basically you only need to create interface DAO class and the framework automatically, changes the code on runtime and creates intermediate class that get called in the middle. Hence DB transactions codes are automatically added to the class. I was wondering, is there any step by step explanation on how this is done? Can java change code on runtime and change the method on runtime?
Are good reference on how this is done? I just want to know how the framework is doing this.
Yes, it is possible to do dynamic implementations of an interface at runtime, and to manipulate the compiled bytecode also.
Java provides a built-in mechanism to implement interfaces at run-time, called dynamic proxy classes.
There are also good libraries like cglib or javassist, that allow you not only to implement interfaces, but also to extend classes and to manipulate bytecode at run-time (to change the behavior of a method, for example). Frameworks like Spring and Hibernate use libraries like these to make their magic, so your framework may be using some of these also.
NOTE: If you are curious, these libraries can "tweak" the bytecode because instead of using the default ClassLoader of the JVM, they load your classes using their own ClassLoader, so they have total control of every single byte of the loaded class, and they can do whatever they want with them :).
We basically need to be able to adjust behaviour at start-up time, by providing desired classes to be produced by various factories inside our application (to avoid the hard binding of the "new" operator).
I am aware that this is provided by several large frameworks, but I was looking for something easily used by a stand-alone Java application without being gigantic.
Any suggestions?
Edit: It is my experience that frameworks tend to grow big as part of maturing (and complex too). I need this to be retrofittable to a legacy application as part of major refactoring (technical debt), so simplicity is essential of the used libraries. I do not mind having to do a bit of coding in our application, but it must be very visible what is going on. AOP has a tendency for moving stuff out of the way, and that may make the application harder to maintain.
Edit: We have now reached the point where we actually need to make a decision. The application will probably live for decades so we need to make a reversible decision with a framework that will be maintained for hopefully as long. I really like the static type check available with Guice, but not that the annotations bind explicitly to Guice instead of being external like in Spring. I also like that code appears to be more concise when using Guice as opposed to Spring. We need something that is robust and helpful. We do not need more than just DI at the moment. Is there a use case that definitive says go for one of these?
Edit 2011-07-27: The final decision was to use the JSR-330 API in code, and choose on a per-project basis if to use Spring, Guice or Weld. For stand-alone applications Guice has worked well so far as the JSR-330 implementation.
You can always use Spring Framework 2.5. It is a big one, but if you planning to use only DI you can use spring-core and spring-beans modules, which are pretty small (ca. 500KB and 300KB).
There is also Google Guice 2.0 which comes with a package with only basic stuff (no AOP) and it's 430KB.
Have you looked at the Google Guice framework? It's pretty lightweight and annotation-based, avoiding XML configuration files
There's also Pico- and Nano-container (from codehaus) which are quite lightweight although the last time I looked (admittedly a few years ago) the documentation was lacking.
I must say that I agree with others about what I assume is your presumption that Spring is massive and confusing. It's really a very simple IoC container and to be recommended.
There are a couple I know of you might find useful:
PicoContainer
Plexus (used in Maven)
I've found Plexus very useful in standalone apps as it has optional utility components for CLI interaction.
By "gigantic" I'm going to assume you're referring to Spring, but that's unfair, since you can cherry-pick the bits of Spring you want to use. If all you need is the IoC container, just use the appropriate JAR files and the appropriate bit of the API, and ignore the rest of it.
Most answers so far seem to be concerned with the size of the jar files to be added.
However I think the more important question is the impact on the project: How many lines of code must be added/changed in order to use the framework?
Even the "big" spring framework is actually very easy to use:
You basically need:
a xml file that describes your factories.
one line of code to initialize the container by loading the xml file
The nice thing is that spring is non-intrusive. So you do not have to implement specific interfaces or add any specific annotations or imports to your classes.
At best the single spot where you actually initialize the Spring container is the only
place in your application that has an actual dependency to spring classes.
I would strongly suggest to take a look at Spring ME. Although originally meant to be a way to use Spring on Java ME applications, it also works fine for standalone applications.
True, it doesn't give you all of the bells and whistles that Spring (Full) has to offer, but then again, Full Spring is much much more than a simple dependency injection framework.
On the plus side: it's based on a (compliant) subset of Spring's configuration files, and the footprint of the runtime is 0%. In fact, there isn't any. Spring ME will take your application context, and turn it into a class that has no dependencies on classes other than your own.
What's wrong with Spring?
These days it's packaged pretty well so you wouldn't need to take the whole kit and caboodle.
As an aside, I'm not a fan of the annotation based injection frameworks. This is because the annotations are bound to the class rather than the instance, the later being a pre-requisite, imho, for DI. This means every instance of a given class gets the same object(s) injected, which seems to defeat the point.
Also consider that DI doesn't even need a framework, what's wrong with your main method wiring together the application?
If you want something maximally simple and appropriate, then write some code that does what you want done. Presumably this involves wiring together factories based partly on fixed logic, and partly on run-time settings.
This has the advantage that the set of possible run-time configurations is known, and so documentable and testable.
It has the disadvantage that an deploying an unanticipated logic change inherently takes an extra second or so of compile time, and (more significantly) can't be sneaked into production without full testing by disguising it as 'just a configuration change'.
About a year ago I asked myself a question very like this. So I spend a few hours reading the Spring and Guice documentation. After about an hour with Spring I was left feeling that I could get a basic web app going, but had no idea how to use it in a stand alone application. After an hour with the Guice document everything had clicked and I could see just how I to do what I wanted to get done.
Now on to recommending Guice? Well no. What does your team already know? If someone already knows say Spring leaver that knowledge and have them spread it about. Like wise with Guice or Pico.
If you want something really light weight you might want to have a look at fuse it's fairly extendable so might be what you're looking for.
cheers
N