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