We Keep Coding

How to resolve jersey.internal.RuntimeDelegateImpl with Jersey on OSGi

Im am using Jersey in an OSGi environment. I wrapped all Jetty and Jersey jars in one bundle containing also my own server / servlet / resource abstraction. This is running quite well. I am importing the javax.ws.rs-api via OSGi package import because related packages are also used by JAX-RS resource implementations in other bundles.
However, from time to time my implementation does not work with an "java.lang.ClassNotFoundException: org.glassfish.jersey.internal.RuntimeDelegateImpl cannot be found by javax.ws.rs-api_2.1.0".
It seems this could be a race condition. Maybe Jersey sometimes uses a class from my internal bundles and sometimes a class from imported javax. I cannot really figure out what the problem is.
The problem is similar to [1], but in my case it is not about any import or dependency. I wrapped the Jetty and Jersey Jars in an OSGi bundle.
[1] org.glassfish.jersey.internal.RuntimeDelegateImpl NOT FOUND

This problem occurs because the JAX-RS API uses many static methods to get hold of implementation types from the JAX-RS provider. In this case the error isn't coming from Jersey, but actually from the JAX-RS API itself when it tries to find an implementation of the various JAX-RS interfaces.
You effectively have four options:
Avoid exposing the JAX-RS API from your server by putting all the resources in there as well (I don't recommend this option!)
Embed the JAX-RS API in your existing Jetty/Jersey uber bundle and export it from there. Be careful to include the correct API package versions and contract capabilities! (This option is fiddly)
Use an OSGi-aware API bundle (such as one from Apache Aries, Apache Geronimo or Apache Service Mix). Many Java EE API bundles (JAX-RS included) package themselves as OSGi bundles, but ignore the fact that they actually need to work in OSGi, which means that you can't rely on reflectively loading types/resources from a flat classpath. (This option is probably quickest and lets you keep working as you are)
Move to using the new OSGi JAX-RS whiteboard from OSGi Release 7. The reference implementation for this is in Apache Aries and available on GitHub (This is the best long term option from an OSGi perspective, and means that you can avoid maintaining your own server)
I hope this all makes sense, explains why you're seeing the error, and hopefully gives you some options for working through the problem.

Considering moving from Java/Spring MVC to Grails

I'm currently using Java & Spring (MVC) to create a webapp, and I'm considering moving to Grails. I'd appreciate feedback/insight on the following:
I have multiple application contexts in the current Java/Spring webapp that I load through the web.xml ContextLoaderListener; is it possible to have multiple application contexts in Grails? If, yes, how?
This webapp extensively uses a CXF restful web service and the current Java/Spring webapp uses the bundled CXF HTTP client. Can I continue to use the (Java) CXF HTTP Client in Grails?
I implemented Spring Security using a custom implementation of UserDetails and UserDetailsService, can I re-use these implementations in Grails "as is" or must I re-implement them?
There is an instance where I've relied on Spring's jdbc template (rather than the available ORM) and an additional data source I defined in app context, can I re-use this in Grails?
I plan on using Maven as the project management tool; are there any issues of using Maven with Grails where there is a combination of groovy and java?
Edit:
I'm considering moving to Grails to make the development of the web component of the webapp "faster," a la Ruby-on-Rails. Also, I'm considering Grails rather than say Ruby-on-Rails, because I want to continue to use the JVM and I've dabbled with Grails in the past and it was fairly easy to pick-up and use.

Probably. Grails uses a sub-class of Spring's ContextLoaderListener class which it configures in the web.xml file. I can answer more precisely if you let me know how you do it with Spring MVC.
Yes. You might even be interested in the CXF plugin, although I can't vouch for it:
http://grails.org/plugin/cxf
You should be able to use them as-is. However, you might want to check whether this is easily done with the Spring Security plugin. I believe it is, but you'll be able to get a definitive answer from Burt Beckwith, the author of the plugin.
Yes. You can also get hold of the Hibernate session factory to do raw Hibernate stuff. GORM can also work with multiple data sources:
http://grails.org/plugin/datasources
Another Burt Beckwith one :)
It depends on what you mean by "a combination of Groovy and Java". You can build Grails projects with Maven, but the integration isn't entirely smooth. If you have Java and Groovy in your Grails project, then that's taken care of automatically.
In response to Bozho, I use standard Grails services + GORM and wouldn't do it any other way. Note that if you use Java for services and the domain model, you won't have automatic reloading of services. You also lose the benefits of expressiveness and conciseness that Groovy bring.
If you want, you can use static types in Grails services to make it easier for your IDE to provide code completion. It can also give you hints on properties and methods it doesn't recognise (which would corresponding to Java compilation errors). That said, even if you use static types, Groovy can't do type checks at compilation time. You'll only find out about them at runtime.

You can do all these things in grails. It supports all existing Java classes and spring configurations (grails is built ontop of spring mvc)
However, I really wouldn't recommend moving the whole application to grails. You can perhaps move only the web layer, if you have web developers that are not java experts.
The service layer, the data access, etc, better remain pure Java. That is, only your web controllers - the components that gather the user input, handle http requests and sessions, should use grails. The rest - the stateless service classes and your domain model would better be Java. That's my opinion, but I have already some experience with grails, and static typing in the service layer will save you much trouble.

2) Yes you can use CXF as is. There is a nice layer on top of CXF called GroovyWS. I have only used it for consuming SOAP services, but maybe it has something for REST as well. It's really easy to use.
For consuming REST services I have used HTTP Builder
4) Yes. You can continue to use e.g. spring config for configuring the datasource, or any other way you do it today. Multiple datasources is no problem.
5) I have recently tried using Grails (1.2.1) with Maven. It works, but there has been some issues with both Maven and Grails trying to do dependency management. The documentation is maybe the worst part. I haven't tried upgrading to 1.3 yet because of some major Maven-related JIRAs, but 1.3.2 is right around the corner, and those issues have now been resolved :) There will also be a 1.3.2 maven archetype. Looking forward to that. "Deployment and resolution of plugins from Maven repositories" is one of the new features of Grails 1.3, so things are probably better. Roadmap for 1.3.2 says release today, but there are 8 issues left at time speaking, so my guess would be tomorrow, the Grails releases are usually on time. If you can wait for that, you will probably save yourself some trouble.

If you are looking for rapid application development but aren't otherwise particularly enthused about groovy, you should look into spring-roo. It offers the same kind of RAD functionality, but builds a completely standard java + ORM + spring-mvc app (which has no actual dependencies (runtime or compile) on roo). It's definitely not as mature as grails, but you may find that it better suits your existing experience with statically typed java code and existing ORM, etc. I've only done a couple of small pet projects in roo, but I've been very impressed so far, particularly with how easy it is to customize the generated code and move back and forth between written and generated code. The initial tutorial is very rapid and quite revealing.

How to modularize a JSF/Facelets/Spring application with OSGi?

I'm working with very large JSF/Facelets applications which use Spring for DI/bean management.
My applications have modular structure and I'm currently looking for approaches to standardize the modularization.
My goal is to compose a web application from a number of modules (possibly depending on each other). Each module may contain the following:
Classes;
Static resources (images, CSS, scripts);
Facelet templates;
Managed beans - Spring application contexts, with request, session and application-scoped beans (alternative is JSF managed beans);
Servlet API stuff - servlets, filters, listeners (this is optional).
What I'd like to avoid (almost at all costs) is the need to copy or extract module resources (like Facelets templates) to the WAR or to extend the web.xml for module's servlets, filters, etc. It must be enough to add the module (JAR, bundle, artifact, ...) to the web application (WEB-INF/lib, bundles, plugins, ...) to extend the web application with this module.
Currently I solve this task with a custom modularization solution which is heavily based on using classpath resources:
Special resources servlet serves static resources from classpath resources (JARs).
Special Facelets resource resolver allows loading Facelet templates from classpath resources.
Spring loads application contexts via the pattern classpath*:com/acme/foo/module/applicationContext.xml - this loads application contexts defined in module JARs.
Finally, a pair of delegating servlets and filters delegate request processing to the servlets and filters configured in Spring application contexts from modules.
Last days I read a lot about OSGi and I was considering, how (and if) I could use OSGi as a standardized modularization approach. I was thinking about how individual tasks could be solved with OSGi:
Static resources - OSGi bundles which want to export static resources register a ResourceLoader instances with the bundle context. A central ResourceServlet uses these resource loaders to load resources from bundles.
Facelet templates - similar to above, a central ResourceResolver uses services registered by bundles.
Managed beans - I have no idea how to use an expression like #{myBean.property} if myBean is defined in one of the bundles.
Servlet API stuff - use something like WebExtender/Pax Web to register servlets, filters and so on.
My questions are:
Am I inventing a bicycle here? Are there standard solutions for that? I've found a mentioning of Spring Slices but could not find much documentation about it.
Do you think OSGi is the right technology for the described task?
Is my sketch of OSGI application more or less correct?
How should managed beans (especially request/session scope) be handled?
I'd be generally grateful for your comments.

What you're aiming to do sounds doable, with a few caveats:
The View Layer: First, your view layer sounds a little overstuffed. There are other ways to modularize JSF components by using custom components that will avoid the headaches involved with trying to create something as dramatic as late-binding managed beans.
The Modules Themselves: Second, your modules don't seem particularly modular. Your first bullet-list makes it sound as if you're trying to create interoperable web apps, rather than modules per se. My idea of a module is that each component has a well-defined, and more or less discrete, purpose. Like how ex underlies vi. If you're going down the OSGi route, then we should define modular like this: Modular, for the sake of this discussion, means that components are hot-swappable -- that is, they can be added and removed without breaking the app.
Dependencies: I'm a little concerned by your description of the modules as "possibly depending on each other." You probably (I hope) already know this, but your dependencies ought to form a directed acyclic graph. Once you introduce a circular dependency, you're asking for a world of hurt in terms of the app's eventual maintainability. One of the biggest weaknesses of OSGi is that it doesn't prevent circular dependencies, so it's up to you to enforce this. Otherwise your dependencies will grow like kudzu and gradually choke the rest of your system's ecosystem.
Servlets: Fuhgeddaboudit. You can't late-bind servlets into a web app, not until the Servlet 3.0 spec is in production (as Pascal pointed out). To launch a separate utility servlet, you'll need to put it into its own app.
OK, so much for the caveats. Let's think about how this might work:
You've defined your own JSF module to do... what, exactly? Let's give it a defined, fairly trivial purpose: a login screen. So you create your login screen, late-bind it using OSGi into your app and... then what? How does the app know the login functionality is there, if you haven't defined it in your .jspx page? How does the app know to navigate to something it can't know is there?
There are ways to get around this using conditional includes and the like (e.g., <c:if #{loginBean.notEmpty}>), but, like you said, things get a little hairy when your managed loginBean exists in another module that may not have even been introduced to the app yet. In fact, you'll get a servlet exception unless that loginBean exists. So what do you do?
You define an API in one of your modules. All the managed beans that you intend to share between modules must be specified as interfaces in this API layer. And all your modules must have default implementations of any of these interfaces that they intend to use. And this API must be shared between all interoperable modules. Then you can use OSGi and Spring to wire together the specified beans with their implementation.
I need to take a moment to point out that this is not how I would approach this problem. Not at all. Given something like as simple as a login page, or even as complicated as a stock chart, I'd personally prefer to create a custom JSF component. But if the requirement is "I want my managed beans to be modular (i.e., hot-swappable, etc)," this is the only way I know to make it work. And I'm not even entirely sure it will work. This email exchange suggests that it's a problem that JSF developers have only just started to work on.
I normally consider managed beans to be part of the view layer, and as such I use them only for view logic, and delegate everything else to the service layer. Making managed beans late-binding is, to my mind, promoting them out of the view layer and into the business logic. There's a reason why all those tutorials are so focused on services: because most of the time you want to consider what it would take for your app to run "headless," and how easy it would be to "skin" your view if, for instance, you wanted it to run, with all its functionality, on an Android phone.
But it sounds like a lot of what you're working with is itself view logic -- for instance, the need to swap in a different view template. OSGi/Spring should be able to help, but you'll need something in your app to choose between available implementations: pretty much what OSGi's Service Registry was built to do.
That leaves static resources. You can modularize these, but remember, you'll need to define an interface to retrieve these resources, and you'll need to provide a default implementation so your app doesn't choke if they're absent. If i18n is a consideration, this could be a good way to go. If you wanted to be really adventurous, then you could push your static resources into JNDI. That would make them completely hot-swappable, and save you the pain of trying to resolve which implementation to use programmatically, but there are some downsides: any failed lookup will cause your app to throw a NamingException. And it's overkill. JNDI is normally used in web apps for app configuration.
As for your remaining questions:
Am I inventing a bicycle here? Are there standard solutions for that?
You are, a little. I've seen apps that do this kind of thing, but you seem to have stumbled into a fairly unique set of requirements.
Do you think OSGi is the right technology for the described task?
If you need the modules to be hot-swappable, then your choices are OSGi and the lighter-weight ServiceLocator interface.
Is my sketch of OSGI application more or less correct?
I can't really tell without knowing more about where your component boundaries are. At the moment, it sounds like you may be pushing OSGi to do more than it is capable of doing.
But don't take my word for it. I found other reading material in these places.
And since you ask about Spring Slices, this should be enough to get you started. You'll need a Git client, and it looks like you'll be training yourself on the app by looking through the source code. And it's very early prototype code.

I am facing the same problems in my current project. In my opinion, OSGi is the best and cleanest solution in terms of standards and future support, but currently you may hit some problems if you try using it in a web application:
there is no well integrated solution between a Web Container and the OSGi platform yet.
OSGi may be too much for a custom build web application that is just searching for a simple modularized architecture. I would consider OSGi if my project needs to support third party extensions that are not 100% under our control, if the project needs hot redeployments, strict access rules between plugins, etc.
A custom solution based on class loaders and resource filters seems very appropriate for me.
As an example you can study the Hudson source code or Java Plug-in Framework (JPF) Project(http://jpf.sourceforge.net/).
As about extending the web.xml, we may be lucky with the Servlet 3.0 specification(http://today.java.net/pub/a/today/2008/10/14/introduction-to-servlet-3.html#pluggability-and-extensibility).

The "web module deployment descriptor fragment" (aka web-fragment.xml) introduced by the Servlet 3.0 specification would be nice here. The specification defines it as:
A web fragment is a logical
partitioning of the web app in such a
way that the frameworks being used
within the web app can define all the
artifacts without asking devlopers to
edit or add information in the
web.xml.
Java EE 6 is maybe not an option for you right now though. Still, it would to be the standardized solution.

Enterprise OSGi is a fairly new domain so dont think you will get a solution that directly satisfies your need. That said one of the things I found missing from Equinox (osgi engine behind eclipse and hence one with largest user base!) is a consistent configuration / DI service. In my project recently we had some similar needs and ended building a simple configuration osgi service.
One of the problems which will be inherent to modular applications would be around DI, as the module visibility could prevent class access in some cases. We got around this using a registered-buddy policy, which is not too ideal but works.
Other than configuration, you can take a look at the recently released Equinox book for guidance on using OSGi as base for creating modular applications. The examples may be specific to Equinox, but the principles would work with any OSGi framework. Link - http://equinoxosgi.org/

You should look into Spring DM Server (it's being transitioned to Eclipse Virgo but that's not been released yet). There's a lot of good things in the recent OSGi enterprise spec which has also just been released.
Some of the Spring DM tutorials will help, I'd imagine. But yes, it's possible to have both resources and classes loaded from outside the web bundle using standard modularity. In that, it's a good fit.
As for the session context - it gets handled as you would expect in a session. However, you might run into problems with sharing that session between web bundles to the extent that in not sure if it's even possible.
You could also look to have a single web bundle and then use e.g. the Eclipse extension registry to extend the capabilities of you web app.

java tomcat6: javax.ws missing

I'm trying to run TinyFbClient (tiny facebook client) and it needs to import
javax.ws.rs.core.UriBuilder and javax.ws.rs.core.MediaType
i don't have javax.ws package.
what jar file am i missing?
programming using netbeans 6.8
on tomcat 6.0.20
thanks!

You need a concrete JAX-WS implementation. Tomcat isn't, it's just a Servlet API implementation. You'll need another appserver which implements JAX-WS as well (e.g. Glassfish), or to add a concrete JAX-WS implementation to your webapp. Glassfish uses Metro, which is built on top of Sun reference JAX-WS implementation. You can download it separately and use on Tomcat as well. If you Google using keywords "tomcat metro", you'll find several hints at blogs, for example this one.
Update you need javax.ws.rs package, not javax.ws package only ;) So here's a slight modified answer:
You need a concrete JAX-RS implementation. Tomcat isn't, it's just a Servlet API implementation. You'll need another appserver which implements JAX-RS as well (e.g. Glassfish), or to add a concrete JAX-RS implementation to your webapp. Glassfish uses Jersey, which is built on top of Sun reference JAX-RS implementation. You can download it separately and use on Tomcat as well. If you Google using keywords "tomcat jersey", you'll find several hints at blogs, for example this one.

It seems you need JAX-RS on your classpath. Jersey is the JAX-RS reference imeplementation.
Googling, as advised by BalusC, gives this tutorial, which seems like a good one.

How to create documented WSDL using XFire

I use XFire to create a webservice wrapper around my application. XFire provides the webservice interface and WSDL at runtime (or creates them at compile time, don't know exactly).
Many of our customers don't know webservices very well and additionally they simply don't read any external documentation like Javadoc. I know that it's possible to add documentation (for parameters and methods) directly to the WSDL file.
I thought about Annotations or Aegis XML files but I don't know how... Do you know a way?
Edit: I just found this JIRA issue but the last activity was 2006. Any ideas?

XFire is slowly headed for /dev/null. Use CXF instead. In other words, XFire is being deprecated in favor of CXF - it's pretty much the same developers.
Since you use the Java-first approach, I suggest you generate you WSDL once and for all with CXF's java2wsdl tool, then you put your documentation in that and tell CXF to use that documented WSDL instead of letting CXF generate its own (undocumented) WSDL at runtime/deploy-time.
This page has pretty much everything you need to know about creating a web service in CXF.

And my last hint regarding CXF - use Aegis for data binding instead of JAXB. It doesn't work for complex POJO.
In my experience we have no problem with complex POJO and JAXB, the only problem is that the code starts to be cluttered with JAXBElements. On the other hand, Aegis documentation is pretty sparse and not well-maintained with relation to CXF.

Let's me add my two cents regarding XFire. We had very serious issue with XFie under JDK6 (both Tomcat 6.0 and 5.5).Please take a glance at that issue. In our case XFire with 4+ web services under JDK6 leads to hanging application servers (thread deadlocks etc.). It's interesting, but under JDK5 everything was OK.
And I completely agree with Christian Vest regarding migration to CXF from XFire. It has sense in many cases e.g. ESB Mule 2 doesn't support native XFire connectors anymore (see also).
And I wish to add that migration from XFire to CXF is not straitforward way (e.g. CXF has jar dependences that conflict with some hibernate releases see also), but it's doable. In our case we did it for couple days without code correction (Spring only configuration).
And my last hint regarding CXF - use Aegis for data binding instead of JAXB. It doesn't work for complex POJO.