Announcement Announcement Module
Collapse
No announcement yet.
First Web Bundle Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • First Web Bundle

    I got stuck working on my first web bundle, trying to add a controller.

    The bundle imports only Spring 2.5.4 in MANIFEST.MF:
    > Import-Library: org.springframework.spring;version="2.5.4"

    Now subclassing SimpleFormController gives me
    > The type javax.servlet.http.HttpServletResponse cannot be resolved. It is indirectly referenced from required .class files.

    That error can be resolved by importing the Servlet API using
    > Import-Bundle: com.springsource.javax.servlet;version="2.5.0"

    However, that produces an error upon deployment:
    > com.springsource.platform.osgi.framework.OsgiFrame workException:
    > Expansion of the library import(s) failed. One or more packages explicity imported in the manifest is also
    > imported as a result of one or more library imports. The packages are:
    > javax.servlet, javax.servlet.http

    Thanks,
    -Ralph.

  • #2
    First Web Bundle

    Hi Ralph,

    Can you please include the complete contents of the manifest for your web module
    and briefly describe the structural layout of the JAR you're creating?

    With that information, I'll be able to better help diagnose the problem.

    Thanks,

    Sam

    Comment


    • #3
      First Web Bundle

      Sam,

      I've worked around the issue by adding com.springsource.javax.servlet-2.5.0.jar to the Eclipse build path (not the bundle dependencies). I guess that's not how it's supposed to work, however.

      My src directory contains
      * (default package)TestController.java
      * META-INF/
      * META-INF/MANIFEST.MF
      * META-INF/spring/appCtx.xml
      * index.jsp

      > // TestController.java
      > public class TestController extends SimpleFormController implements InitializingBean {
      >
      > public ModelAndView handleRequest() throws Exception {
      > System.out.println("handleRequest() called on " + this);
      > return new ModelAndView("hello world");
      > }
      >
      > @Override
      > protected Object formBackingObject(HttpServletRequest request) throws Exception {
      > return new Object();
      > }
      >
      > public void afterPropertiesSet() throws Exception {
      > System.out.println("afterPropertiesSet() called on " + this);
      > }
      > }


      > //MANIFEST.MF
      > Manifest-Version: 1.0
      > Bundle-Name: FirstBundle Bundle
      > Bundle-SymbolicName: FirstBundle
      > Bundle-Version: 1.0.0
      > Import-Library: org.springframework.spring;version="2.5.4"
      > Platform-ModuleType: Web

      > // appCtx.xml
      > <beans:beans ...>
      > <beans:bean name="/controller.htm" class="TestController" />
      > </beans:beans>

      Thanks for looking into this!

      Cheers,
      -Ralph.

      Comment


      • #4
        First Web Bundle

        Hi Ralph,

        > I've worked around the issue by adding com.springsource.javax.servlet-2.5.0.jar
        > to the Eclipse build path (not the bundle dependencies). I guess that's not how
        > it's supposed to work, however.

        This may have already been addressed within the Tooling. In any case, the Servlet API is required on the Eclipse classpath at compile-time yet provided by the Platform at run-time.

        So, if you haven't made any further progress with this, please create a JIRA issue and provide the version of the Platform and the Tools that you are using as well as the information you've provided here (e.g., manifest, etc.).

        https://issuetracker.springsource.com/secure/CreateIssue!default.jspa

        Now a few pointers...

        > My src directory contains
        > * (default package)TestController.java

        Even in a Web Module, you must place your classes (i.e., .class files) in /WEB-INF/classes just as you would in a traditional WAR. Otherwise, your classes will made available via HTTP requests, which is of course a security hole.

        Furthermore, you should refrain from using the default package in an OSGi environment. Use a sensible package hierarchy instead.

        Regards,

        Sam

        Comment

        Working...
        X