Seems it is not as trivial as I initially thought. After doing the proposed
changes, the simple-war is redeployed successfully. I then went ahead and
tested this on a more complex WAB but got an exception during servlet
initialization which indicated that the "osgi-bundlecontext" servlet
context attribute is not available.
Researching this further, I found out that Tomcat would re-create the
ServletContext instance when reloading a web application. Gemini Web
however is not coded to expect that ServletContext will change. In fact, it
assumes that the web application lifecycle is bound entirely to the
corresponding bundle's lifecycle, so it does not assume that the web
application might be controlled from Tomcat at all.
This seems like a general design issue of Gemini Web and solving it might
require changing the its architecture. I would be interested to know if
this issue has already been discussed and whether you think it makes sense
to improve Gemini Web to handle this use case.
Regards,
Detelin
On Wed, Apr 2, 2014 at 3:57 PM, <[email protected]> wrote:
> Hello Gemini Web devs,
> We are using Gemini Web with Equinox and we had to update our test setup
> recently to reload a web application, while Tomcat is running. We ended up
> using Tomcat JMX for that, but it turned out a NPE is thrown when the web
> application is re-started. The issue is reproducible with any web
> application bundle. To reproduce it with latest Gemini Web 2.2.2 and the
> "simple-war.war" web application, follow these steps:
>
> 1. Install the war in Equinox:
>
> osgi> install file:simple-war.war
>
> 2. Run jconsole JDK tool and connect to the Equinox process
>
> 3. Open the "//localhost/simple-war" node under "Catalina/WebModule",
> navigate to the operations and execute "reload"
>
> 4. Observe the following exception appears in Equinox console:
>
> org.apache.catalina.core.StandardContext reload
> SEVERE: Exception starting Context with name [/simple-war]
> org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/simple-war]]
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
> at
> org.apache.catalina.core.StandardContext.reload(StandardContext.java:3926)
> ...
> Caused by: org.apache.catalina.LifecycleException: Failed to start
> component
> [org.eclipse.gemini.web.tomcat.internal.loading.BundleWebappLoader@6638e53
> ]
> ...
> Caused by: java.lang.NullPointerException
> at
> org.eclipse.gemini.web.tomcat.internal.loading.BundleClassPathURLExtractor.extractBundleClassPathURLs(BundleClassPathURLExtractor.java:37)
> at
> org.eclipse.gemini.web.tomcat.internal.loading.BundleWebappClassLoader.addBundleClassPathURLs(BundleWebappClassLoader.java:101)
> at
> org.eclipse.gemini.web.tomcat.internal.loading.BundleWebappClassLoader.<init>(BundleWebappClassLoader.java:77)
> at
> org.eclipse.gemini.web.tomcat.internal.loading.BundleWebappLoader.createClassLoader(BundleWebappLoader.java:88)
> at
> org.eclipse.gemini.web.tomcat.internal.loading.BundleWebappLoader.startInternal(BundleWebappLoader.java:169)
>
> I checked the sources and it seems that the BundleWebappClassLoader nulls
> out the "bundle" and "classLoaderCustomizer" fields upon stop:
>
>
> http://git.eclipse.org/c/gemini.web/org.eclipse.gemini.web.gemini-web-container.git/tree/org.eclipse.gemini.web.tomcat/src/main/java/org/eclipse/gemini/web/tomcat/internal/loading/BundleWebappLoader.java#n212
>
> These are initialized in the constructor and since a new
> BundleWebappClassLoader instance is not created when starting the context
> after a stop, these remain null and ultimately cause the exception.
>
> It seems like the fix would be easy - removing the respective null
> assigments so that the "bundle" and "classLoaderCustomizer" instances are
> preserved. If there are no side effects and there is no specific reason for
> this piece of code, I would open a defect and attach a patch, but first I
> wanted to get your opinion on this. Does this sound reasonable?
>
> Thanks,
> Detelin
>
>
>
>
>
_______________________________________________
gemini-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/gemini-dev
