Hi Paul!
Thanks so much for the fast reply.
I was quite happy to see Atmosphere Spade Server as a module in the
system I am developing (a RESTful device gateway for automation)
because of the following reasons:
- it can run standalone
- supports REST
- supports Comet
However, as I based my system on OSGi, I am now in a serious dilemma
on how to continue. Do you have any suggestions on quick fixes I could
do to get atmosphere (the Jersey part of it) under OSGi until a decent
solution comes from the dev team?
Regards,
Vlatko
On Sep 28, 2009, at 2:37 PM, Paul Sandoz wrote:
>
> On Sep 27, 2009, at 3:25 AM, Vlatko Davidovski wrote:
>
>> Hi!
>>
>> I am trying to port atmosphere-spade-server (with all required
>> dependencies) to OSGi.
>> After a lot of problems I had, I finally managed to get a normal
>> OSGi bundle containing the required code for the atmosphere-spade-
>> server to run.
>>
>> However, I hit a huge problem in respect to the REST resource class
>> loading. Seems that the PackagesResourceConfig class contains OSGi
>> unfriendly code (it tries to treat classes as resources, which
>> seems not to work on OSGi). Therefore, there is now way I can
>> attach any resource classes, no matter the spade server runs.
>
> Yes, PackagesResourceConfig is not appropriate for an OSGi
> environment.
>
> We might be able to use alternative registration mechanism, for
> example see here:
>
> https://jersey.dev.java.net/nonav/documentation/1.1.2-ea/user-guide.html
> #d4e115
>
> for registering an Application or ResourceConfig. For example,
>
> https://jersey.dev.java.net/nonav/apidocs/1.1.2-ea/jersey/com/sun/jersey/api/core/ClassNamesResourceConfig.html
>
> However, further errors will occur because of META-INF/services files.
>
>
>> I found out that someone already hit the same problem on Jersey
>> level and provided info on http://coderthoughts.blogspot.com/2008/03/using-jersey-jsr311-inside-osgi-with.html
>> and this might be of help.
>>
>
> Yes.
>
> We are working to modify Jersey jars to support OSGi. The plan is to
> use Apache service mix and we will provide separate OSGi-based jars
> (because we want to reduce the risks given the release of Java EE 6
> in November that Jersey will be a part of). The problem is we keep
> get distracted from this task due to higher priority Glassfish tasks!
>
>
>> So here are few questions:
>>
>> 1. I was wondering, would it be possible to do something to remove
>> this constraint that stops running the spade server in OSGi.
>>
>> 2. Is the dev team planning to include some support in providing a
>> single OSGi Atmosphere Spade Server bundle that will contain all
>> required code to run the server and would have a simple service to
>> allow registration of resource classes? I believe this would be of
>> a great help for many OSGi developers interested in having Comet
>> support on RESTful architecture. On my side, I could provide some
>> more feedback, and potentially help in writing the OSGi services.
>>
>
> Thanks, Jakub from the Jersey team is responsible for the
> OSGi'ification of Jersey. He can provide a better description of the
> plan of action than I.
>
>
>> 3. A final question.. Currently one can set up only a package
>> containing the resource classes for the atmosphere spade server. It
>> would be quite helpful, if there would be a method in the server
>> class allowing something like server.addResource(...) (to add a
>> single resource class). Could we have such functionality?
>>
>
> I think it would be more appropriate to pass in an a class or
> instance of javax.ws.rs.Application.
>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_atmosphere.dev.java.net
> For additional commands, e-mail: users-help_at_atmosphere.dev.java.net
>