"...I cannot explain why initiate gets called twice, it implies that
servlet initiation occurs twice as well and you should see duplicate
information in the logs when Jersey initiates."
In Tomcat I do see the duplicate information in the logs when Jersey initiates.
I also removed the "implements Filter" from our Servlet since ServletContainer already implements Filter.
Here is a snippet of my Tomcat log that shows Jersey being initiated twice on startup
Aug 30, 2010 10:04:35 AM com.sun.jersey.api.core.PackagesResourceConfig init
INFO: Scanning for root resource and provider classes in the packages:
com.ejgallo.finance
Aug 30, 2010 10:04:35 AM com.sun.jersey.api.core.ScanningResourceConfig logClasses
INFO: Root resource classes found:
class com.ejgallo.finance.accountspayable.payments.documents.ImageRequest
class com.ejgallo.finance.accountspayable.payments.menu.inquiry.Inquiry
class com.ejgallo.finance.accountspayable.payments.invoice.PreferencesRequest
class com.ejgallo.finance.accountspayable.payments.mobile.Mobile
class com.ejgallo.finance.accountspayable.payments.attachments.Attachments
class com.ejgallo.finance.accountspayable.payments.documents.DocumentRequest
class com.ejgallo.finance.accountspayable.payments.data.Data
class com.ejgallo.finance.accountspayable.payments.invoice.InvoiceRequest
class com.ejgallo.finance.accountspayable.payments.workflow.WorkflowRequest
class com.ejgallo.finance.accountspayable.payments.dialogs.Dialogs
class com.ejgallo.finance.accountspayable.payments.admin.Reminders
class com.ejgallo.finance.accountspayable.payments.invoice.HistoryRequest
class com.ejgallo.finance.accountspayable.payments.admin.Support
Aug 30, 2010 10:04:35 AM com.sun.jersey.api.core.ScanningResourceConfig logClasses
INFO: Provider classes found:
class com.ejgallo.finance.common.jaxrs.W3CDocumentProvider
class com.ejgallo.finance.common.jaxrs.BinaryContentProvider
class com.ejgallo.finance.accountspayable.payments.errors.ApplicationExceptionMapper
class com.ejgallo.finance.accountspayable.payments.web.WebSessionInjector
class com.ejgallo.finance.common.jaxrs.GenericProvider
class com.ejgallo.finance.accountspayable.payments.errors.ThrowableExceptionMapper
class com.ejgallo.finance.accountspayable.payments.errors.NotFoundExceptionMapper
class com.ejgallo.finance.common.jaxrs.TemplateProvider
...
...
...
Aug 30, 2010 10:04:41 AM com.sun.jersey.api.core.PackagesResourceConfig init
INFO: Scanning for root resource and provider classes in the packages:
com.ejgallo.finance
Aug 30, 2010 10:04:41 AM com.sun.jersey.api.core.ScanningResourceConfig logClasses
INFO: Root resource classes found:
class com.ejgallo.finance.accountspayable.payments.documents.ImageRequest
class com.ejgallo.finance.accountspayable.payments.menu.inquiry.Inquiry
class com.ejgallo.finance.accountspayable.payments.invoice.PreferencesRequest
class com.ejgallo.finance.accountspayable.payments.mobile.Mobile
class com.ejgallo.finance.accountspayable.payments.attachments.Attachments
class com.ejgallo.finance.accountspayable.payments.documents.DocumentRequest
class com.ejgallo.finance.accountspayable.payments.data.Data
class com.ejgallo.finance.accountspayable.payments.invoice.InvoiceRequest
class com.ejgallo.finance.accountspayable.payments.workflow.WorkflowRequest
class com.ejgallo.finance.accountspayable.payments.dialogs.Dialogs
class com.ejgallo.finance.accountspayable.payments.admin.Reminders
class com.ejgallo.finance.accountspayable.payments.invoice.HistoryRequest
class com.ejgallo.finance.accountspayable.payments.admin.Support
Aug 30, 2010 10:04:41 AM com.sun.jersey.api.core.ScanningResourceConfig logClasses
INFO: Provider classes found:
class com.ejgallo.finance.common.jaxrs.W3CDocumentProvider
class com.ejgallo.finance.common.jaxrs.BinaryContentProvider
class com.ejgallo.finance.accountspayable.payments.errors.ApplicationExceptionMapper
class com.ejgallo.finance.accountspayable.payments.web.WebSessionInjector
class com.ejgallo.finance.common.jaxrs.GenericProvider
class com.ejgallo.finance.accountspayable.payments.errors.ThrowableExceptionMapper
class com.ejgallo.finance.accountspayable.payments.errors.NotFoundExceptionMapper
class com.ejgallo.finance.common.jaxrs.TemplateProvider
Aug 30, 2010 10:04:41 AM com.sun.jersey.server.impl.application.WebApplicationImpl initiate
INFO: Initiating Jersey application, version 'Jersey: 1.2 05/07/2010 02:11 PM'
We have marked the servlet to load on startup in our web.xml as well, but even when this is removed and the init-param " com.sun.jersey.config.property.packages" parameter is removed from web.xml it still initializes twice in Tomcat.
Perhaps this is just a Tomcat bug?
Thank you,
Travis Beech | Programmer Analyst |E&J Gallo Winery | 209-341-6108
-----Original Message-----
From: Paul Sandoz [mailto:Paul.Sandoz_at_oracle.com]
Sent: Monday, August 30, 2010 3:34 AM
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] adding a @Context annotated parameter using an InjectableProvider on WebSphere
On Aug 27, 2010, at 8:17 PM, Beech, Travis wrote:
> I apologize in advance for the length of this post, and if I have
> posted incorrectly to this list. I hope the information contained in
> this email is coherent enough to follow, if any clarification is
> required please let me know.
>
> We are having the same exact issue as Mark is having with a custom
> class that implements the InjectableProvider interface. I suspect
> that Mark is correct about the subtle difference in the classloader
> of WebSphere and Tomcat. However, I have been able to successfully
> get our application to work locally with RAD75 running a local
> WAS6.1.0.19 server, unfortunately our production, acceptance, and
> development server are running WAS6.1.0.9.
>
> Even with the difference in WAS versions I am still seeing a
> difference in package scanning with Jersey 1.2 between the WAS
> 6.1.0.19 and the WAS 6.1.0.9.
>
> Locally when I start my server this is what I see when the package
> scanning begins:
> [8/27/10 10:50:38:046 PDT] 00000013 PackagesResou I Scanning for
> root resource and provider classes in the packages:
> com.ejgallo.finance
> [8/27/10 10:50:40:089 PDT] 00000013 ScanningResou I Root resource
> classes found:
> class
> com.ejgallo.finance.accountspayable.payments.attachments.Attachments
> class com.ejgallo.finance.accountspayable.payments.mobile.Mobile
> class
> com.ejgallo.finance.accountspayable.payments.documents.ImageRequest
> class
> com.ejgallo.finance.accountspayable.payments.documents.DocumentRequest
> class com.ejgallo.finance.accountspayable.payments.admin.Reminders
> class
> com.ejgallo.finance.accountspayable.payments.workflow.WorkflowRequest
> class com.ejgallo.finance.accountspayable.payments.data.Data
> class
> com.ejgallo.finance.accountspayable.payments.invoice.HistoryRequest
> class
> com
> .ejgallo.finance.accountspayable.payments.invoice.PreferencesRequest
> class com.ejgallo.finance.accountspayable.payments.dialogs.Dialogs
> class
> com.ejgallo.finance.accountspayable.payments.invoice.InvoiceRequest
> class
> com.ejgallo.finance.accountspayable.payments.menu.inquiry.Inquiry
> class com.ejgallo.finance.accountspayable.payments.admin.Support
> [8/27/10 10:50:40:091 PDT] 00000013 ScanningResou I Provider
> classes found:
> class com.ejgallo.finance.common.jaxrs.GenericProvider
> class
> com
> .ejgallo
> .finance.accountspayable.payments.errors.ThrowableExceptionMapper
> class
> com
> .ejgallo
> .finance.accountspayable.payments.errors.ApplicationExceptionMapper
> class com.ejgallo.finance.common.jaxrs.BinaryContentProvider
> class
> com
> .ejgallo
> .finance.accountspayable.payments.errors.NotFoundExceptionMapper
> class com.ejgallo.finance.common.jaxrs.W3CDocumentProvider
> class com.ejgallo.finance.accountspayable.web.WebSessionInjector
> (This is our custom class that implements InjectableProvider
> class com.ejgallo.finance.common.jaxrs.TemplateProvider
>
> However, when deployed to the development server, the package
> scanning looks like this on server startup:
> [8/27/10 10:33:46:198 PDT] 00000027 PackagesResou I Scanning for
> root resource and provider classes in the packages:
> com.ejgallo.finance
> [8/27/10 10:33:46:490 PDT] 00000027 ScanningResou I Root resource
> classes found:
> class
> com
> .ejgallo.finance.accountspayable.payments.invoice.PreferencesRequest
> class
> com.ejgallo.finance.accountspayable.payments.documents.ImageRequest
> class com.ejgallo.finance.accountspayable.payments.data.Data
> class com.ejgallo.finance.accountspayable.payments.mobile.Mobile
> class
> com.ejgallo.finance.accountspayable.payments.documents.DocumentRequest
> class com.ejgallo.finance.accountspayable.payments.admin.Reminders
> class com.ejgallo.finance.accountspayable.payments.admin.Support
> class
> com.ejgallo.finance.accountspayable.payments.invoice.HistoryRequest
> class
> com.ejgallo.finance.accountspayable.payments.menu.inquiry.Inquiry
> class
> com.ejgallo.finance.accountspayable.payments.invoice.InvoiceRequest
> class
> com.ejgallo.finance.accountspayable.payments.attachments.Attachments
> class com.ejgallo.finance.accountspayable.payments.dialogs.Dialogs
> class
> com.ejgallo.finance.accountspayable.payments.workflow.WorkflowRequest
> [8/27/10 10:33:46:492 PDT] 00000027 ScanningResou I Provider
> classes found:
> class
> com
> .ejgallo
> .finance.accountspayable.payments.errors.NotFoundExceptionMapper
> class
> com
> .ejgallo
> .finance.accountspayable.payments.errors.ThrowableExceptionMapper
> class
> com
> .ejgallo
> .finance.accountspayable.payments.errors.ApplicationExceptionMapper
>
> The main difference here is that when deployed to the development
> server, the package scanning is limited in scope to the packages
> within the web application.
>
That is indeed a subtle difference between WLS versions.
> The following packages are contained in two separate libraries that
> exist in a common library folder and is bound to the application
> through a shared library reference in WAS.
> com.ejgallo.finance.common.jaxrs (This package contains other custom
> providers)
> com.ejgallo.finance.accountspayable.web (This package contains the
> WebSessionInjector class)
>
> When working locally these additional projects are bound to the web
> application as Java EE Module dependencies, so they look as if they
> exist in the WEB-INF/lib folder (This, I believe is the fundamental
> difference between our local development environments and our
> development server).
>
> I believe a work around that might work, which I have yet to
> attempt, is to move the WebSessionInjector class into a package
> within our web application because otherwise the package scanning
> just isn't registering the WebSessionInjector class on startup.
>
> As a side note related to this, one of the main differences I have
> noticed between start up of Tomcat and WebSphere is in this method:
>
> @Override
> protected void initiate(com.sun.jersey.api.core.ResourceConfig rc,
> com.sun.jersey.spi.container.WebApplication wa)
> {
> try
> {
> super.initiate( rc, wa );
> }
> catch( Throwable t )
> {
> t.printStackTrace();
> }
> };
>
> We are using a class that is a Servlet\Filter, so it extends
> ServletContainer and implements Filter, and when I override this
> method I notice that in Tomcat this initiate method is called twice
> on startup and succeeds both times whereas in WebSphere it is called
> once on start up and once when the Servlet\Filter is accessed for
> the first time. In WebSphere the first call (on start up) succeeds
> and the second call (on first access) fails with the following error:
>
The ServletContainer already implements Filter.
I cannot explain why initiate gets called twice, it implies that
servlet initiation occurs twice as well and you should see duplicate
information in the logs when Jersey initiates.
Paul.
> com.sun.jersey.api.container.ContainerException: Method, public
> org.w3c.dom.Document
> com
> .ejgallo
> .finance
> .accountspayable
> .payments
> .documents
> .DocumentRequest
> .getDocumentFoldersData
> (com.ejgallo.finance.accountspayable.web.WebSession), annotated with
> GET of resource, class
> com
> .ejgallo.finance.accountspayable.payments.documents.DocumentRequest,
> is not recognized as valid Java method annotated with @HttpMethod.
>
> And the method that it is complaining about is declared as follows,
> note this method contains "@Context WebSession" which is supposed to
> be handled by our custom WebSessionInjector class. I will get the
> same error in WebSphere for every method that contains "@Context
> WebSession".
>
> @GET
> @Path( "/folders/documentfolders" )
> @Produces( MediaType.TEXT_XML )
> public Document getDocumentFoldersData( @Context WebSession session )
> {...}
>
> Travis Beech | Programmer Analyst |E&J Gallo Winery | 209-341-6108
>
>
> -----Original Message-----
> From: Paul Sandoz [mailto:Paul.Sandoz_at_oracle.com]
> Sent: Thursday, August 26, 2010 7:23 AM
> To: users_at_jersey.dev.java.net
> Subject: Re: [Jersey] adding a @Context annotated parameter using an
> InjectableProvider on Websphere
>
>
> On Aug 26, 2010, at 3:43 PM, Mark Birenbaum wrote:
>
>> Oops, missed that detail. We're using the @Provider annotation.
>>
>> @Provider
>> public class LocaleProvider
>> implements InjectableProvider<Context, Type> {
>> ...
>>
>> I figure it's probably some classloader issue and the LocaleProvider
>> isn't being seen in the same context as jersey for some reason,
>> although since we have it all as one big war file, I can't imagine
>> what the issue would be. If it was broken in both environments I'd
>> assume our configuration was messed up, but only broken in websphere
>> makes me think there's some subtly to the way jersey looks for
>> providers that I need to be concerned with.
>>
>
> I cannot recall exactly which version of Jersey but i do recall there
> were some issues with scanning on WebSphere. They may have been
> similar to those for WebLogic which were fixed in Jersey 1.1.5 and
> Jersey 1.2).
>
> What is your web.xml?
>
> Paul.
>
>>
>>> From: Paul Sandoz <Paul.Sandoz_at_oracle.com>
>>> To: users_at_jersey.dev.java.net
>>> Date: Thu, 26 Aug 2010 10:31:52 +0200
>>> Subject: Re: [Jersey] adding a @Context annotated parameter using
>>> an InjectableProvider on Websphere
>>> Hi Mark,
>>>
>>> How are you deploying and registering your LocaleProvider on
>>> WebSphere?
>>>
>>> I suspect when you deploy on WebSphere the LocaleProvider is not
>>> getting registered.
>>>
>>> Paul.
>>>
>>> On Aug 25, 2010, at 10:47 PM, Mark Birenbaum wrote:
>>>
>>>> We've added an InjectableProvider to our system to allow the
>>>> addition
>>>> of Locale to resource methods. Our provider looks like this:
>>>>
>>>>
>>>>
>>>> public class LocaleProvider
>>>> implements InjectableProvider<Context, Type> {
>>>>
>>>> ...
>>>> public Injectable<Locale> getInjectable(ComponentContext
>>>> ic, Context
>>>> a, Type c) { ...
>>>>
>>>>
>>>> And our use of it looks like this:
>>>>
>>>> @GET
>>>> @Produces(APPLICATION_JSON)
>>>> public JSONArray getTasksAsJsonArray(@Context UriInfo
>>>> uriInfo,
>>>> @QueryParam("template") boolean isTemplate,
>>>> @Context Locale locale)
>>>> throws JSONException { ...
>>>>
>>>>
>>>>
>>>>
>>>> Works great in tomcat. Blows up in websphere like this:
>>>>
>>>> Exception:
>>>> com.sun.jersey.api.container.ContainerException: Method, public
>>>> javax.ws.rs.core.Response
>>>> com.bps.iproject.jersey.resources.TasksResource.
>>>> getTasksAsJsonArray
>>>> (javax.ws.rs.core.UriInfo,boolean,java.util.Locale), annotated with
>>>> GET of resource, class
>>>> com.bps.iproject.jersey.resources.TasksResource, is not recognized
>>>> as
>>>> valid Java method annotated with @HttpMethod.
>>>> at
>>>> com
>>>> .sun
>>>> .jersey
>>>> .server
>>>> .impl
>>>> .model.method.ResourceHttpMethod.<init>(ResourceHttpMethod.java:92)
>>>> at
>>>> com
>>>> .sun
>>>> .jersey
>>>> .server
>>>> .impl
>>>> .model.method.ResourceHttpMethod.<init>(ResourceHttpMethod.java:69)
>>>> at
>>>> com
>>>> .sun
>>>> .jersey
>>>> .server
>>>> .impl
>>>> .model.ResourceClass.processSubResourceMethods(ResourceClass.java:
>>>> 258)
>>>> at
>>>> com
>>>> .sun
>>>> .jersey.server.impl.model.ResourceClass.<init>(ResourceClass.java:
>>>> 128)
>>>> at
>>>> com
>>>> .sun
>>>> .jersey
>>>> .server
>>>> .impl
>>>> .application
>>>> .WebApplicationImpl.newResourceClass(WebApplicationImpl.java:348)
>>>> at
>>>> com
>>>> .sun
>>>> .jersey
>>>> .server
>>>> .impl
>>>> .application
>>>> .WebApplicationImpl.getResourceClass(WebApplicationImpl.java:321)
>>>> at
>>>> com
>>>> .sun
>>>> .jersey
>>>> .server
>>>> .impl
>>>> .application
>>>> .WebApplicationImpl.processRootResources(WebApplicationImpl.java:
>>>> 807)
>>>> at
>>>> com
>>>> .sun
>>>> .jersey
>>>> .server
>>>> .impl
>>>> .application.WebApplicationImpl.initiate(WebApplicationImpl.java:
>>>> 590)
>>>> at
>>>> com
>>>> .sun
>>>> .jersey
>>>> .spi
>>>> .spring
>>>> .container.servlet.SpringServlet.initiate(SpringServlet.java:78)
>>>> at com.sun.jersey.spi.container.servlet.ServletContainer
>>>> $InternalWebComponent.initiate(ServletContainer.java:242)
>>>> at
>>>> com
>>>> .sun
>>>> .jersey.spi.container.servlet.WebComponent.load(WebComponent.java:
>>>> 449)
>>>> at
>>>> com
>>>> .sun
>>>> .jersey.spi.container.servlet.WebComponent.init(WebComponent.java:
>>>> 169)
>>>> at
>>>> com
>>>> .sun
>>>> .jersey
>>>> .spi.container.servlet.ServletContainer.init(ServletContainer.java:
>>>> 281)
>>>> at
>>>> com
>>>> .sun
>>>> .jersey
>>>> .spi.container.servlet.ServletContainer.init(ServletContainer.java:
>>>> 442)
>>>> at javax.servlet.GenericServlet.init(GenericServlet.java:256)
>>>> at
>>>> com
>>>> .ibm
>>>> .ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:
>>>> 227)
>>>>
>>>>
>>>>
>>>> If I change the Locale to one of the standard @Context options
>>>> (i.e.,
>>>> HttpServletRequest) I have no issues. So to work around this I'm
>>>> changing all our methods that take Locale to take the request
>>>> instead.
>>>> But I would like to know what I'm doing wrong,.
>>>>
>>>> We're using spring and Jersey 1.0.3.
>>>>
>>>> Any thoughts?
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
For additional commands, e-mail: users-help_at_jersey.dev.java.net