On Oct 13, 2009, at 5:49 PM, Naresh wrote:
> Hi Paul,
>
> Paul Sandoz wrote:
>> Hi Naresh,
>>
>> Sorry i am a bit slow today,
> thats okay.
>> have a bad cold.
> Wish you get better soon.
Thanks!
>> 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());
> Adding this initParam value did the trick.
>
> But, I'm kind of confused why it was working fine with LW Grizzly
> and HTTPServer without using this.
>
I think that may depend on the transform from the Web to Low-level
description.
> And also, with GrizzlyWeb test container type, it just worked fine
> for the other resource config types like PackagesResourceConfig or
> ClasspathResourceConfig, without having to add the init-param value
> for ServletContainer.RESOURCE_CONFIG_CLASS.
>
> Am I missing something basic here?
>
Read the JavaDoc of ServletContainer:
https://jersey.dev.java.net/nonav/apidocs/1.1.2-ea/jersey/com/sun/jersey/spi/container/servlet/ServletContainer.html
Paul.
> Thanks,
> Naresh
>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>