JBoss Web Services
  1. JBoss Web Services
  2. JBWS-3479

Implement @org.jboss.ws.api.annotation.WebContext support for POJO endpoints

    Details

    • Type: Feature Request Feature Request
    • Status: Open Open (View Workflow)
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: jbossws-integration
    • Security Level: Public (Everyone can see)
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Description

      We support @WebContext on EJB endpoints now.
      Since Servlet 3.0 spec allows web deployments
      without web.xml it is worth to support this annotation
      also on POJO WS endpoints.
      There are however two restrictions that must be ensured.
      If there are multiple WS endpoints in web archive
      all annotated with @WebContext annotation then the following
      restriction must apply:

      • contextRoot value must be the same for all @WebContext annotated endpoints
      • virtualHost value must be the same for all @WebContext annotated endpoints
      • if there's provided jboss-web.xml or jboss-webservices.xml with context root in deployment
        this DD driven context root will have higher priority than context root specified in annotations.

        Activity

        Hide
        Jim Ma
        added a comment -

        I'd prefer to not support this. We introduce the @WebContext for the ejb ws endpoint, partly because there is no descriptor in ejb archive to specify the contextRoot, urlPattern, virtualHost etc. Given there is web.xml which can specify all these things in @WebContext, we can ask user to configure in web.xml instead of annotation. It will be more portable and less complex to check various above restriction. Your opinion ?

        Show
        Jim Ma
        added a comment - I'd prefer to not support this. We introduce the @WebContext for the ejb ws endpoint, partly because there is no descriptor in ejb archive to specify the contextRoot, urlPattern, virtualHost etc. Given there is web.xml which can specify all these things in @WebContext, we can ask user to configure in web.xml instead of annotation. It will be more portable and less complex to check various above restriction. Your opinion ?
        Hide
        Alessio Soldano
        added a comment -

        Hi Jim,
        well, my point of view is that this would a) simplify the api from a user point of view (you could use this annotation regardless of the type of ws endpoint, pojo or ejb3), b) allow fully configuring pojo endpoints without web.xml, again something users might like.
        The context-root, btw, is not set in the web.xml, but in the jboss-web.xml, which is still not portable, so to me allowing using the @WebContext annotation here would not really affect portability.

        This said, I agree supporting this adds a bit of complexity when computing the actual context-root, virtual-host etc., but I still believe it's worth exploring the feasibility of this feature req issue.

        Show
        Alessio Soldano
        added a comment - Hi Jim, well, my point of view is that this would a) simplify the api from a user point of view (you could use this annotation regardless of the type of ws endpoint, pojo or ejb3), b) allow fully configuring pojo endpoints without web.xml, again something users might like. The context-root, btw, is not set in the web.xml, but in the jboss-web.xml, which is still not portable, so to me allowing using the @WebContext annotation here would not really affect portability. This said, I agree supporting this adds a bit of complexity when computing the actual context-root, virtual-host etc., but I still believe it's worth exploring the feasibility of this feature req issue.
        Hide
        Jim Ma
        added a comment -

        Ok. Alessio, Let's evaluate how much effort shall we pay for this feature and decide the next step.

        Show
        Jim Ma
        added a comment - Ok. Alessio, Let's evaluate how much effort shall we pay for this feature and decide the next step.

          People

          • Assignee:
            Unassigned
            Reporter:
            Richard Opalka
          • Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated: