Hi Daniele, sorry for answering this late, anyways, inline reply.
On [Fri, 22.04.2011 16:09], Daniele Dellafiore wrote: > Hi, sorry I read your reply only today... > I got basically to the same results yesterday, but I've some problem which I > summarized in the last message in this thread on felix mailing list: > > http://old.nabble.com/A-better-life%3A-quick-webapp-deploy-to31334158.html > > I'll go into details point by point. > > On Fri, Apr 8, 2011 at 3:29 PM, Eike Kettner <n...@eknet.org> wrote: > > > Hi Daniele, > > > > I might have not understood your concern well enough... But here is what I > > do: I deploy a really small war file (without any deps of course) into the > > osgi container (I use felix...). There is another bundle from pax, > > called pax-web-extender, that "listens" for war files coming into the > > container and will then register them on the embedded jetty instance. > > > > I use the following pax bundles: > > * org.ops4j.pax.web.pax-web-extender-war > > * org.ops4j.pax.web.pax-web-jetty-bundle > > * org.ops4j.pax.web.pax-web-jsp (might be superfluous) > > > > yeah I've everything installed. I do not remember what osgi features > installed this but there is: > > [ 54] [Active ] [ ] [ ] [ 60] OPS4J Pax Web - > Runtime (1.0.1) > [ 55] [Active ] [ ] [ ] [ 60] OPS4J Pax Web - API > (1.0.1) > [ 56] [Active ] [ ] [ ] [ 60] OPS4J Pax Web - Jetty > (1.0.1) > [ 57] [Active ] [ ] [ ] [ 60] OPS4J Pax Web - > Service SPI (1.0.1) > [ 59] [Active ] [ ] [ ] [ 60] OPS4J Pax Web - > Extender - Whiteboard (1.0.1) > [ 60] [Active ] [ ] [ ] [ 60] OPS4J Pax Web - > FileInstall Deployer (1.0.1) > [ 61] [Active ] [ ] [ ] [ 60] OPS4J Pax Url - war:, > war-i: (1.2.5) > [ 62] [Active ] [ ] [ ] [ 60] OPS4J Pax Web - > Extender - WAR (1.0.1) > [ 63] [Active ] [ ] [ ] [ 60] OPS4J Pax Web - Jsp > Support (1.0.1) > > on Karaf 2.2.0 > > > > > > Then I use the felix-bundle plugin to create a MANIFEST.MF for my war > > file. It looks like that: > > > > <plugins> > > <plugin> > > <groupId>org.apache.felix</groupId> > > <artifactId>maven-bundle-plugin</artifactId> > > <executions> > > <execution> > > <id>bundle-manifest</id> > > <phase>process-classes</phase> > > <goals> > > <goal>manifest</goal> > > </goals> > > </execution> > > </executions> > > <configuration> > > <supportedProjectTypes> > > <supportedProjectType>jar</supportedProjectType> > > <supportedProjectType>war</supportedProjectType> > > <supportedProjectType>bundle</supportedProjectType> > > </supportedProjectTypes> > > <instructions> > > <_include>-osgi.bnd</_include> > > </instructions> > > </configuration> > > </plugin> > > <plugin> > > <groupId>org.apache.maven.plugins</groupId> > > <artifactId>maven-war-plugin</artifactId> > > <configuration> > > <archive> > > <manifestFile> > > ${project.build.outputDirectory}/META-INF/MANIFEST.MF > > </manifestFile> > > </archive> > > </configuration> > > </plugin> > > </plugins> > > > > > > it's almost the same as mine, also the war-plugin config is identical. > I do not have > > <_include>-osgi.bnd</_include> > > but I have this instructions > > <_wab>src/main/webapp</_wab> > <Web-ContextPath>/myApp</Web-ContextPath> I didn't know about tha <_wab> configuration, This will maybe then add the web bundle class path to the headers, so it needn't be specified explicitely. > There are some more instructions in the "osgi.bnd" file. You could have > > written them directly in the <instructions> section of the bundle plugin: > > > > Bundle-Classpath: ., WEB-INF/classes > > Web-ContextPath: mywebapp > > DynamicImport-Package: * > > Webapp-Context: mywebapp > > > > It seems that maven-bundle-plugin, at least 2.3.4 version, automatically > add Bundle-Classpath: WEB-INF/classes if the project is a WAR or have a > Webapp-Context (that make the bundle a WAB, as for OSGI in Action), in fact > I do not have that intructions and the war project Bundle-Classpath: > WEB-INF/classes in the MANIFEST (note, without the dot). > I think also that Webapp-Context has been deprecated in favor of the new > Web-ContextPath you also have. ok, thanks for the info, I used both headers (web-contextpath and webapp-context) so far without issues, so I didn't worry to modify this so far. > As for DynamicImport-Package: * > what does this do? This is a very generic import header for the bundle. It is needed, if you plan to have other bundles contribute wicket pages/components. Wicket uses reflection to create page instances. In this case, the classes must be available to the class loader. If you do not know them up front, you can use the DynamicImport-Package statement. > It does not seem you do not have specific Import or Export package > instructions, so you use the maven-bundle-plugin defaults, so every dep is > explicitly written in the MANIFEST right? yes, every dep especially wicket is explicitely written in the manifest. > > > > > This creates a MANIFEST with Import-Package statements for all your > > dependencies - they are not included in the war file. The war file has > > no /lib folder, just WEB-INF/classes and META-INF/ are there. The bundle > > classpath is extended to include the classes in WEB-INF/classes. I > > use the scope "provided" for all dependencies. > > > > where do you specify the "provided" scope? In all the maven deps explicitly? > There is not a way to tell just maven-bundle-plugin to consider everything > as provided just when building the bundle? I think that this is the reason > why you do not have jars in the lib folder, right? > yes, right now I tell every dependency in maven to be "provided", if the jar is available from the osgi container. if not, i say "compile" and use the "EmbedDependency" instruction to embed this dependency in the bundle. I did not use this with the war bundle (only with normal jars) it needs more fiddleing... > > > > When the war file is deployed to the osgi container, the pax bundles > > from above will make it available to jetty. > > > > In fact, it seems that if I just manually remove the jars from the lib > folder, the pax extensions starts but fails to found the classes cause it > expect to found them in the WEB-INF/lib. So, I get a series of > ClassNotFoundException for spring and wicket classes during the startup (as > you can read in the same thread > http://old.nabble.com/A-better-life%3A-quick-webapp-deploy-to31334158.html) > I'm not sure why this happens. I remember from other threads that you solved this already, right? > > > > In my case the war file contains a simple wicket application that itself > > listens for other bundles to finally create content. > > > What do you mean with "listen"? Do you have some OSGI specific code to > access the application services? yes and no. I use spring-dm to have services registered at the osgi registry and to import them from there. every bundle has its own spring application context. then the war bundle is "listening" for specific services entering the osgi registry (in my case this is all wired by spring-dm). If it happens, the webapp can serve more content. > > > So its just a few > > bytes and I can reload/redeploy the "content bundles" without affecting > > the whole application. > > > > > So the wicket module is a separated bundle and the real application > (services, repositories...) are in another bundle? How do you access them, > with an OSGi specific mechanism, so you export your services as OSGI > services and access them from Wicket? Yes exactly. There are many bundles; and the wicket bundle is also a separate one. Then, for example, one is for authentication and exports a service to the osgi registry. I can then use the service by declaring it in the application context of another bundle using spring-dm specific xml configuration and then using the @SpringBean annotation. A note to the @SpringBean annotation: if you plan to have bundles updated or uninstalled at any time (in my case I "forbid" to stop the authentication bundle for my application lifetime but allow to stop/update several other bundles that just add more content to the webapp, because the application is written to allow it), you might want to rewrite the @SpringBean cache because it is not aware of services leaving the application. > Thanks for sharing your experience, I feel I'm close :) you're welcome. hope it helps.. regards Eike --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
