-
Notifications
You must be signed in to change notification settings - Fork 303
service framework #1
Comments
If we use metro from jdk we still need to use another implementation for JAX-RS (e.g. restEasy). CXF would give us one solution for implementation of both standards. It integrates also very good with Spring and other frameworks, like Camel (it would be helpful if one needs to use Camel). Could you attach a patch with your poc or commit the changes into a new branch, e.g. If we use the jdk metro version we should check whether the JAX-WS RI’s Spring support works (using the JAX-WS Commons Spring integration). Another way would be export using the |
Another disadvantage of the Metro provided by jdk is locking to the version provided by the used jdk. We should probably think about integrating the JAX-WS RI provided by external jars. We were using for a short time the jdk version of Metro and it made a lot of compatibility problems when we wanted to implement more complicated extensions (like handlers or even tubes) and run in development using the version provided by jdk and in production using the version provided by WebLogic. We have migrated to the external JAX-WS RI implementations (locally in classpath, in prod included in ear file) and it works with no problem. But for easy cases it should make no problems. We can eventually provide one concept for Metro (and something for JAX-RS) and another for CXF. |
We're both using JAX RS and JAX WS in our project. I think have to check which implementation and version were using exactly. I can provide some example snippets of what were doing then. |
Which JAX-RS implementation are you using? |
I thinks it's metro (for jax ws) and jersey (for jax rs), but I have to check. |
Okay that makes sense.
Yes, that would be nice because you often have to deal with both and then you only have one solution to hook up with authentication, etc. |
I comitted the change on the master. If we go for metro and jersey, I will simply replace it. Currently anything is better than nothing. The REST service is not working as expected. Might be some config missing... Any CXF experienced person might have a look. |
Have you pushed the commit? I can't see it |
Sorry, I was to tired. Now pushed... |
Thanks. What a problem is with the REST service? Could you open an issue in oasp4j-sample? I'll look at it next week. |
In put from Frank:
Sounds great so far. However Martin G. wrote:
Mhm. This underlines what @sobkowiak said. Relying on something build into JDK or Appserver is sometimes tedious. However both approaches have their pros and cons. Considerations for Java < 1.7 are IMHO not relevant. However the same problems may apply in the future with upcoming versions. But as we are going to promote the actual standard and use it in the code, "only" the integration and configuration will change if you have to switch. Having less dependencies and using what java already provides is at least a Pro argument according to KISS. |
Even with Java 7 we had problems with running the application on WebLogic 12c. We have solved it by using the external JAX-WS implementation. We had to make additional configuration in ears to force WebLogic to use the implementation provided by ears (instead of the WebLogic implementation) But as long as the application will run on as separate jdk process or will be started using web container (which does not provide JAX-WS implementation) the jdk version should work. We can provide solution for the problem with starting the application on WebLogic. Perhaps can Martin provide a solution for WebSphere (if they have solved the problem) I think, we should also test it with JBoss AS/WildFly. It uses CXF as internal JAX-WS implementation. Where should we collect such informations? In Wiki too? |
It is available but does not respond. And this is just a HelloWorld example. I am sure that there will be an easy fix so nothing against CXF except maybe that it might have a pitfall I ran into (HelloWorld should actually run OOTB without magic configuration triggers).
Cyclic references, advanced Polymorphism, etc. should be considered as an anit-pattern for WS and REST services and are out of scope. This is only acceptable for internal Java to Java communication that we will do via HttpInvoker. |
I fixed the PoC with CXF (already pushed). It now works properly. Only the service overview page is confusing for REST services. I fixed the spring config (and removed "helloWorld" from address that was also present in Path annotation causing a duplication for URL - so a mistake from my end). |
Independent from the implementation and technology what are the conventions and best practices? I already established as global "services/" path and then divided into "ws/" and "rest/". On the next level should there be the <component> and then the actual service? |
|
Things are never smooth and easy :(
If this is the official documentation then the decision is easy: We will use Jersey as proposed by @maihacke, Frank and Martin. See the ease of use here: |
Together with @agreul I changed the PoC to jersey (already pushed, not visible in this issue as the sample is in a separate repository). As always some tricky parts to get along but now it works as expected. POJOs get down to JSON seamlessly. The Web-Service has to be ported with metro what we will do on monday. Also we will start with writing real REST services for the angular client and remove the HelloWorld PoC. I also tagged the PoC running CXF and pushed the tag in case we need that later on.
Then we should have an easy to use and smooth solution and can start the documentation. |
What do you exactly mean with the wiki authors guide? |
We don't need to use jettison with CXF. Please look at http://cxf.apache.org/docs/jax-rs-data-bindings.html#JAX-RSDataBindings-Jackson. Together with schema based Spring configuration it's KISS too. I know, it's decided to use Metro and Jersey as a standard for OASP4J, but I think, we should provide the CXF guide as alternative for Metro and Jersey for projects which prefer this solution (it can be also provided somewhere in optional documentation if you prefer to promote one standard). Let's implement a solid standard solution with Metro and Jersey. I'd like to take over the CXF theme next, after the more important themes are finalized. |
A few comments from my side:
|
|
This is what we are using with Jersey.
I see your point. But for Metro it is about JDK1.7 and that is what we already require as minimum by our code (will not work in JDK1.6 already). I think CXF is a great escape if you have pain with Metro and JDK version. But Metro2 and Jersey have been used by many projects in larger scale and it works with their requirements. This is a major aspect. Which project is already using CXF 3 in mission critical situations? Maybe we have one but I did not find anybody in my near circles...
I solved this in less than 2 Minutes. We had a long weekend in Germany. Let us not discuss on such aspects. I sometimes want to give a preview when someone can expect progress. That has nothing to do with the complexity of the solution just with my personal schedule. |
Using Jersey and Metro we have to use 2 different implementations and 2 different ways for configuration. Using CXF you can simply use the Spring xml scheme for both service types - I think, this is less confusing for developers |
IMHO this is not really the point. With CXF you already have 2 ways to configure REST and WS as these are two different animals. For JAXRS you configure a "server" and declare all service endpoints in that service and for JAXWS you define endpoints individually. In any way I did not want to use any of such approach and instead just use a marker interface so that all services implementing the marker and available as spring bean are auto registered. I solved this for Jersey and will try to find a similar solution for CXF. I currently gave CXF another try because the spring integration is buggy: JSON with Jaxkson is working easy in CXF. Still I am looking for a large-scale project that has proven success with CXF before promoting it. |
There are some more issue addressing this point: https://java.net/jira/browse/JERSEY-2301 Spring Integration is relatively new (Mid 2013) |
For the record: |
upgrade to oasp2.0.0 (Spring boot)
Issue oasp#15 Patch d'envers
We need a service framework. It should ideally support both JAX-WS and JAX-RS and integrate with CDI and spring.
I managed to do this with CXF in our example (not committed).
Simon says this also works with metro from JDK OOTB. In that case this would be preferred.
The text was updated successfully, but these errors were encountered: