Hi,
This is probably slightly off topic, as below seems to be focused on maven /
build stuff...
I have a demonstration, which I could provide the eclipse project/workspace if
anyone is interested, of a tomcat web app that embeds felix... The idea was a
bit more decoupling than what most attempts have tried, from what I've seen...
My tenants were: A). Tomcat has no idea that embedded OSGi ('er, felix as the
equinox has a NPE bug in it, for which I logged a bugzilla report) is
occurring, and B). the embedded OSGi (bundles and services thereof) have no
idea that they are in a web app (tomcat or otherwise); After all, OSGi is
loose coupling taken to another stratosphere (for which I am not complaining in
the least, certainly pleased with the mentality/mind-set), and thus the
embedding of which should also be loosely coupled;
Now, with the loose coupling mantra said, I still had to modify the
bootdelegation line to include my embedded services API, but that was
acceptable to me -- So, the trick was to have a small piece of glue code that
takes the web app request(s) and translates to an embedded bundle service a la
the API -- hence, if the API changes, my glue code would need to change -- so,
the bootdelegation entry didn't bother me; I have a few ideas to make my
embedded API in a "meta model" scheme, at which point the API would barely need
to change.... but I leave that to your imagination... One big thing I've always
liked about OSGi (and Felix even better): minimal agenda (like the "Lego"
analogy); I don't get that mentality from Sun or even other implementations
(and, don't get me started on J-7);
Well, thought I'd throw that out there, sort of related fodder to embedding and
web apps...
Craig Phillips, Praxis
________________________________
From: Richard S. Hall [mailto:[EMAIL PROTECTED]
Sent: Wed 10/8/2008 9:27 AM
To: [email protected]
Subject: [Fwd: Re: building a felix embedding web app with maven]
I guess servlet gets dragged into the framework dependencies from
compendium. Should we put excluding servlet in our own POMs? Would it
excluding it in the framework POM be sufficient?
-> richard
-------- Original Message --------
Subject: Re: building a felix embedding web app with maven
Date: Wed, 8 Oct 2008 17:08:49 +0800
From: Stuart McCulloch <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
References:
<[EMAIL PROTECTED]>
2008/10/8 Maxim Suponya <[EMAIL PROTECTED]>
> Hi,
> I have a web app that is built using maven 2.0.8. The application's
> pom.xml contains following dependency:
>
> <dependency>
> <groupId>org.apache.felix</groupId>
> <artifactId>org.apache.felix.framework</artifactId>
> <version>1.2.1</version>
> </dependency>
>
> But felix, in turn, depends on a project defined in
> javax.servlet-1.0.0.pom which subsequently makes a jar file called
> javax.servlet-1.0.0.jar ending up in WEB-INF/lib together with
> org.apache.felix.framework-1.2.1.jar.
have you tried using:
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.framework</artifactId>
<version>1.2.1</version>
<exclusions>
<exclusion>
<groupId>org.apache.felix</groupId>
<artifactId>javax.servlet</artifactId>
</exclusion>
</exclusions>
</dependency>
to tell Maven to exclude the transitive servlet dependency?
> When the web application starts and the servlet that launches felix gets
> initialized, a ClassCastException is thrown saying that this servlet is
> not a Servlet.. this is due to presence of javax.servlet-1.0.0.jar with
> Servlet.class in WEB-INF/lib which comes in conflict with the one that's
> provided by Tomcat.
>
> Adding <scope>provided</scope> in my app's pom.xml doesn't make any
> difference.
>
> <dependency>
> <groupId>org.apache.felix</groupId>
> <artifactId>javax.servlet</artifactId>
> <version>1.0.0</version>
> <scope>provided</scope>
> </dependency>
>
> Is there any way around this?
>
> Thanks a lot,
>
> Maxim
>
> - ----------------
> IMPORTANT NOTICE : The information in this email is confidential and may
> also be privileged. If you are not the intended recipient, any use or
> dissemination of the information and any disclosure or copying of this email
> is unauthorised and strictly prohibited. If you have received this email in
> error, please promptly inform us by reply email or telephone. You should
> also delete this email and destroy any hard copies produced.
--
Cheers, Stuart
