You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Peter Kriens <pe...@aqute.biz> on 2011/05/06 16:47:16 UTC
Re: A better life: quick webapp deploy
I am not sure I understand where you're going ....
The -wab/-wablib facility is ONLY for people that want to make a WAR that also runs on OSGi. Your use case seems to be standard vanilla OSGi. Just make it a WAB, i.e. set the Web-ContextPath header and you're done with any compliant OSGi Web container. The -wab option is just a convenience that moves the classes from the root to WEB-INF/classes. So start from zero and just create a bundle. I have NO idea what will happen when you try to build a JAR with all these different packagers in maven.
Did you try to make a simple "hello world" servlet?
Kind regards,
Peter Kriens
On 21 apr 2011, at 10:48, Daniele Dellafiore wrote:
> I thank you all for the information. I need to make it run from the
> maven-bundle-plugin 2.2.0.
> With the configuration (pasted in the end of the email) and instructing the
> maven-war-plugin to where the MANIFEST file is, the module with packaging =
> war has the osgi info but still has the /lib folder with all the jars and
> the MANIFEST file is not even populated with the OSGI info (while for all
> the other jar it is)
>
> I think I still need to add something like
>
> <Bundle-ClassPath>.,WEB-INF/classes</Bundle-ClassPath>
>
> Just for the war project.
>
> I'm confused about two things now:
> 1. how do I instruct the maven plugin NOT to copy dependency? Is this enough
> for the bundle to look for dependency in the container rather than in it's
> own /lib folder?
> 2. How do I instruct the container to run the bundle as a webapp? So to make
> the jetty that's active on Karaf to read the web.xml of my bundle?
>
> Or maybe I can skip the web.xml at all, in this way I've to figure out how
> to run a Wicket application without it...
>
>>
>> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <version>2.2.0</version>
> <extensions>true</extensions>
> <executions>
> <execution>
> <id>bundle-manifest</id>
> <phase>process-classes</phase>
> <goals>
> <goal>manifest</goal>
> </goals>
> </execution>
> </executions>
> <configuration>
> <supportedProjectTypes>
> <supportedProjectType>jar</supportedProjectType>
> <supportedProjectType>bundle</supportedProjectType>
> <supportedProjectType>war</supportedProjectType>
> </supportedProjectTypes>
> <instructions>
>
> <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
> <_versionpolicy>${osgi.version.policy}</_versionpolicy>
> <Export-Package>${osgi.export.package}</Export-Package>
> <Import-Package>${osgi.import.package}</Import-Package>
> <_wab>src/main/webapp/</_wab>
> </instructions>
> </configuration>
> </plugin>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: A better life: quick webapp deploy
Posted by Daniele Dellafiore <da...@dellafiore.net>.
On Tue, May 10, 2011 at 6:23 PM, <mv...@comcast.net> wrote:
>
>
> Danielle,
>
>
>
> We had similar issues with spring xml files, and you're correct, you cannot
> access spring.xml files between bundles. To be clear though, are you
> referring to the xml files in META-INF/spring or are you referring to the
> .xsd files spring uses in its namespaces?
>
to the xml files in META-INF/spring
also, the xml I'd like to load, i'd rather not put them in that folder cause
xml in that folder is automatically loaded by spring-dm.
What I'm thinking about are some xml used as resources, not started by
spring-dm in any way, that can be included in the spring context of another
bundle just as like I can instantiate a class from an imported bundle.
Included not with some custom code (not only at least) but with some
mechanism like import classpath*: that loads from dependent jars.
Re: A better life: quick webapp deploy
Posted by Daniele Dellafiore <da...@dellafiore.net>.
X_____X
@njbartlett pointed me out that bnd add a "." in the Import-Package when
there are Eclipse classes that does not compile in the project.
Indeed, it's true.
If he would have told me "it's because you drank a cappuccino after 12
today" would have made more sense to me.
On Thu, May 19, 2011 at 2:27 PM, Daniele Dellafiore
<da...@dellafiore.net>wrote:
> On Thu, May 19, 2011 at 1:26 PM, Daniele Dellafiore <
> daniele@dellafiore.net> wrote:
>
>> Sometimes happens that the resultant Manifest.mf contains a dot as the
>> first of the Import-Package. Like
>> Can't really understand why that happen.
>>
>
> I've debugged and it's bnd that put the dot as the first import package.
> I've hacked the maven-bundle-plugin to remove the dot so I Can continue to
> work, but I can't figure out why bnd would ever put a dot as import-package.
>
> More over, why this does not happens in all the other projects...
>
>
>
Re: A better life: quick webapp deploy
Posted by Daniele Dellafiore <da...@dellafiore.net>.
On Thu, May 19, 2011 at 1:26 PM, Daniele Dellafiore
<da...@dellafiore.net>wrote:
> Sometimes happens that the resultant Manifest.mf contains a dot as the
> first of the Import-Package. Like
> Can't really understand why that happen.
>
I've debugged and it's bnd that put the dot as the first import package.
I've hacked the maven-bundle-plugin to remove the dot so I Can continue to
work, but I can't figure out why bnd would ever put a dot as import-package.
More over, why this does not happens in all the other projects...
Re: A better life: quick webapp deploy
Posted by Daniele Dellafiore <da...@dellafiore.net>.
Sometimes happens that the resultant Manifest.mf contains a dot as the first
of the Import-Package. Like
Can't really understand why that happen.
Follows the complete maven-bundle-plugin configuration:
This is the exact same configuration that in other, say, 3/4 war bundles
produce a Import-Package without any dot. Adding or removing the
DynamicImport instructions does not change a bit.
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.3.4</version>
<extensions>true</extensions>
<executions>
<execution>
<id>bundle-manifest</id>
<phase>process-classes</phase>
<goals>
<goal>manifest</goal>
</goals>
</execution>
</executions>
<configuration>
<instructions>
<_wab>src/main/webapp</_wab>
<Web-ContextPath>/artivio</Web-ContextPath>
<Bundle-Classpath>WEB-INF/classes</Bundle-Classpath>
<DynamicImport-Package>*</DynamicImport-Package>
<Export-Package></Export-Package>
<_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>
<Import-Package>org.springframework.web,org.springframework.beans,*</Import-Package>
</instructions>
<supportedProjectTypes>
<supportedProjectType>jar</supportedProjectType>
<supportedProjectType>bundle</supportedProjectType>
<supportedProjectType>war</supportedProjectType>
</supportedProjectTypes>
</configuration>
</plugin>
On Sun, May 15, 2011 at 5:55 PM, Daniele Dellafiore
<da...@dellafiore.net>wrote:
>
> On Tue, May 10, 2011 at 6:26 PM, <mv...@comcast.net> wrote:
>
>>
>>
>> Danielle,
>>
>>
>>
>> What you are trying to do is best accomplished by using services. In my
>> application, we have a database connection and JMS connections that are used
>> by multiple bundles.
>
>
> does the connections provided by that bundle always points to the same
> database/jms broker or is able to return a custom connection, that's built
> with the connection properties that the client bundle knows?
>
>
>
Re: A better life: quick webapp deploy
Posted by Daniele Dellafiore <da...@dellafiore.net>.
On Tue, May 10, 2011 at 6:26 PM, <mv...@comcast.net> wrote:
>
>
> Danielle,
>
>
>
> What you are trying to do is best accomplished by using services. In my
> application, we have a database connection and JMS connections that are used
> by multiple bundles.
does the connections provided by that bundle always points to the same
database/jms broker or is able to return a custom connection, that's built
with the connection properties that the client bundle knows?
Re: A better life: quick webapp deploy
Posted by Peter Kriens <pe...@aqute.biz>.
right ... that is the way to go ... modularize and share via the service registry.
Kind regards,
Peter Kriens
On 10 mei 2011, at 18:26, mvangeertruy@comcast.net wrote:
>
>
> Danielle,
>
>
>
> What you are trying to do is best accomplished by using services. In my application, we have a database connection and JMS connections that are used by multiple bundles. So, for my database connection (since that's what we're talking about), I created my bundle, and then in the context file that uses the osgi and osgix namespaces, I simple attached the bundle to the service registry. Then any other bundle that needed to consume the database connection was able to grab a reference to the database service from the service registry, and then inject it via the database connections interface.
>
>
>
> v/r,
>
>
>
> Mike Van
>
>
> ----- Original Message -----
> From: "Daniele Dellafiore" <da...@dellafiore.net>
> To: users@felix.apache.org
> Sent: Tuesday, May 10, 2011 11:37:22 AM
> Subject: Re: A better life: quick webapp deploy
>
> On Tue, May 10, 2011 at 3:17 PM, Peter Kriens <pe...@aqute.biz>wrote:
>
>> In OSGi the idea is that you get a bunch of bundles that collaborate
>> through services. The bundle is a module and is therefore supposed to be
>> impenetrable. Just like a class has private fields so does a bundle have
>> private classes and resources. It would not be very modular if you could use
>> the XML from other bundles, this Spring XML is supposed to be an
>> implementation detail of the bundle. As long as you do the collaboration
>> with services you can use many different techniques: Spring, DS, iPOJO,
>> dependency manager, etc.
>>
>
> Another way to say is that I use the XML from other bundles as I use a class
> from another bundle, I do not see any violation here.
> A spring xml is an implementation detail? For me is like a class, nothing
> more, I load it using <import> like instantiate a class with a new.
>
> Example.
> If I've defined some beans that manage storage and search in a bundle A and
> want to load them in a bundle B changing just some properties (database
> connections and some search tuning), the only way I know now, in OSGI, is to
> copy-paste the spring XML into bundle A, cause import classpath*: does not
> work.
> Copy paste is always bad so I figure out that alternatives are:
>
> 1. importing beans from bundle A in the context of B, using a sort of
> osgi:classpath
> 2. exporing those beans as osgi services, but as long that properties are
> chosen by bundle B, I need something more sophisticated like
> ManagedServiceFactory to get a new instance with the actual parameters. I've
> never dig into that but it seems to be the case. This solution, that I do
> not find easy, is OSGI specific while I'd like to stay on spring and avoid
> to couple with OSGI mechanism
> 3. i can raise the level of abstraction. If I need a DatabaseTemplate
> configured with some property that definese database connection, i can
> export as osgi service a DatabaseTemplateFactory from bundle B and ask the
> template to the factory from A. But here I loose advantages of spring IOC:
> in my classes I will have an instance of the factory, and I've to ask for a
> new class everytime and who keeps the control that the new template instance
> is a singleton now?
> 4. bundle A do the persistence and that's it. I export a DatabaseTemplate
> that can write on different databases, and I tell which one using a
> parameter or some more sophisticated mechanism (ThreadLocal? wonder how it
> works on OSGI).
>
> Maybe is not that important but sometime it happens I have a bundle that
> offer some classes. In a typical app that use that bundle, one or more
> classes are candidate to become spring beans, in every app that will use the
> classes. So I provide a ready to use spring xml so that you do not need to
> copy-paste the spring definition but you can just import the file as a
> resource.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: A better life: quick webapp deploy
Posted by mv...@comcast.net.
Danielle,
What you are trying to do is best accomplished by using services. In my application, we have a database connection and JMS connections that are used by multiple bundles. So, for my database connection (since that's what we're talking about), I created my bundle, and then in the context file that uses the osgi and osgix namespaces, I simple attached the bundle to the service registry. Then any other bundle that needed to consume the database connection was able to grab a reference to the database service from the service registry, and then inject it via the database connections interface.
v/r,
Mike Van
----- Original Message -----
From: "Daniele Dellafiore" <da...@dellafiore.net>
To: users@felix.apache.org
Sent: Tuesday, May 10, 2011 11:37:22 AM
Subject: Re: A better life: quick webapp deploy
On Tue, May 10, 2011 at 3:17 PM, Peter Kriens <pe...@aqute.biz>wrote:
> In OSGi the idea is that you get a bunch of bundles that collaborate
> through services. The bundle is a module and is therefore supposed to be
> impenetrable. Just like a class has private fields so does a bundle have
> private classes and resources. It would not be very modular if you could use
> the XML from other bundles, this Spring XML is supposed to be an
> implementation detail of the bundle. As long as you do the collaboration
> with services you can use many different techniques: Spring, DS, iPOJO,
> dependency manager, etc.
>
Another way to say is that I use the XML from other bundles as I use a class
from another bundle, I do not see any violation here.
A spring xml is an implementation detail? For me is like a class, nothing
more, I load it using <import> like instantiate a class with a new.
Example.
If I've defined some beans that manage storage and search in a bundle A and
want to load them in a bundle B changing just some properties (database
connections and some search tuning), the only way I know now, in OSGI, is to
copy-paste the spring XML into bundle A, cause import classpath*: does not
work.
Copy paste is always bad so I figure out that alternatives are:
1. importing beans from bundle A in the context of B, using a sort of
osgi:classpath
2. exporing those beans as osgi services, but as long that properties are
chosen by bundle B, I need something more sophisticated like
ManagedServiceFactory to get a new instance with the actual parameters. I've
never dig into that but it seems to be the case. This solution, that I do
not find easy, is OSGI specific while I'd like to stay on spring and avoid
to couple with OSGI mechanism
3. i can raise the level of abstraction. If I need a DatabaseTemplate
configured with some property that definese database connection, i can
export as osgi service a DatabaseTemplateFactory from bundle B and ask the
template to the factory from A. But here I loose advantages of spring IOC:
in my classes I will have an instance of the factory, and I've to ask for a
new class everytime and who keeps the control that the new template instance
is a singleton now?
4. bundle A do the persistence and that's it. I export a DatabaseTemplate
that can write on different databases, and I tell which one using a
parameter or some more sophisticated mechanism (ThreadLocal? wonder how it
works on OSGI).
Maybe is not that important but sometime it happens I have a bundle that
offer some classes. In a typical app that use that bundle, one or more
classes are candidate to become spring beans, in every app that will use the
classes. So I provide a ready to use spring xml so that you do not need to
copy-paste the spring definition but you can just import the file as a
resource.
Re: A better life: quick webapp deploy
Posted by Justin Edelson <ju...@justinedelson.com>.
On Tue, May 10, 2011 at 11:37 AM, Daniele Dellafiore
<da...@dellafiore.net> wrote:
> On Tue, May 10, 2011 at 3:17 PM, Peter Kriens <pe...@aqute.biz>wrote:
>
>> In OSGi the idea is that you get a bunch of bundles that collaborate
>> through services. The bundle is a module and is therefore supposed to be
>> impenetrable. Just like a class has private fields so does a bundle have
>> private classes and resources. It would not be very modular if you could use
>> the XML from other bundles, this Spring XML is supposed to be an
>> implementation detail of the bundle. As long as you do the collaboration
>> with services you can use many different techniques: Spring, DS, iPOJO,
>> dependency manager, etc.
>>
>
> Another way to say is that I use the XML from other bundles as I use a class
> from another bundle, I do not see any violation here.
Maybe I'm missing something, but what's stopping you from exporting
the package containing these XML files from one bundle and importing
them in another?
> A spring xml is an implementation detail? For me is like a class, nothing
> more, I load it using <import> like instantiate a class with a new.
>
> Example.
> If I've defined some beans that manage storage and search in a bundle A and
> want to load them in a bundle B changing just some properties (database
> connections and some search tuning), the only way I know now, in OSGI, is to
> copy-paste the spring XML into bundle A, cause import classpath*: does not
> work.
> Copy paste is always bad so I figure out that alternatives are:
>
> 1. importing beans from bundle A in the context of B, using a sort of
> osgi:classpath
> 2. exporing those beans as osgi services, but as long that properties are
> chosen by bundle B, I need something more sophisticated like
> ManagedServiceFactory to get a new instance with the actual parameters. I've
> never dig into that but it seems to be the case. This solution, that I do
> not find easy, is OSGI specific while I'd like to stay on spring and avoid
> to couple with OSGI mechanism
> 3. i can raise the level of abstraction. If I need a DatabaseTemplate
> configured with some property that definese database connection, i can
> export as osgi service a DatabaseTemplateFactory from bundle B and ask the
> template to the factory from A. But here I loose advantages of spring IOC:
> in my classes I will have an instance of the factory, and I've to ask for a
> new class everytime and who keeps the control that the new template instance
> is a singleton now?
> 4. bundle A do the persistence and that's it. I export a DatabaseTemplate
> that can write on different databases, and I tell which one using a
> parameter or some more sophisticated mechanism (ThreadLocal? wonder how it
> works on OSGI).
>
> Maybe is not that important but sometime it happens I have a bundle that
> offer some classes. In a typical app that use that bundle, one or more
> classes are candidate to become spring beans, in every app that will use the
> classes. So I provide a ready to use spring xml so that you do not need to
> copy-paste the spring definition but you can just import the file as a
> resource.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: A better life: quick webapp deploy
Posted by Peter Kriens <pe...@aqute.biz>.
Though you can if you want access the XML files with the Bundle API you violate the intended encapsulation. This is similar to using reflection in Java. Extremely useful sometimes but you have to understand the consequences. As stated, OSGi is about collaborating services which are implemented in bundles. Once you find yourself fighting with the barriers that were consciously put in place you have to consider if you're having the right design. Or, of course, if OSGi is the right model for you.
Now for you particular problem there are other solutions. It seems you want to use Spring "templates". With a tool like bnd
On 10 mei 2011, at 17:37, Daniele Dellafiore wrote:
> On Tue, May 10, 2011 at 3:17 PM, Peter Kriens <pe...@aqute.biz>wrote:
>
>> In OSGi the idea is that you get a bunch of bundles that collaborate
>> through services. The bundle is a module and is therefore supposed to be
>> impenetrable. Just like a class has private fields so does a bundle have
>> private classes and resources. It would not be very modular if you could use
>> the XML from other bundles, this Spring XML is supposed to be an
>> implementation detail of the bundle. As long as you do the collaboration
>> with services you can use many different techniques: Spring, DS, iPOJO,
>> dependency manager, etc.
>>
>
> Another way to say is that I use the XML from other bundles as I use a class
> from another bundle, I do not see any violation here.
> A spring xml is an implementation detail? For me is like a class, nothing
> more, I load it using <import> like instantiate a class with a new.
>
> Example.
> If I've defined some beans that manage storage and search in a bundle A and
> want to load them in a bundle B changing just some properties (database
> connections and some search tuning), the only way I know now, in OSGI, is to
> copy-paste the spring XML into bundle A, cause import classpath*: does not
> work.
> Copy paste is always bad so I figure out that alternatives are:
>
> 1. importing beans from bundle A in the context of B, using a sort of
> osgi:classpath
> 2. exporing those beans as osgi services, but as long that properties are
> chosen by bundle B, I need something more sophisticated like
> ManagedServiceFactory to get a new instance with the actual parameters. I've
> never dig into that but it seems to be the case. This solution, that I do
> not find easy, is OSGI specific while I'd like to stay on spring and avoid
> to couple with OSGI mechanism
> 3. i can raise the level of abstraction. If I need a DatabaseTemplate
> configured with some property that definese database connection, i can
> export as osgi service a DatabaseTemplateFactory from bundle B and ask the
> template to the factory from A. But here I loose advantages of spring IOC:
> in my classes I will have an instance of the factory, and I've to ask for a
> new class everytime and who keeps the control that the new template instance
> is a singleton now?
> 4. bundle A do the persistence and that's it. I export a DatabaseTemplate
> that can write on different databases, and I tell which one using a
> parameter or some more sophisticated mechanism (ThreadLocal? wonder how it
> works on OSGI).
>
> Maybe is not that important but sometime it happens I have a bundle that
> offer some classes. In a typical app that use that bundle, one or more
> classes are candidate to become spring beans, in every app that will use the
> classes. So I provide a ready to use spring xml so that you do not need to
> copy-paste the spring definition but you can just import the file as a
> resource.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: A better life: quick webapp deploy
Posted by Daniele Dellafiore <da...@dellafiore.net>.
On Tue, May 10, 2011 at 3:17 PM, Peter Kriens <pe...@aqute.biz>wrote:
> In OSGi the idea is that you get a bunch of bundles that collaborate
> through services. The bundle is a module and is therefore supposed to be
> impenetrable. Just like a class has private fields so does a bundle have
> private classes and resources. It would not be very modular if you could use
> the XML from other bundles, this Spring XML is supposed to be an
> implementation detail of the bundle. As long as you do the collaboration
> with services you can use many different techniques: Spring, DS, iPOJO,
> dependency manager, etc.
>
Another way to say is that I use the XML from other bundles as I use a class
from another bundle, I do not see any violation here.
A spring xml is an implementation detail? For me is like a class, nothing
more, I load it using <import> like instantiate a class with a new.
Example.
If I've defined some beans that manage storage and search in a bundle A and
want to load them in a bundle B changing just some properties (database
connections and some search tuning), the only way I know now, in OSGI, is to
copy-paste the spring XML into bundle A, cause import classpath*: does not
work.
Copy paste is always bad so I figure out that alternatives are:
1. importing beans from bundle A in the context of B, using a sort of
osgi:classpath
2. exporing those beans as osgi services, but as long that properties are
chosen by bundle B, I need something more sophisticated like
ManagedServiceFactory to get a new instance with the actual parameters. I've
never dig into that but it seems to be the case. This solution, that I do
not find easy, is OSGI specific while I'd like to stay on spring and avoid
to couple with OSGI mechanism
3. i can raise the level of abstraction. If I need a DatabaseTemplate
configured with some property that definese database connection, i can
export as osgi service a DatabaseTemplateFactory from bundle B and ask the
template to the factory from A. But here I loose advantages of spring IOC:
in my classes I will have an instance of the factory, and I've to ask for a
new class everytime and who keeps the control that the new template instance
is a singleton now?
4. bundle A do the persistence and that's it. I export a DatabaseTemplate
that can write on different databases, and I tell which one using a
parameter or some more sophisticated mechanism (ThreadLocal? wonder how it
works on OSGI).
Maybe is not that important but sometime it happens I have a bundle that
offer some classes. In a typical app that use that bundle, one or more
classes are candidate to become spring beans, in every app that will use the
classes. So I provide a ready to use spring xml so that you do not need to
copy-paste the spring definition but you can just import the file as a
resource.
Re: A better life: quick webapp deploy
Posted by Peter Kriens <pe...@aqute.biz>.
In OSGi the idea is that you get a bunch of bundles that collaborate through services. The bundle is a module and is therefore supposed to be impenetrable. Just like a class has private fields so does a bundle have private classes and resources. It would not be very modular if you could use the XML from other bundles, this Spring XML is supposed to be an implementation detail of the bundle. As long as you do the collaboration with services you can use many different techniques: Spring, DS, iPOJO, dependency manager, etc.
So with spring the basic idea is that spring configures your bundle to register and consume services. How this is achieved is then an implementation detail.
Kind regards,
Peter Kriens
On 10 mei 2011, at 13:12, Daniele Dellafiore wrote:
> On Fri, May 6, 2011 at 4:47 PM, Peter Kriens <pe...@aqute.biz> wrote:
>
>> I am not sure I understand where you're going ....
>>
>> The -wab/-wablib facility is ONLY for people that want to make a WAR that
>> also runs on OSGi. Your use case seems to be standard vanilla OSGi. Just
>> make it a WAB, i.e. set the Web-ContextPath header and you're done with any
>> compliant OSGi Web container. The -wab option is just a convenience that
>> moves the classes from the root to WEB-INF/classes. So start from zero and
>> just create a bundle. I have NO idea what will happen when you try to build
>> a JAR with all these different packagers in maven.
>>
>> Did you try to make a simple "hello world" servlet?
>>
>
> Yes I tried that way and I finally succeded. The misunderstanding was I
> thought that "WAB" means "war without dependencies, with a context and with
> classpath in WEB-INF/classes", and that bnd/maven-bundle build that
> accordingly. It's not the case, a WAB is a WAR with a couple of special
> instructions for OSGI in the manifest and there's to use maven-war to
> exclude dependencies.
> Fine
>
> I succeded in starting a simple servlet project, a wicket webapp and also a
> wicket webapp with spring using OsgiBundleXmlWebApplicationContext from the
> org.springframework.osgi.web project.
>
> There's still a thing I can't understand how to achieve, that involves osgi
> and spring (not wicket or webapps)
> In the OSGI context, I can only load spring xml files that are in the
> bundle, not the ones in imported bundles.
>
> Anyway thanks to everyone for the help.
>
>
>
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>
>>
>> On 21 apr 2011, at 10:48, Daniele Dellafiore wrote:
>>
>>> I thank you all for the information. I need to make it run from the
>>> maven-bundle-plugin 2.2.0.
>>> With the configuration (pasted in the end of the email) and instructing
>> the
>>> maven-war-plugin to where the MANIFEST file is, the module with packaging
>> =
>>> war has the osgi info but still has the /lib folder with all the jars and
>>> the MANIFEST file is not even populated with the OSGI info (while for all
>>> the other jar it is)
>>>
>>> I think I still need to add something like
>>>
>>> <Bundle-ClassPath>.,WEB-INF/classes</Bundle-ClassPath>
>>>
>>> Just for the war project.
>>>
>>> I'm confused about two things now:
>>> 1. how do I instruct the maven plugin NOT to copy dependency? Is this
>> enough
>>> for the bundle to look for dependency in the container rather than in
>> it's
>>> own /lib folder?
>>> 2. How do I instruct the container to run the bundle as a webapp? So to
>> make
>>> the jetty that's active on Karaf to read the web.xml of my bundle?
>>>
>>> Or maybe I can skip the web.xml at all, in this way I've to figure out
>> how
>>> to run a Wicket application without it...
>>>
>>>>
>>>> <plugin>
>>> <groupId>org.apache.felix</groupId>
>>> <artifactId>maven-bundle-plugin</artifactId>
>>> <version>2.2.0</version>
>>> <extensions>true</extensions>
>>> <executions>
>>> <execution>
>>> <id>bundle-manifest</id>
>>> <phase>process-classes</phase>
>>> <goals>
>>> <goal>manifest</goal>
>>> </goals>
>>> </execution>
>>> </executions>
>>> <configuration>
>>> <supportedProjectTypes>
>>> <supportedProjectType>jar</supportedProjectType>
>>> <supportedProjectType>bundle</supportedProjectType>
>>> <supportedProjectType>war</supportedProjectType>
>>> </supportedProjectTypes>
>>> <instructions>
>>>
>>> <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
>>> <_versionpolicy>${osgi.version.policy}</_versionpolicy>
>>> <Export-Package>${osgi.export.package}</Export-Package>
>>> <Import-Package>${osgi.import.package}</Import-Package>
>>> <_wab>src/main/webapp/</_wab>
>>> </instructions>
>>> </configuration>
>>> </plugin>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: A better life: quick webapp deploy
Posted by mv...@comcast.net.
Danielle,
We had similar issues with spring xml files, and you're correct, you cannot access spring.xml files between bundles. To be clear though, are you referring to the xml files in META-INF/spring or are you referring to the .xsd files spring uses in its namespaces?
v/r,
Mike Van
----- Original Message -----
From: "Daniele Dellafiore" <da...@dellafiore.net>
To: users@felix.apache.org
Sent: Tuesday, May 10, 2011 7:12:48 AM
Subject: Re: A better life: quick webapp deploy
On Fri, May 6, 2011 at 4:47 PM, Peter Kriens <pe...@aqute.biz> wrote:
> I am not sure I understand where you're going ....
>
> The -wab/-wablib facility is ONLY for people that want to make a WAR that
> also runs on OSGi. Your use case seems to be standard vanilla OSGi. Just
> make it a WAB, i.e. set the Web-ContextPath header and you're done with any
> compliant OSGi Web container. The -wab option is just a convenience that
> moves the classes from the root to WEB-INF/classes. So start from zero and
> just create a bundle. I have NO idea what will happen when you try to build
> a JAR with all these different packagers in maven.
>
> Did you try to make a simple "hello world" servlet?
>
Yes I tried that way and I finally succeded. The misunderstanding was I
thought that "WAB" means "war without dependencies, with a context and with
classpath in WEB-INF/classes", and that bnd/maven-bundle build that
accordingly. It's not the case, a WAB is a WAR with a couple of special
instructions for OSGI in the manifest and there's to use maven-war to
exclude dependencies.
Fine
I succeded in starting a simple servlet project, a wicket webapp and also a
wicket webapp with spring using OsgiBundleXmlWebApplicationContext from the
org.springframework.osgi.web project.
There's still a thing I can't understand how to achieve, that involves osgi
and spring (not wicket or webapps)
In the OSGI context, I can only load spring xml files that are in the
bundle, not the ones in imported bundles.
Anyway thanks to everyone for the help.
>
> Kind regards,
>
> Peter Kriens
>
>
>
>
> On 21 apr 2011, at 10:48, Daniele Dellafiore wrote:
>
> > I thank you all for the information. I need to make it run from the
> > maven-bundle-plugin 2.2.0.
> > With the configuration (pasted in the end of the email) and instructing
> the
> > maven-war-plugin to where the MANIFEST file is, the module with packaging
> =
> > war has the osgi info but still has the /lib folder with all the jars and
> > the MANIFEST file is not even populated with the OSGI info (while for all
> > the other jar it is)
> >
> > I think I still need to add something like
> >
> > <Bundle-ClassPath>.,WEB-INF/classes</Bundle-ClassPath>
> >
> > Just for the war project.
> >
> > I'm confused about two things now:
> > 1. how do I instruct the maven plugin NOT to copy dependency? Is this
> enough
> > for the bundle to look for dependency in the container rather than in
> it's
> > own /lib folder?
> > 2. How do I instruct the container to run the bundle as a webapp? So to
> make
> > the jetty that's active on Karaf to read the web.xml of my bundle?
> >
> > Or maybe I can skip the web.xml at all, in this way I've to figure out
> how
> > to run a Wicket application without it...
> >
> >>
> >> <plugin>
> > <groupId>org.apache.felix</groupId>
> > <artifactId>maven-bundle-plugin</artifactId>
> > <version>2.2.0</version>
> > <extensions>true</extensions>
> > <executions>
> > <execution>
> > <id>bundle-manifest</id>
> > <phase>process-classes</phase>
> > <goals>
> > <goal>manifest</goal>
> > </goals>
> > </execution>
> > </executions>
> > <configuration>
> > <supportedProjectTypes>
> > <supportedProjectType>jar</supportedProjectType>
> > <supportedProjectType>bundle</supportedProjectType>
> > <supportedProjectType>war</supportedProjectType>
> > </supportedProjectTypes>
> > <instructions>
> >
> > <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
> > <_versionpolicy>${osgi.version.policy}</_versionpolicy>
> > <Export-Package>${osgi.export.package}</Export-Package>
> > <Import-Package>${osgi.import.package}</Import-Package>
> > <_wab>src/main/webapp/</_wab>
> > </instructions>
> > </configuration>
> > </plugin>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: A better life: quick webapp deploy
Posted by Daniele Dellafiore <da...@dellafiore.net>.
On Fri, May 6, 2011 at 4:47 PM, Peter Kriens <pe...@aqute.biz> wrote:
> I am not sure I understand where you're going ....
>
> The -wab/-wablib facility is ONLY for people that want to make a WAR that
> also runs on OSGi. Your use case seems to be standard vanilla OSGi. Just
> make it a WAB, i.e. set the Web-ContextPath header and you're done with any
> compliant OSGi Web container. The -wab option is just a convenience that
> moves the classes from the root to WEB-INF/classes. So start from zero and
> just create a bundle. I have NO idea what will happen when you try to build
> a JAR with all these different packagers in maven.
>
> Did you try to make a simple "hello world" servlet?
>
Yes I tried that way and I finally succeded. The misunderstanding was I
thought that "WAB" means "war without dependencies, with a context and with
classpath in WEB-INF/classes", and that bnd/maven-bundle build that
accordingly. It's not the case, a WAB is a WAR with a couple of special
instructions for OSGI in the manifest and there's to use maven-war to
exclude dependencies.
Fine
I succeded in starting a simple servlet project, a wicket webapp and also a
wicket webapp with spring using OsgiBundleXmlWebApplicationContext from the
org.springframework.osgi.web project.
There's still a thing I can't understand how to achieve, that involves osgi
and spring (not wicket or webapps)
In the OSGI context, I can only load spring xml files that are in the
bundle, not the ones in imported bundles.
Anyway thanks to everyone for the help.
>
> Kind regards,
>
> Peter Kriens
>
>
>
>
> On 21 apr 2011, at 10:48, Daniele Dellafiore wrote:
>
> > I thank you all for the information. I need to make it run from the
> > maven-bundle-plugin 2.2.0.
> > With the configuration (pasted in the end of the email) and instructing
> the
> > maven-war-plugin to where the MANIFEST file is, the module with packaging
> =
> > war has the osgi info but still has the /lib folder with all the jars and
> > the MANIFEST file is not even populated with the OSGI info (while for all
> > the other jar it is)
> >
> > I think I still need to add something like
> >
> > <Bundle-ClassPath>.,WEB-INF/classes</Bundle-ClassPath>
> >
> > Just for the war project.
> >
> > I'm confused about two things now:
> > 1. how do I instruct the maven plugin NOT to copy dependency? Is this
> enough
> > for the bundle to look for dependency in the container rather than in
> it's
> > own /lib folder?
> > 2. How do I instruct the container to run the bundle as a webapp? So to
> make
> > the jetty that's active on Karaf to read the web.xml of my bundle?
> >
> > Or maybe I can skip the web.xml at all, in this way I've to figure out
> how
> > to run a Wicket application without it...
> >
> >>
> >> <plugin>
> > <groupId>org.apache.felix</groupId>
> > <artifactId>maven-bundle-plugin</artifactId>
> > <version>2.2.0</version>
> > <extensions>true</extensions>
> > <executions>
> > <execution>
> > <id>bundle-manifest</id>
> > <phase>process-classes</phase>
> > <goals>
> > <goal>manifest</goal>
> > </goals>
> > </execution>
> > </executions>
> > <configuration>
> > <supportedProjectTypes>
> > <supportedProjectType>jar</supportedProjectType>
> > <supportedProjectType>bundle</supportedProjectType>
> > <supportedProjectType>war</supportedProjectType>
> > </supportedProjectTypes>
> > <instructions>
> >
> > <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
> > <_versionpolicy>${osgi.version.policy}</_versionpolicy>
> > <Export-Package>${osgi.export.package}</Export-Package>
> > <Import-Package>${osgi.import.package}</Import-Package>
> > <_wab>src/main/webapp/</_wab>
> > </instructions>
> > </configuration>
> > </plugin>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>