Comments on: Deploying WARs to the OSGi Web Container is now even easier http://blog.springsource.org/2009/06/16/deploying-wars-to-the-osgi-web-container-is-now-even-easier/ The voice of SpringSource Wed, 08 Feb 2012 17:31:53 +0000 hourly 1 http://wordpress.org/?v=3.1.1 By: Andy Wilkinson http://blog.springsource.org/2009/06/16/deploying-wars-to-the-osgi-web-container-is-now-even-easier/comment-page-1/#comment-168447 Andy Wilkinson Sat, 12 Sep 2009 10:51:05 +0000 http://blog.springsource.com/?p=2232#comment-168447 Don, the configuration location algorithm used by the com.springsource.osgi.webcontainer.tomcat bundle is as follows: <ol> <li>Check for config/tomcat-server.xml in the current working directory, use if found</li> <li>Check this bundle and attached fragments for /META-INF/tomcat/server.xml, use if found</li> <li>Check this bundle for /META-INF/tomcat/default-server.xml, use if found</li> <li>Throw IllegalStateException if no configuration is found</li> </ol> Take a look at com.springsource.webcontainer.tomcat.TomcatConfigLocator for the implementation. The server.xml file is a standard Tomcat server.xml and you be used to configure connectors, keystore locations, etc. Don, the configuration location algorithm used by the com.springsource.osgi.webcontainer.tomcat bundle is as follows:

  1. Check for config/tomcat-server.xml in the current working directory, use if found
  2. Check this bundle and attached fragments for /META-INF/tomcat/server.xml, use if found
  3. Check this bundle for /META-INF/tomcat/default-server.xml, use if found
  4. Throw IllegalStateException if no configuration is found

Take a look at com.springsource.webcontainer.tomcat.TomcatConfigLocator for the implementation. The server.xml file is a standard Tomcat server.xml and you be used to configure connectors, keystore locations, etc.

]]> By: Don Laidlaw http://blog.springsource.org/2009/06/16/deploying-wars-to-the-osgi-web-container-is-now-even-easier/comment-page-1/#comment-168412 Don Laidlaw Tue, 08 Sep 2009 18:48:46 +0000 http://blog.springsource.com/?p=2232#comment-168412 Any news on how to configure the Tomcat instance yet? Especially when not running the web container in Spring dm. When I create my own OSGi container based on equinox, how do I configure the tomcat server.xml so that I can set connector properties and keystore locations, etc.? Any news on how to configure the Tomcat instance yet? Especially when not running the web container in Spring dm. When I create my own OSGi container based on equinox, how do I configure the tomcat server.xml so that I can set connector properties and keystore locations, etc.?

]]> By: Pax your OSGi tutorials! « pax my framework http://blog.springsource.org/2009/06/16/deploying-wars-to-the-osgi-web-container-is-now-even-easier/comment-page-1/#comment-168381 Pax your OSGi tutorials! « pax my framework Fri, 04 Sep 2009 11:17:19 +0000 http://blog.springsource.com/?p=2232#comment-168381 [...] Pax your OSGi tutorials! By adreghiciu Today I just bumped into two OSGi tutorials related to CXF-DOSGi which is the reference Implementation of the Distribution Software (DSW) component of the Distributed OSGi Specification (RFC 119). Well, you may ask yourself: And what’s so interesting about that? Well, for some the tutorial may be interesting as is a “hot” subject nowadays. But my interest is in how you could use Pax Runner to improve user experience related to running such tutorials. Lets take for example the “Getting Started” with CXF-DOSGi. You will find the sections where you have to setup your OSGi container (either Felix or Equinox). User will have to first find out framework jars somewhere (okay, for Felix there is a link to downloads page), unpack it, start it, type/copy&paste a long start command. The alternative? Well, download and install just one tool: Pax Runner. Then? Start latest Felix with CXF-DOSGi: pax-run –profiles=cxf.dosgi.singlebundle wanna start Equinox?: pax-run –profiles=cxf.dosgi.singlebundle –platform=equinox And what’s the big deal? Beside the fact that you do not care where and how you deal with Felix or Equinox and that will download and install latest CXF DOSGi, nothing really. But what if you have a more complex example? Lets see in the next sample that is related: Using iPOJO and CXF-DOGi. In this tutorial, once again, you need Felix (okay, okay…you may already have it from the previous tutorial). Then you need the cxf and ipojo bundles. While using Pax Runner you would have to just do: pax-run –profiles=cxf.dosgi.singlebundle,ipojo Already getting the point? No? Then lets get further. You will also need a set of other bundles which are defined in the tutorial. Again, copy & paste. What else could be done? Well just put all of them in a public available text file as this ones I made for this blog: ipojo-dosgi-provider and ipojo-dosgi-consumer and then the instructions will be simple as: start provider: pax-run –args=http://tinyurl.com/nnog62 start consumer: pax-run –args=http://tinyurl.com/mjbqe2 So what was all of this about? In my view using Pax Runner in tutorials will improve user experience and will focus user on the subject at hand, not on infrastructure issues. Actually people is already using Pax Runner in this way. [...] [...] Pax your OSGi tutorials! By adreghiciu Today I just bumped into two OSGi tutorials related to CXF-DOSGi which is the reference Implementation of the Distribution Software (DSW) component of the Distributed OSGi Specification (RFC 119). Well, you may ask yourself: And what's so interesting about that? Well, for some the tutorial may be interesting as is a "hot" subject nowadays. But my interest is in how you could use Pax Runner to improve user experience related to running such tutorials. Lets take for example the "Getting Started" with CXF-DOSGi. You will find the sections where you have to setup your OSGi container (either Felix or Equinox). User will have to first find out framework jars somewhere (okay, for Felix there is a link to downloads page), unpack it, start it, type/copy&paste a long start command. The alternative? Well, download and install just one tool: Pax Runner. Then? Start latest Felix with CXF-DOSGi: pax-run –profiles=cxf.dosgi.singlebundle wanna start Equinox?: pax-run –profiles=cxf.dosgi.singlebundle –platform=equinox And what's the big deal? Beside the fact that you do not care where and how you deal with Felix or Equinox and that will download and install latest CXF DOSGi, nothing really. But what if you have a more complex example? Lets see in the next sample that is related: Using iPOJO and CXF-DOGi. In this tutorial, once again, you need Felix (okay, okay…you may already have it from the previous tutorial). Then you need the cxf and ipojo bundles. While using Pax Runner you would have to just do: pax-run –profiles=cxf.dosgi.singlebundle,ipojo Already getting the point? No? Then lets get further. You will also need a set of other bundles which are defined in the tutorial. Again, copy & paste. What else could be done? Well just put all of them in a public available text file as this ones I made for this blog: ipojo-dosgi-provider and ipojo-dosgi-consumer and then the instructions will be simple as: start provider: pax-run –args=http://tinyurl.com/nnog62 start consumer: pax-run –args=http://tinyurl.com/mjbqe2 So what was all of this about? In my view using Pax Runner in tutorials will improve user experience and will focus user on the subject at hand, not on infrastructure issues. Actually people is already using Pax Runner in this way. [...]

]]> By: Tom H http://blog.springsource.org/2009/06/16/deploying-wars-to-the-osgi-web-container-is-now-even-easier/comment-page-1/#comment-167436 Tom H Sun, 28 Jun 2009 14:00:58 +0000 http://blog.springsource.com/?p=2232#comment-167436 Has anyone looked into why either the RI or pax-run does not honor proxies? Even when I use the proper -Dhttp.proxyHost=my.proxy.host -Dhttp.proxyPort=80 I still get the build bombing out. Has anyone looked into why either the RI or pax-run does not honor proxies? Even when I use the proper

-Dhttp.proxyHost=my.proxy.host -Dhttp.proxyPort=80

I still get the build bombing out.

]]> By: Andy Wilkinson http://blog.springsource.org/2009/06/16/deploying-wars-to-the-osgi-web-container-is-now-even-easier/comment-page-1/#comment-167326 Andy Wilkinson Thu, 18 Jun 2009 07:44:44 +0000 http://blog.springsource.com/?p=2232#comment-167326 @Mahesh, thanks for reporting this. I assume you're referring to the dm Server snapshot builds? If you have a moment, could please <a href="https://issuetracker.springsource.com/browse/DMS" rel="nofollow">open a JIRA</a> for the problem that you're seeing? @Mahesh, thanks for reporting this. I assume you're referring to the dm Server snapshot builds? If you have a moment, could please open a JIRA for the problem that you're seeing?

]]> By: Mahesh http://blog.springsource.org/2009/06/16/deploying-wars-to-the-osgi-web-container-is-now-even-easier/comment-page-1/#comment-167324 Mahesh Thu, 18 Jun 2009 07:05:29 +0000 http://blog.springsource.com/?p=2232#comment-167324 When I am trying to evaluate with the snapshots builds 264 to 266 ,during deployment of a war file I got javax.management.MalformedObjectNameException: Invalid character ':' in value part of property execption.You might want to look into this When I am trying to evaluate with the snapshots builds 264 to 266 ,during deployment of a war file I got javax.management.MalformedObjectNameException: Invalid character ':' in value part of property execption.You might want to look into this

]]> By: Andy Wilkinson http://blog.springsource.org/2009/06/16/deploying-wars-to-the-osgi-web-container-is-now-even-easier/comment-page-1/#comment-167319 Andy Wilkinson Wed, 17 Jun 2009 08:31:31 +0000 http://blog.springsource.com/?p=2232#comment-167319 @Pierre-Antoine, no, unfortunately not. However, a number of other SpringSource employees will be at Jazoon - grab one of them and they'll be happy to discuss this with you. Alternatively, you can post any questions you have on the <a href="http://forum.springsource.org/forumdisplay.php?f=53" rel="nofollow">dm Server forums</a>. @Anoop Thanks. This should now be fixed in 2.0.0.CI-R315-B264.zip and later. @Pierre-Antoine, no, unfortunately not. However, a number of other SpringSource employees will be at Jazoon – grab one of them and they'll be happy to discuss this with you. Alternatively, you can post any questions you have on the dm Server forums.

@Anoop Thanks. This should now be fixed in 2.0.0.CI-R315-B264.zip and later.

]]> By: Anoop http://blog.springsource.org/2009/06/16/deploying-wars-to-the-osgi-web-container-is-now-even-easier/comment-page-1/#comment-167315 Anoop Wed, 17 Jun 2009 06:39:01 +0000 http://blog.springsource.com/?p=2232#comment-167315 The dm server development snapshots builds have doubled in size (around 51 MB from 25 MB) recently with all files getting duplicated. You might want to look into this. The dm server development snapshots builds have doubled in size (around 51 MB from 25 MB) recently with all files getting duplicated. You might want to look into this.

]]> By: Pierre-Antoine Grégoire http://blog.springsource.org/2009/06/16/deploying-wars-to-the-osgi-web-container-is-now-even-easier/comment-page-1/#comment-167311 Pierre-Antoine Grégoire Tue, 16 Jun 2009 21:15:33 +0000 http://blog.springsource.com/?p=2232#comment-167311 Will you by any chance attend Jazoon in Zurich next week? I'd really like to give this a try and discuss it until then. Will you by any chance attend Jazoon in Zurich next week? I'd really like to give this a try and discuss it until then.

]]>