users@jersey.java.net

Re: [Jersey] An issue seen when running tests on a WebApp using the Grizzly container

From: Srinivas Naresh Bhimisetty <Srinivas.Bhimisetty_at_Sun.COM>
Date: Mon, 10 Nov 2008 17:49:49 +0530

Hi,

   finally I could get the tests to run with Embedded Glassfish, Grizzly
and HTTPServer. Thanks to the 'profiles' feature of maven.
Also, I could add some encapsulation details as suggested by Paul.
Attached is a zip file which contains two modules. One being the general
utility classes which could be used across different modules, the other
being the helloworld sample which I had picked from the samples. Could
somebody please have a look and suggest me if there is something which
needs to be changed or added?

Thanks,
Naresh

Srinivas Naresh Bhimisetty wrote:
> Jakub Podlesak wrote:
>> On Fri, Nov 07, 2008 at 09:46:04AM +0100, Paul Sandoz wrote:
>>
>>> On Nov 7, 2008, at 9:41 AM, Srinivas Naresh Bhimisetty wrote:
>>>
>>>
>>>> Found the cause -
>>>>
>>>> Looks like maven loads a class from the repository in the order in
>>>> which the dependencies are listed in the POM file. In the POM I
>>>> have added the dependency for the Grizzly server at a point later
>>>> than the Embedded GlassFish's dependency, and the class is loaded
>>>> from the embedded glassfish jar which is an older version one, and
>>>> thus the problem.
>>>>
>>>> I tried putting the dependency for Grizzly before Glassfish's and
>>>> it worked fine, however, this time the test failed to run with
>>>> the Embedded Glassfish :-( .
>>>>
>>>>
>>> Ideally we should try and do some isolation in terms of maven
>>> dependency profiles, so that when a test is execute the profile is
>>> declared or determined from the test itself. Jakub knows more about
>>> that.
>>>
>>
>> Naresh, you can look at the [jersey-tests] module, where
>> [bundle-dependency] profile is used to define a different set of
>> dependencies.
>> If you invoke maven with -Pbundle-dependency parameter, the other
>> set will be used. You can introduce similar profiles for every
>> container you want to test on.
>>
>>
>>> But also we need to move to the latest GF once the maven issues are
>>> fixed.
>>>
>>
>> One issue is filed for glassfish-plugin [1]. I reckon, once this is
>> resolved, the latest embedded GF will work fine for sure (maybe it
>> already works,
>> but the docs are lacking in this area, and it is really time consuming
>> to find out the proper configuration).
>>
> Thanks Jakub. I shall try that.
>
> -Naresh
>> ~Jakub
>>
>> [1]https://glassfish.dev.java.net/issues/show_bug.cgi?id=6710
>>
>>
>>> Paul.
>>>
>>>
>>>> -Naresh
>>>>
>>>> Paul Sandoz wrote:
>>>>
>>>>> On Nov 7, 2008, at 5:45 AM, Srinivas Naresh Bhimisetty wrote:
>>>>>
>>>>>
>>>>>> Hi Paul,
>>>>>>
>>>>>> Paul Sandoz wrote:
>>>>>>
>>>>>>> Hi Naresh,
>>>>>>>
>>>>>>> Tests in the jersey-tests module and the samples work fine
>>>>>>> using the same versions. Jersey would fail to build which such
>>>>>>> an error as reported. It is as if you are picking up a
>>>>>>> different grizzly implementation.
>>>>>>>
>>>>>> Yes, ideally it should have worked as it does with the samples
>>>>>> and the jersey-tests, for I have picked up the dependency from
>>>>>> one of those samples, but I do not understand why its behaving
>>>>>> this way.
>>>>>>
>>>>> Perhaps you can try:
>>>>>
>>>>> java -verbose:class
>>>>>
>>>>> I cannot recall if it tells you from which location classes are
>>>>> loaded, but it might...
>>>>>
>>>>>
>>>>>
>>>>>>> BTW i hope you are going to encpasulate the if/else if/else
>>>>>>> loop as separate classes. For example there is the direct
>>>>>>> Grizzly container, if you need to support that in your current
>>>>>>> design you will have to add another else if statement to all
>>>>>>> blocks. It is better to encapsulate the code into separate
>>>>>>> classes with a common interface.
>>>>>>>
>>>>>> I actually plan to break it up into classes with the common
>>>>>> interface. I thought I will get a working model and then I can
>>>>>> do so, but then this error gave me a halt. Anyway, I shall do it
>>>>>> now.
>>>>>>
>>>>>>
>>>>> Great. IMHO i recommend doing that that earlier rather than later
>>>>> in the process as it helps you better understand the
>>>>> abstractions, and with refactorng tools it is really easy to
>>>>> change things. Also using Map as an associative function is great
>>>>> way to avoid a "bootstrap" if/else if/else block.
>>>>>
>>>>> 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
>