On Sun, Jul 5, 2009 at 2:35 AM, Michael Elman<[email protected]> wrote: > We don't have support for multiple applications yet. We discussed it as a > "nice to have" feature and didn't dive into the details yet. > I think the main idea was to be able to load multiple applications, but to > try resolving paths conflicts. > Anyway it's just an idea, we can continue discussing it, but anyway I don't > think we'll want it for 0.1
Right, not something for 0.1, and right now I prefer that the developer should just combine everything into a single Application class. > If I understand your use-case correctly, you can use the Wink with multiple > servlets using the symphony.requestProcessorAttribute parameter. I think > using this parameter for testing is ok and we don't need to develop anything > to generate it. The servlet-mapping will resolve possible paths conflicts. Right, the parameter works, I was just hoping that we might invert the default behavior if possible (i.e. if you wanted to use the AdminServlet, you would have to specify the requestProcessorAttribute for both RestServlet and AdminServlet) since people migrating over would have multiple RestServlets rather than any of the Wink specific features (obviously). Just throwing a use case pattern out here, some developers may develop a single WAR that had a context root of something like "/restapi/" and then have one JAX-RS Application with a servlet mapping of "/v1" and then another JAX-RS Application with a servlet mapping of "/v2" for versions 1 and 2 of their API respectively. The motivation is that they could re-use their existing resource classes where the code doesn't need to be changed between Applications (since the @Path wouldn't allow 2 different "/v1/Item" and "/v2/Item"). I don't consider this a good (nor bad) practice but something that I was thinking about. I think using subresource locators as an alternate means to achieve the above becomes somewhat more difficult if you ever wanted to use anything beyond method injection. In the end we need to document this somewhere (I couldn't find it in the original PDF but it's probably in the site documentation) and if users start complaining, we can re-investigate the options. > What do you think? Also, I think if it became an issue, we could always have the container integration layers use their own RestServlet and then they would have the luxury of generating their own unique attribute. I would prefer it if we could have things work out of the box for the vast majority of use cases obviously so integration layers don't have to do too many special things. Maybe thinking too far ahead, but there would have to be customized RestServlet behavior for EE 6 container aware integration layers anyway so it's better for them to go ahead and either extend off the internal one or to create their own. > On Thu, Jul 2, 2009 at 11:22 PM, Bryant Luk <[email protected]> wrote: > >> Thanks, I think I understand the reasoning and the implementation >> better between Eli and your messages. Let me think about this for a >> bit. >> >> For the basic improvement that Eli suggested where multiple JAX-RS >> Applications are allowed via a ; or something else, is the assumption >> that you could find a common url pattern and make the @Path values be >> "right"? For instance, if I had a bookstore application and a >> shoestore application with (context root)/bookstore/item1 and (context >> root)/shoestore/item1 as two intended URLs, you would have the URL >> pattern be /* and all bookstore resources pre-pended with >> @Path("/bookstore/{item}") and shoestore resources pre-pended with >> @Path("/shoestore/{item}") (and also hope that there aren't >> "undefined" scenarios where 2 paths are unknowingly exactly the same)? >> An unlikely example but just making sure I understand the suggestion >> and the implications. >> >> In any case, yes, I would hope the normal situation would be only one >> RestServlet per war. I was trying to isolate some of the JAX-RS >> Applications because I don't want some of the @Providers to cross >> Applications. Originally the tests were written in numerous small >> applications but in order to limit the number of Maven submodules, I >> wanted to combine the applications together without the @Providers >> crossing over. >> >> As far as the shared library point, I think both Eli and Michael have >> answered my question. >> >> On Thu, Jul 2, 2009 at 12:56 PM, Michael Elman<[email protected]> wrote: >> > Hi Bryant , >> > >> > this parameter is used in order to provide an additional functionality, >> like >> > Administration Servlet and a runtime registration. >> > The reason is simple: we want be able to access the RequestProcessor >> > instance from sources that are different that the RestServlet: other >> > servlets, JMX, spring beans and so on. >> > Of cause if this functionality is not required, we can use an >> autogenerated >> > value. >> >> >> >> > >> > >> > On Thu, Jul 2, 2009 at 4:51 PM, Bryant Luk <[email protected]> wrote: >> > >> >> Hi Eli, >> >> >> >> Just curious why we need the application developer to add that >> >> parameter. Is there any way that we can autogenerate that parameter >> >> within the runtime? The reasons why I think we should autogenerate: >> >> >> >> 1) Application portability. If other implementations take their >> >> JAX-RS application and switch to Wink (or start with Wink), the first >> >> impression may be that we don't work out of the box. >> > >> > >> > The parameter is needed only if there are multiple RestServlet instances >> > within the same war. I believe that a normal situation is to have a >> single >> > RestServlet per war. If this is the case, such a parameter is not needed. >> So >> > it won't work out of the box only in a complex cases. >> > >> > >> >> >> >> 2) I haven't tested this but if we use Wink as a shared library >> >> across a container's applications (such as Geronimo/WebSphere), I >> >> think this would cause some administration headaches since every >> >> parameter value (I'm assuming) has to be unique. Some application >> >> developers might not communicate their unique attribute names, and >> >> this would be a really hard thing to find out when an application >> >> doesn't work correctly. >> >> >> > >> > What do you mean by using Wink as a shared library? If you mean sharing >> it >> > between wars (putting it in a parent classloader), it won't cause any >> > problems, since the parameter should be unique per ServletConfig, meaning >> it >> > should be unique in the same war, but different wars can use the same >> name. >> > >> > >> >> >> >> I think we can have it as an optional attribute if you want to use the >> >> same RequestProcessor across two servlet instances, just that by >> >> default, we generate a unique one per servlet instance. >> >> >> >> Thoughts? >> >> >> >> On Thu, Jul 2, 2009 at 3:34 AM, Baram, Eliezer<[email protected]> wrote: >> >> > Hi Bryant >> >> > The RestServlet stores the requestProcessor on the servletContext, by >> >> default it saves it under an attribute named >> >> RequestProcessor.class.getName() >> >> > >> >> > If you register more then one servlet and you want each to have a >> >> separate RequestProcessor you need to indicate the RestServlet to save >> the >> >> RequestProcessor under a different attribute. >> >> > >> >> > You can specify the attribute name by setting the >> >> "symphony.requestProcessorAttribute" init parameter of the RestServlet. >> >> > See modification below. >> >> > >> >> > --Eli >> >> > >> >> > >> >> > >> >> > -----Original Message----- >> >> > From: Bryant Luk [mailto:[email protected]] >> >> > Sent: Thursday, July 02, 2009 2:09 AM >> >> > To: [email protected] >> >> > Subject: Multiple RestServlets in single web application? >> >> > >> >> > Hi, >> >> > >> >> > Does the RestServlet support multiple servlet instances in the same >> >> > web application? >> >> > >> >> > It seems that only the first servlet (in alphabetical order) is fired >> >> > up correctly. If I have two instances of the servlet, say >> >> > MessageBodyWriterExceptions and MessageBodyReaderExceptions, only >> >> > MessageBodyReaderExceptions seems to work. If I then rename >> >> > MessageBodyReaderExceptions to "Z" (or comment out the servlet >> >> > definition), then my MessageBodyWriterExceptions servlet JAX-RS app >> >> > works. >> >> > >> >> > My web.xml: >> >> > >> >> > <web-app> >> >> > <display-name>Archetype Created Web Application</display-name> >> >> > <servlet> >> >> > <servlet-name>MessageBodyWriterExceptions</servlet-name> >> >> > >> >> >> <servlet-class>org.apache.wink.server.internal.servlet.RestServlet</servlet-class> >> >> > <init-param> >> >> > <param-name>javax.ws.rs.Application</param-name> >> >> > >> >> >> <param-value>org.apache.wink.jaxrs.test.providers.writerexceptions.Application</param-value> >> >> > </init-param> >> >> > <load-on-startup>1</load-on-startup> >> >> > </servlet> >> >> > <servlet> >> >> > <servlet-name>MessageBodyReaderExceptions</servlet-name> >> >> > >> >> >> <servlet-class>org.apache.wink.server.internal.servlet.RestServlet</servlet-class> >> >> > <init-param> >> >> > <param-name>javax.ws.rs.Application</param-name> >> >> > >> >> >> <param-value>org.apache.wink.jaxrs.test.providers.readerexceptions.Application</param-value> >> >> > </init-param> >> >> > [E.B] <init-param> >> >> > <param-name>symphony.requestProcessorAttribute</param-name> >> >> > <param-value>requestProcessorAttribute_2</param-value> >> >> > </init-param> >> >> > <load-on-startup>1</load-on-startup> >> >> > </servlet> >> >> > <servlet-mapping> >> >> > <servlet-name>MessageBodyWriterExceptions</servlet-name> >> >> > <url-pattern>/writerexceptions/*</url-pattern> >> >> > </servlet-mapping> >> >> > <servlet-mapping> >> >> > <servlet-name>MessageBodyReaderExceptions</servlet-name> >> >> > <url-pattern>/readerexceptions/*</url-pattern> >> >> > </servlet-mapping> >> >> > </web-app> >> >> > >> >> > -- >> >> > >> >> > - Bryant Luk >> >> > >> >> >> >> >> >> >> >> -- >> >> >> >> - Bryant Luk >> >> >> > >> >> >> >> -- >> >> - Bryant Luk >> > -- - Bryant Luk
