Eclipse Community Forums: Virgo » Best Practice for extending the in-built Tomcat bundle

Home » Eclipse Projects » Virgo » Best Practice for extending the in-built Tomcat bundle(Best Practice for extending the in-built Tomcat bundle)

Show: Today's Messages :: Show Polls :: Message Navigator

Best Practice for extending the in-built Tomcat bundle [message #659655]

Tue, 15 March 2011 02:28

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

Report message to a moderator

Re: Best Practice for extending the in-built Tomcat bundle [message #659676 is a reply to message #659655]

Tue, 15 March 2011 08:38

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.

Report message to a moderator

Re: Best Practice for extending the in-built Tomcat bundle [message #660120 is a reply to message #659655]

Wed, 16 March 2011 22:49

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

Attachment: com.melbourneit.web.terracotta-session-1.1.1.jar
(Size: 500.04KB, Downloaded 283 times)

Report message to a moderator

Re: Best Practice for extending the in-built Tomcat bundle [message #660153 is a reply to message #660120]

Thu, 17 March 2011 06:07

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 06: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 09:46

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

Report message to a moderator

Re: Best Practice for extending the in-built Tomcat bundle [message #660239 is a reply to message #660188]

Thu, 17 March 2011 14:13

Hristo Iliev

Messages: 156
Registered: May 2010
Location: Sofia, Bulgaria

Senior Member

Seems install works fine in 3.0.0.M03

Report message to a moderator

Re: Best Practice for extending the in-built Tomcat bundle [message #660245 is a reply to message #660239]

Thu, 17 March 2011 14:32

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

Thanks Hristo!

Report message to a moderator

Re: Best Practice for extending the in-built Tomcat bundle [message #660336 is a reply to message #659655]

Fri, 18 March 2011 01:02

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

Report message to a moderator

[Resolved] Re: Best Practice for extending the in-built Tomcat bundle [message #662515 is a reply to message #659655]

Wed, 30 March 2011 21:46

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!

Report message to a moderator

Re: [Resolved] Re: Best Practice for extending the in-built Tomcat bundle [message #662576 is a reply to message #662515]

Thu, 31 March 2011 08:13

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

We appreciate the feedback. Thanks Matt.

Report message to a moderator

Re: [Resolved] Re: Best Practice for extending the in-built Tomcat bundle [message #736477 is a reply to message #662515]

Fri, 14 October 2011 03:14

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

Report message to a moderator

Re: [Resolved] Re: Best Practice for extending the in-built Tomcat bundle [message #736895 is a reply to message #736477]

Fri, 14 October 2011 12:46

Violeta Georgieva

Messages: 278
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 213 times)

Report message to a moderator

Previous Topic:	JNLP on Virgo Web Server
Next Topic:	virgo start ... hang ...

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 18 04:49:32 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter