Skip to main content


Eclipse Community Forums

      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
Eclipse UserFriend
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
Eclipse UserFriend
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
Eclipse UserFriend
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
Eclipse UserFriend
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] by 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
Eclipse UserFriend
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
Eclipse UserFriend
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
Eclipse UserFriend
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
Eclipse UserFriend
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
Eclipse UserFriend
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
Eclipse UserFriend
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
Eclipse UserFriend
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
Eclipse UserFriend
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 246 times)
Previous Topic:JNLP on Virgo Web Server
Next Topic:virgo start ... hang ...
Goto Forum:
  


Current Time: Wed Jul 23 07:46:59 EDT 2025

Powered by FUDForum. Page generated in 0.09156 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly