added jersey-scala library to trunk

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

added jersey-scala library to trunk

jstrachan
As mentioned on this thread...
http://n2.nabble.com/using-Lift-templates-with-Jersey-%28was-Re%3A--Jersey--custom--TemplateProcessor-not-having-its-constructor-injected-%29-td2675518.html

I've just made my first commit (yay!) to solve this issue
https://jersey.dev.java.net/issues/show_bug.cgi?id=281

by adding a new jersey-scala library (to the contribs area) along with
an example of it in use in the samples...
https://jersey.dev.java.net/source/browse/jersey/trunk/jersey/samples/scala-helloworld-webapp/src/main/scala/com/sun/jersey/samples/helloworld/resources/MarkupResource.scala?annotate=2305

the only icky part of this is having to remember to add the
jersey-scala package to the list of packages in your web.xml (e.g.
look for the 'jersey.scala' in here on line 8...)
https://jersey.dev.java.net/source/browse/jersey/trunk/jersey/samples/scala-helloworld-webapp/src/main/webapp/WEB-INF/web.xml?annotate=2305

it would be nice to make jersey extensions & resource beans
auto-discoverable (either on OSGi via a bundle activator looking for
jersey extensions, or in non-OSGi using a META-INF/services type thing
where all Jersey extensions can be advertised using a canonical file
that Jersey can load on startup) - then just adding jersey-scala to
your classpath would be enough.
http://n2.nabble.com/-IDEA--making-resource-beans-auto-discoverable-when-making-modular--web-applications-td2389256.html#a2389256

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: added jersey-scala library to trunk

Paul Sandoz
Administrator

On Apr 27, 2009, at 2:15 PM, James Strachan wrote:

> As mentioned on this thread...
> http://n2.nabble.com/using-Lift-templates-with-Jersey-%28was-Re%3A--Jersey--custom--TemplateProcessor-not-having-its-constructor-injected-%29-td2675518.html
>
> I've just made my first commit (yay!) to solve this issue
> https://jersey.dev.java.net/issues/show_bug.cgi?id=281
>

Great!


> by adding a new jersey-scala library (to the contribs area) along with
> an example of it in use in the samples...
> https://jersey.dev.java.net/source/browse/jersey/trunk/jersey/samples/scala-helloworld-webapp/src/main/scala/com/sun/jersey/samples/helloworld/resources/MarkupResource.scala?annotate=2305
>
> the only icky part of this is having to remember to add the
> jersey-scala package to the list of packages in your web.xml (e.g.
> look for the 'jersey.scala' in here on line 8...)
> https://jersey.dev.java.net/source/browse/jersey/trunk/jersey/samples/scala-helloworld-webapp/src/main/webapp/WEB-INF/web.xml?annotate=2305
>
> it would be nice to make jersey extensions & resource beans
> auto-discoverable (either on OSGi via a bundle activator looking for
> jersey extensions, or in non-OSGi using a META-INF/services type thing
> where all Jersey extensions can be advertised using a canonical file
> that Jersey can load on startup) - then just adding jersey-scala to
> your classpath would be enough.
> http://n2.nabble.com/-IDEA--making-resource-beans-auto-discoverable-when-making-modular--web-applications-td2389256.html#a2389256
>

You can include the writer implementation class in the file:

   META-INF/services/javax.ws.rs.ext.MessageBodyWriter

of the jersey-scala jar e.g. see the jersey-multipart module.

I liked your solution, we discussed a while ago, for a single META-INF/
services file that contains a list of classes.

Strictly speaking it is not necessary to have a META-INF/services file  
specific to the interface of what is being implemented. It is sort of  
a hangover from how things were initially implemented.

Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: added jersey-scala library to trunk

jstrachan
2009/4/27 Paul Sandoz <[hidden email]>:

>
> On Apr 27, 2009, at 2:15 PM, James Strachan wrote:
>
>> As mentioned on this thread...
>>
>> http://n2.nabble.com/using-Lift-templates-with-Jersey-%28was-Re%3A--Jersey--custom--TemplateProcessor-not-having-its-constructor-injected-%29-td2675518.html
>>
>> I've just made my first commit (yay!) to solve this issue
>> https://jersey.dev.java.net/issues/show_bug.cgi?id=281
>>
>
> Great!
>
>
>> by adding a new jersey-scala library (to the contribs area) along with
>> an example of it in use in the samples...
>>
>> https://jersey.dev.java.net/source/browse/jersey/trunk/jersey/samples/scala-helloworld-webapp/src/main/scala/com/sun/jersey/samples/helloworld/resources/MarkupResource.scala?annotate=2305
>>
>> the only icky part of this is having to remember to add the
>> jersey-scala package to the list of packages in your web.xml (e.g.
>> look for the 'jersey.scala' in here on line 8...)
>>
>> https://jersey.dev.java.net/source/browse/jersey/trunk/jersey/samples/scala-helloworld-webapp/src/main/webapp/WEB-INF/web.xml?annotate=2305
>>
>> it would be nice to make jersey extensions & resource beans
>> auto-discoverable (either on OSGi via a bundle activator looking for
>> jersey extensions, or in non-OSGi using a META-INF/services type thing
>> where all Jersey extensions can be advertised using a canonical file
>> that Jersey can load on startup) - then just adding jersey-scala to
>> your classpath would be enough.
>>
>> http://n2.nabble.com/-IDEA--making-resource-beans-auto-discoverable-when-making-modular--web-applications-td2389256.html#a2389256
>>
>
> You can include the writer implementation class in the file:
>
>  META-INF/services/javax.ws.rs.ext.MessageBodyWriter
>
> of the jersey-scala jar e.g. see the jersey-multipart module.

Ah - I'd missed that! I just added that now, so at least this issue is
avoided for jersey-scala - thanks!


> I liked your solution, we discussed a while ago, for a single
> META-INF/services file that contains a list of classes.
>
> Strictly speaking it is not necessary to have a META-INF/services file
> specific to the interface of what is being implemented. It is sort of a
> hangover from how things were initially implemented.

I wonder if we had something like a text file containing package names called

  META-INF/services/jersey-packages

which Jersey could then load all of them it can see on the classpath
and use them to search through for resource beans & entity providers
and whatnot?

Then in effect the packages listed in each
META-INF/services/jersey-packages file are concatenated with whatever
the user configures in the com.sun.jersey.config.property.packages
property?

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: added jersey-scala library to trunk

Paul Sandoz
Administrator
On Apr 27, 2009, at 3:00 PM, James Strachan wrote:

>> I liked your solution, we discussed a while ago, for a single
>> META-INF/services file that contains a list of classes.
>>
>> Strictly speaking it is not necessary to have a META-INF/services  
>> file
>> specific to the interface of what is being implemented. It is sort  
>> of a
>> hangover from how things were initially implemented.
>
> I wonder if we had something like a text file containing package  
> names called
>
>  META-INF/services/jersey-packages
>
> which Jersey could then load all of them it can see on the classpath
> and use them to search through for resource beans & entity providers
> and whatnot?
>
> Then in effect the packages listed in each
> META-INF/services/jersey-packages file are concatenated with whatever
> the user configures in the com.sun.jersey.config.property.packages
> property?
>

Yes. I think supporting a jersey-classes property as well is useful  
because the package scanning utilizes techniques that might not work  
if a special class loader is utilized (e.g. one that does not load  
classes from files).

I am guessing for framework-type libraries it is not as useful to  
declare a package as is the case for an end developer.

Could you log an issue?

Thanks,
Paul.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: added jersey-scala library to trunk

jstrachan
2009/4/27 Paul Sandoz <[hidden email]>:

> On Apr 27, 2009, at 3:00 PM, James Strachan wrote:
>>>
>>> I liked your solution, we discussed a while ago, for a single
>>> META-INF/services file that contains a list of classes.
>>>
>>> Strictly speaking it is not necessary to have a META-INF/services file
>>> specific to the interface of what is being implemented. It is sort of a
>>> hangover from how things were initially implemented.
>>
>> I wonder if we had something like a text file containing package names
>> called
>>
>>  META-INF/services/jersey-packages
>>
>> which Jersey could then load all of them it can see on the classpath
>> and use them to search through for resource beans & entity providers
>> and whatnot?
>>
>> Then in effect the packages listed in each
>> META-INF/services/jersey-packages file are concatenated with whatever
>> the user configures in the com.sun.jersey.config.property.packages
>> property?
>>
>
> Yes. I think supporting a jersey-classes property as well is useful because
> the package scanning utilizes techniques that might not work if a special
> class loader is utilized (e.g. one that does not load classes from files).
>
> I am guessing for framework-type libraries it is not as useful to declare a
> package as is the case for an end developer.
>
> Could you log an issue?

Done
https://jersey.dev.java.net/issues/show_bug.cgi?id=282
--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]