Ludovic Champenois wrote:
> Sahoo wrote:
>> Ludo,
>>
>> Ludovic Champenois wrote:
>>> Hi,
>>> I am resuming my work on running a full GF V3 Prelude server
>>> embedded inside the Eclipse IDE.
>>>
>>> This IDE already defines a javax.servlet bundle (but it is 2.4
>>> version) and it uses it.
>>> GF V3 needs servlet 2.5.
>>>
>>> I can start a V3 Prelude server inside the Eclipse VM as OSGI, but
>>> at deployment tine of a web app, I see this error:
>>>
>>> LifecycleException: java.lang.ClassCastException:
>>> org.apache.jasper.servlet.JspServlet cannot be cast to
>>> javax.servlet.Servlet
>>> at
>>> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4926)
>>>
>>> at
>>> org.apache.catalina.core.StandardContext.start(StandardContext.java:5313)
>>>
>>> at com.sun.enterprise.web.WebModule.start(WebModule.java:381)
>>>
>>>
>>> telling me that our V3 runtime might be using the servlet jar from
>>> Eclipse and not from V3.
>> I still don't understand why that should cause a ClassCastException
>> unless Equinox is not detecting an inconsistent class space.
> Well, I talked to Richard on the subject yesterday, and apparently,
> OSGi runtime is returning the correct jar (i.e 2.4 which is already
> loaded and used by Eclipse) whenever a new module (from V3) is
> requesting to import the javax.servlet package without a precise
> version number.
> So we need to be more specific in what we ask for since this is really
> a environement issue.
The point Ludo is making is correct, which is if versions are specified
then resolve ordering becomes important, because any bundles asking for
servlet will get wired to the existing "in use" servlet package first,
which could be the incorrect version. However, once the newer version
becomes "in use", then all imports should resolve to it, since it is the
highest version.
Sahoo's question is valid, though, but I don't know the answer to it.
These are the likely answers:
1. There could be a bug in Equinox where it is not detecting a
constraint violation.
2. There could be incomplete "uses" metadata in the bundles involved.
3. There could be code that uses reflective means to pass around
instances, not knowing they have different types.
My bet is on (2), but I definitely don't know for certain, that is just
a guess.
-> richard
> In our pure V3+Felix environement, nobody defines or use an old
> version for javax.servlet so the runtime returns the correct bundle...
> Not true in an Eclipse environment.
> I guess it would become the same if one day we would like to run in
> the same VM 2 FlassFish servers (1 for Prelude Java EE 5) and one for
> Java EE 6.
> Not likely scenario, (or maybe it is with out extensible containers
> design where we could offer different spec level per container?) but...
>
>>>
>>> Searching for javax.servlet inside all of our pom files, I can see
>>> some of the pom files not defining the version number for importing
>>> javax.servlet, so these modules would get the jar from eclipse,
>>> hence the wrong version...
>>>
>>> So check your manifest files/ pom files and if you see a import
>>> package of javax.servlet without a 2.5 version, it means that the
>>> dependency is not correctly defined.
>>>
>>> I see this in the 3 jmx poms (client common server), servlet.jsp,,
>>> jsp.jstl, websecurity, grizzly-optional, and maybe others...
>>>
>>> There might be other java ee apis dependencies (servlet.http,
>>> ...,....,...) which are not correctly defined.
>>>
>> I am taking care of all the API jars to have proper dependencies. The
>> changes have been put back, but rest of the build system is not using
>> it. I am in the process of making the necessary changes in the build
>> system. That will improve the situation. I will drop you an email
>> once I am done.
> You rock!
>
> Ludo
>> Thanks,
>> Sahoo
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>