Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [gemini-dev] NPE when reloading a WAB
Hi,


I'll see what we can do in order to support this scenario.
However I'll recommend you to use Gemini Management as it's purpose is to provide management for the bundles via JMX.

Regards,
Violeta


2014-04-03 17:14 GMT+03:00 michael keith <michael.keith@xxxxxxxxxx>:
Hi Detelin,

Thanks very much for the information.
Would it possible to enter a bug report for this? That way your history and input is properly captured and the Gemini Web maintainers can track it.

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Gemini.Web

Thanks,
-Mike


On 03/04/2014 9:21 AM, detelinyordanov@xxxxxxxxx wrote:
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, <detelinyordanov@xxxxxxxxx> 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)

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
gemini-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gemini-dev


_______________________________________________
gemini-dev mailing list
gemini-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gemini-dev


Back to the top