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.
> 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.
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?
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
>