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.
But also we need to move to the latest GF once the maven issues are
fixed.
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
>