Announcement Announcement Module
Collapse

Spring Dynamic Modules forum decommissioned in favor of Eclipse Gemini Blueprint

With the official first release of Eclipse Gemini Blueprint shipped, the migration of the Spring Dynamic Modules code base to the Eclipse Foundation, as part of the Gemini project, has been completed.

As such, this forum has been decommissioned in favour of the Eclipse Gemini forums.
See more
See less
BRITS vs. Temporary Spring-DM Repo Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • BRITS vs. Temporary Spring-DM Repo

    I've been trying very hard to use BRITS (SpringSource bundle repository) as much as possible and to avoid using the "temporary" Spring-DM repo on Amazon S3. But I keep running into things that lure me back to the temporary repository.

    I thought I'd bring them up as items to discuss in this forum...just to see if I'm overlooking something that someone can help me with. And, I'll create JIRA issues against BRITS to see if these problems can be addressed.

    Specifically, I have three issues at the moment:

    First, the Catalina bundles in BRITS have *required* dependencies on javax.ejb, javax.mail, and several other similar packages that I'm pretty sure should be optional. This means that I can't use Tomcat and the web extender from BRITS unless I also install a ton of other bundles that my app doesn't really need. This seems to violate the spirit of modularity, as you don't really need EJB packages to server web pages with Tomcat.

    Second, if I use the web extender from BRITS, it defaults to using Tomcat--as documented--but there isn't a web extender Jetty fragment that switches the web extender to use Jetty. There *is* such a fragment in the temporary repository, but that fragment's Fragment-Host references a symbolic name that is different from the web extender in BRITS. It seems that if the web extender in BRITS is going to have a different symbolic name than the one in the temporary repository, then there should also be a corresponding Jetty fragment in BRITS.

    Finally, I submit that if the temporary Spring-DM repository is truly temporary and if the Spring-DM bundles in BRITS are going to have different symbolic names, then there is a fairly significant inconsistency in the Spring-DM documentation. Perhaps the Spring-DM documentation needs to be updated to reflect the current selection of symbolic names.

  • #2
    Hi,

    I'm so glad you've reported it as I spent a couple of days trying to figure out what bundles are needed to run webapps on Spring-DM 1.2.0-m2-SNAPSHOT and was suprised to notice that Tomcat bundle (from BRITS) required EJB bundle and alike. I'd appreciate any comments how to work it around as I ended up with almost 20 bundles and am still unable to run webapps on Tomcat 6.0.18. Is catalina.start.osgi required? Why is it in 6.0.16 version? Help appreciated.

    Jacek

    Comment


    • #3
      I cannot comment on why the javax.ejb package is included. However, I can tell you that the catalina activator was tested against the catalina jar from Spring DM temporary repository (as was jetty activator and jetty jar).
      Using the activator or bundles from different repositories might work but it's not guaranteed to be so. Spring DM is not fully migrated to use artifacts just from SpringSource bundle repository, hence the reason for Spring DM temporary maven repository (http://static.springframework.org/os...osgi-repo.html).

      Comment


      • #4
        Even I had a painful time in incorporating the required bundles. These are the ones I ended up using,

        javax.servlet/com.springsource.javax.servlet.jar
        org.apache.juli/com.springsource.org.apache.juli.extras.jar
        org.apache.el/com.springsource.org.apache.el.jar
        javax.el/com.springsource.javax.el.jar
        javax.xml.rpc/com.springsource.javax.xml.rpc.jar
        javax.ejb/com.springsource.javax.ejb.jar
        javax.activation/com.springsource.javax.activation.jar
        javax.xml.soap/com.springsource.javax.xml.soap.jar
        javax.xml.stream/com.springsource.javax.xml.stream.jar
        javax.xml.bind/com.springsource.javax.xml.bind.jar
        javax.xml.ws/com.springsource.javax.xml.ws.jar
        javax.mail/com.springsource.javax.mail.jar
        org.apache.catalina/com.springsource.org.apache.catalina.jar
        javax.servlet/com.springsource.javax.servlet.jsp.jar
        org.apache.jasper/com.springsource.org.apache.jasper.org.eclipse.jdt .jar
        org.apache.coyote/com.springsource.org.apache.coyote.jar
        org.apache.jasper/com.springsource.org.apache.jasper.jar

        For the catalina-start, we ended up writing our own by adapting from the catalina-start. It turned out be very useful since it gave us full control of tomcat.

        Comment

        Working...
        X