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).
~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
>
--
http://blogs.sun.com/japod