Hi Naresh,
Sorry i am a bit slow today, have a bad cold. I mis-read your email
again!
In your init params you need to declare the class of the resource
config implementation to use;
initParams.put(
ServletContainer.RESOURCE_CONFIG_CLASS,
ClassNamesResourceConfig.class.getName());
initParams.put(
ClassNamesResourceConfig.PROPERTY_CLASSNAMES,
"com.sun.jersey.qe.tests.core.MyResource;");
The reason why they work fine when deployed to GF is the default
configuration, namely scanning in WEB-INF/lib and WEB-INF/classes works.
Paul.
On Oct 13, 2009, at 1:58 PM, Naresh wrote:
> Paul Sandoz wrote:
>>
>> On Oct 13, 2009, at 1:03 PM, Naresh wrote:
>>
>>> Paul Sandoz wrote:
>>>>
>>>> On Oct 13, 2009, at 12:12 PM, Naresh wrote:
>>>>
>>>>> Hi Paul,
>>>>>
>>>>> that commit had fixed the problem with transformation.
>>>>>
>>>>
>>>> Ah, got the wrong end of the stick!
>>>>
>>>>
>>>>> But, in my case I'm working with WebAppDescriptor (test), and
>>>>> see that the property PROPERTY_CLASSNAMES is ignored and
>>>>> ClasspathResourceConfig is initialized when I try using the
>>>>> Grizzy Web test container type.
>>>>>
>>>>
>>>> When using the Web layer it attempts to look in certain well
>>>> known directories of the Web app, namely WEB-INF/lib and WEB-INF/
>>>> classes. The trouble is this approach is not very portable, so we
>>>> might be hitting an issue w.r.t embedded GF and a limitation in
>>>> Grizzly's servlet support.
>>> Agree.
>>>>
>>>> It may also be related to the way the tests are built, do the
>>>> following directories exist?
>>> No. They don't exist.
>>
>> Ah, that is the problem :-)
>>
>> Do they exist in another location?
> No.
>>
>> I do not know the structure of the tests but if these tests do not
>> have standard layout as if they were deployed to a web app server
>> then the default class scanning support (when no init-params are
>> supplied) will not work.
> But the tests run fine when the app is deployed to GlassFish.
>
> Also, I'm specifying the init-params. Here is an extract from the
> Test class:
>
> ------------------------------------------------------------------------------------------------------
> static {
> initParams = new HashMap<String, String>();
> // some bug here -- this is not working with GrizzlyWeb and
> EmbeddedGF
> initParams.put(ClassNamesResourceConfig.PROPERTY_CLASSNAMES,
> "com.sun.jersey.qe.tests.core.MyResource;");
> initParams.put(ResourceConfig.FEATURE_DISABLE_WADL, "true");
> }
>
> public MyResourceTest() {
> super(new WebAppDescriptor.Builder(initParams)
> .contextPath("coretest2")
> .servletClass
> (com.sun.jersey.spi.container.servlet.ServletContainer.class)
> .build()); }
> ------------------------------------------------------------------------------------------------------
>
> Is it a requirement that if we are setting the init-param
> ClassNamesResourceConfig.PROPERTY_CLASSNAMES, we also specify the
> Classpath where to scan for the resource classes (which I believe is
> not the case)?
>
> -Naresh
>
>>
>>
>>>>
>>>> /home/naresh/workspace/tango/qe-tests/jersey-tests/core-tests/
>>>> coretest2/WEB-INF/lib
>>>> /home/naresh/workspace/tango/qe-tests/jersey-tests/core-tests/
>>>> coretest2/WEB-INF/classes
>>>>
>>>>
>>>>> The test in the attached zip file shows the behavior, just unzip
>>>>> it and do *mvn test*.
>>>>>
>>>>
>>>> I have no time to investigate at the moment, can you debug into
>>>> Jersey and try and find the reason why the following is logged?
>>> Sure. I'll try to do that. Is there a way where we can set the log
>>> levels to FINEST, so that we can see what really is happening
>>> internally?
>>>
>>
>> You need to read up on JDK logging to do that, but i am not sure it
>> will help much.
>>
>> If you can load up the test in NBs and run it in debug mode that
>> might be easier.
>>
>> Paul.
>>
>> ---------------------------------------------------------------------
>> 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
>