Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Virgo » Best Practice for extending the in-built Tomcat bundle(Best Practice for extending the in-built Tomcat bundle)
Best Practice for extending the in-built Tomcat bundle [message #659655] Mon, 14 March 2011 22:28 Go to next message
Matt Fellows is currently offline Matt Fellows
Messages: 28
Registered: February 2011
Junior Member
Hi guys,

I'm wanting to use Terracotta with Virgo for replicating Web Sessions [1] and distributed caching with EHCache.

Basically, you install a Value in a Tomcat <Context> configuration element and it pipes the session data into Terracotta to manage, which requires the Terracotta JARs to be on the classpath for Tomcat and Terracotta requires access to the Tomcat libs (i.e. org.apache.catalina.*)

To achieve this I understand there are a few options:

1. Create bundle's out of the Terracotta libraries, install into Equinox and modify the Tomcat bundle to import those libraries
2. Create bundle's out of the Terracotta libraries, install into Equinox and create a bundle fragment
3. Adding the libs to one of the booting classpaths of the entire system (seems like a worst case scenario).

4. + 5. The same as the first 2, but embed the libraries directly into the bundles/fragments.

I was wondering if there is a best practice\recommendation around modifying base functionality? The fragment seems like the most elegant approach, but I'm not sure if it will work how I expect.

Any advice would be much appreciated.

Cheers,
Matt

1. http://www.terracotta.org/documentation/web-sessions-install .html#50499643_92283
Re: Best Practice for extending the in-built Tomcat bundle [message #659676 is a reply to message #659655] Tue, 15 March 2011 04:38 Go to previous messageGo to next message
Glyn Normington is currently offline Glyn Normington
Messages: 1222
Registered: July 2009
Senior Member
I would avoid options 1 and 3. Editing Virgo bundles may backfire and will definitely be a pain when you want to upgrade. Adding boot delegation is a pretty blunt instrument as it potentially has a global effect. It should only be used if a more elegant solution cannot be found.

So option 2 where the fragment consists of just a manifest with suitable imports is what I would recommend. I would also recommend placing the fragment in repository/usr so that when the Tomcat bundle is deployed, the fragment will be automatically installed by Virgo. That will minimise your configuration requirements.
Re: Best Practice for extending the in-built Tomcat bundle [message #660120 is a reply to message #659655] Wed, 16 March 2011 18:49 Go to previous messageGo to next message
Matt Fellows is currently offline Matt Fellows
Messages: 28
Registered: February 2011
Junior Member
Apologies in the delay in getting back to you - it seems to be really difficult to login to the forums (I login, then it takes me back to the login page endlessly. Happens in all browsers).

I've given option 2 a go, but was only able to get it to work by wrapping the 2 Terracotta JARs into the Fragment itself. I was unable to use the Bnd tool to wrap the Jars into separate bundles and install them separately as when I do i get the following exception installing the bundle:

osgi>  install file:/Users/mattfellows/development/springsource/com.melbourneit.web.terracotta-session/src/main/resources/META-INF/tmp/com.melbourneit.web.terracotta-session-1.1.1.jar
Bundle id is 122

osgi> start 122
org.osgi.framework.BundleException: Unexpected resolution exception.
	at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:328)
	at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299)
	at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:291)
	at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:253)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:155)
	at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:155)
	at org.eclipse.osgi.framework.internal.core.FrameworkConsole.runConsole(FrameworkConsole.java:140)
	at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:104)
	at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.NullPointerException
	at org.eclipse.virgo.kernel.osgi.region.hook.RegionResolverHook.filter(RegionResolverHook.java:146)
	at org.eclipse.virgo.kernel.osgi.region.hook.RegionResolverHook.allowImportedPackages(RegionResolverHook.java:120)
	at org.eclipse.virgo.kernel.osgi.region.hook.RegionResolverHook.getAllowed(RegionResolverHook.java:111)
	at org.eclipse.virgo.kernel.osgi.region.hook.RegionResolverHook.filterMatches(RegionResolverHook.java:69)
	at org.eclipse.osgi.framework.internal.core.CoreResolverHookFactory$CoreResolverHook.filterMatches(CoreResolverHookFactory.java:169)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveImport(ResolverImpl.java:1436)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveBundle(ResolverImpl.java:1221)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles0(ResolverImpl.java:650)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles(ResolverImpl.java:547)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolve(ResolverImpl.java:437)
	at org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateImpl.java:481)
	at org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateImpl.java:559)
	at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:249)
	at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.resolveBundles(PackageAdminImpl.java:191)
	at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:322)
	... 12 more
Nested Exception:


I did a small amount of debugging and it seems that if I remove all import-package statements of the wrapped Jar it will start; I believe I may have uncovered an issue\feature of the 3.0.0.M2 release.

At first I thought it might have been my configuration, however I've replicated this on a clean install of M02.

Installing and starting this bundle in the 2.1.0.RELEASE works fine.

I've attached the bundle in question (com.melbourneit.web.terracotta-session-1.1.1.jar) that's not working, however just to be sure it wasn't specific to that package, I also wrapped another Jar which had the same symptoms. For now, that bundle will need to be embedded in the WAR. I'm unsure as to whether it's a Bnd issue or not.

Should I raise this as a bug in Bugzilla?

Cheers,
Matt
Re: Best Practice for extending the in-built Tomcat bundle [message #660153 is a reply to message #660120] Thu, 17 March 2011 02:07 Go to previous messageGo to next message
Hristo Iliev is currently offline Hristo Iliev
Messages: 156
Registered: May 2010
Location: Sofia, Bulgaria
Senior Member

I downloaded the attachment but it turns out that the content is actually HTML with embedded ZIP file. I've tried with FF4 and IE9 with the same result Shocked

Putting this thing in Virgo's pickup produced ZIPException, while install file:/... gave me:

104 INSTALLED unknown_0.0.0 [104]

I suspect that the problem may be with the forum, but can you please check if the bundle on your side starts with "PK"?

After I fixed the bundle it turned out that pickup directory successfully deployed the bundle, while install command produced the same NPE:

Nested Exception:
java.lang.NullPointerException
at org.eclipse.virgo.kernel.osgi.region.hook.RegionResolverHook .filter(RegionResolverHook.java:146)
at org.eclipse.virgo.kernel.osgi.region.hook.RegionResolverHook .allowImportedPackages(RegionResolverHook.java:120)
at org.eclipse.virgo.kernel.osgi.region.hook.RegionResolverHook .getAllowed(RegionResolverHook.java:111)
at org.eclipse.virgo.kernel.osgi.region.hook.RegionResolverHook .filterMatches(RegionResolverHook.java:69)
at org.eclipse.osgi.framework.internal.core.CoreResolverHookFac tory$CoreResolverHook.filterMatches(CoreResolverHookFactory. java:169)
at org.eclipse.osgi.internal.module.ResolverImpl.resolveImport( ResolverImpl.java:1436)
at org.eclipse.osgi.internal.module.ResolverImpl.resolveBundle( ResolverImpl.java:1221)
at org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles 0(ResolverImpl.java:650)
at org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles (ResolverImpl.java:547)
at org.eclipse.osgi.internal.module.ResolverImpl.resolve(Resolv erImpl.java:437)
at org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateIm pl.java:481)
at org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateIm pl.java:559)
at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.do ResolveBundles(PackageAdminImpl.java:249)
.................


In the end I think this is a bug, so please report it. Until it is fixed you can use the hot deploy via pickup.

Regards,
Hristo Iliev

[Updated on: Thu, 17 March 2011 02:33]

Report message to a moderator

Re: Best Practice for extending the in-built Tomcat bundle [message #660188 is a reply to message #660153] Thu, 17 March 2011 05:46 Go to previous messageGo to next message
Glyn Normington is currently offline Glyn Normington
Messages: 1222
Registered: July 2009
Senior Member
Hi Matt

I would be grateful if you could re-test the NPE on Virgo milestone 3, which will be published today, before raising the bug.

I'm checking with Hristo to see whether he has performed this test.

Regards,
Glyn
Re: Best Practice for extending the in-built Tomcat bundle [message #660239 is a reply to message #660188] Thu, 17 March 2011 10:13 Go to previous messageGo to next message
Hristo Iliev is currently offline Hristo Iliev
Messages: 156
Registered: May 2010
Location: Sofia, Bulgaria
Senior Member

Seems install works fine in 3.0.0.M03
Re: Best Practice for extending the in-built Tomcat bundle [message #660245 is a reply to message #660239] Thu, 17 March 2011 10:32 Go to previous messageGo to next message
Glyn Normington is currently offline Glyn Normington
Messages: 1222
Registered: July 2009
Senior Member
Thanks Hristo!
Re: Best Practice for extending the in-built Tomcat bundle [message #660336 is a reply to message #659655] Thu, 17 March 2011 21:02 Go to previous messageGo to next message
Matt Fellows is currently offline Matt Fellows
Messages: 28
Registered: February 2011
Junior Member
Thanks Hristo, that's great news.

I'll do a bit more analysis at my end to see if all of the other wrapped Jars continue to work, if not will put through a bug report.

Much appreciated guys!

Cheers,
Matt
[Resolved] Re: Best Practice for extending the in-built Tomcat bundle [message #662515 is a reply to message #659655] Wed, 30 March 2011 17:46 Go to previous messageGo to next message
Matt Fellows is currently offline Matt Fellows
Messages: 28
Registered: February 2011
Junior Member
Just confirming that Milestone 3 has fixed the issue that I was having with wrapping JARs, and the Tomcat bundle fragment worked a treat.

Thanks for you help and keep up the great work!
Re: [Resolved] Re: Best Practice for extending the in-built Tomcat bundle [message #662576 is a reply to message #662515] Thu, 31 March 2011 04:13 Go to previous messageGo to next message
Glyn Normington is currently offline Glyn Normington
Messages: 1222
Registered: July 2009
Senior Member
We appreciate the feedback. Thanks Matt.
Re: [Resolved] Re: Best Practice for extending the in-built Tomcat bundle [message #736477 is a reply to message #662515] Thu, 13 October 2011 23:14 Go to previous messageGo to next message
Matt Lewter is currently offline Matt Lewter
Messages: 1
Registered: October 2011
Junior Member
Hello everyone,

I was hoping someone could provide just a little more detail on the subject of getting this all wired up.

As I understand it:

1. bundle up the necessary terracotta jars & add them to the repository
2. create a bundle fragment that imports the appropriate terracotta packages and tie that into tomcat.
3. Configure as normal (add appropriate valve to context.xml, etc.)

At the moment, the part I'm having the most trouble with is number 2. Exactly which Virgo bundle should be the host, etc.? I've attempted making the catalina bundle the host to my fragment, placed it in the repository/ext directory, but the fragment never resolves with the host.

Any help/insight would be greatly appreciated. An example MANIFEST would be even better! Very Happy

Thanks in advance,

-ML
Re: [Resolved] Re: Best Practice for extending the in-built Tomcat bundle [message #736895 is a reply to message #736477] Fri, 14 October 2011 08:46 Go to previous message
Violeta Georgieva is currently offline Violeta Georgieva
Messages: 236
Registered: October 2010
Senior Member
Hi,

I prepared one very simple example - see attachment.

The basic thing is:

- if you will add additional (Valves, Listeners etc.) configuration to tomcat-server.xml (on Engine/Host level) then you need to attach the fragment to com.springsource.org.apache.catalina bundle
- if you will add additional configuration to global context.xml for example, then you need to attach the fragment to org.eclipse.gemini.web.tomcat bundle

Hope this helps

Regards
Violeta
  • Attachment: plugins.zip
    (Size: 2.51KB, Downloaded 83 times)
Previous Topic:JNLP on Virgo Web Server
Next Topic:virgo start ... hang ...
Goto Forum:
  


Current Time: Sat Aug 30 22:38:59 EDT 2014

Powered by FUDForum. Page generated in 0.02497 seconds