>From your summary Romain, I'd go back to the servlet solution. Seems more deterministic and easy.
>From a performance point of view, it's seems also much better isn't it? >From my understanding, even a simple JS or HTML static resource needs to go through the filter. It seems hard to get the filter work without re-implementing part or the servlet mapping and the JAX RS mapping. I mean really work without any tricks. For example, I often get a WebApplicationException when I want a simple resource or a simple servlet. So from my point of view the filter seems to solve interesting situations for JAX-RS but at the price of adding more complexity to Tomcat servlet management as well as probably impacting performances. And when you say the impl is more complicated, I can't imagine someone else maintaining this code and logic. conflict immediately with resources (html, css, js) > --> can you add more details please? Probably does not bring much to the discussion, but I'm use to say, the simpler the better. There is another point that matters (at least to me). Having a simple app on Tomcat works fine. Having the same app on WebProfile flavor also works fine. But having the same one on JAX RS or plus may or not fail and have less throughput. For instance, not the same stack nor process between Tomcat, TomEE WP and TomEE Plus is a stopper for me. Jean-Louis -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Mon, Jan 26, 2015 at 10:31 AM, Romain Manni-Bucau <[email protected]> wrote: > well basically we have 2 ways of implementing JAXRS "mapping" > - as the result of a servlet (old implementation) > - as a filter (current) > > Pro for servlet: > - everybody does it -> NO surprises in its usage > - simpler than what we have > > Cons for servlet: > - conflict immediately with resources (html, css, js) > - standard servlet rules applies so we can conflict with servlets as well > > > Pro for filter: > - we can solve it > - more complicated impl > > Cons: > - nobody does it (means we are not as close of a standard as we could) > - we loose some servlet rules like /foo/* has a higher priority than > /* for request /foo/bar > > > Current implementation simply does this logic: if a servlet is mapped > and is not the default one then use this servlet, else if a resource > matches the request then return its content else use jaxrs. This allow > JAXRS to not hide resources even when mapping is conflicting - default > case whatever we do when a user doesn't specify an Application mapping > for an @ApplicationPath. > > I know David wanted it to work OOTB, personally I don't care that much > since I consider it is a bad practise to have conflicting endpoints - > the case in this example, index should be mapped to a welcome-file and > that's it IMO. > > Last point it is still deactivable through > openejb.jaxrs.static-first=false in conf/system.properties and > shouldn't happen if there is a JAXRS mapping. > > > Hope I didn't forget too much points. > > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-01-26 10:18 GMT+01:00 Jonathan Gallimore < > [email protected]>: > > Hi, > > > > Interesting issue. I thought I'd create a new thread for this issue as I > > think it probably needs some discussion and agreement on how best to fix, > > and think that's best done on a discussion thread as opposed to the vote > > thread. > > > > I'll leave the vote open at least for a few more hours to see if there is > > any further feedback that comes in. > > > > If I have understood it correctly, the issue is that you have servlet > > mappings like: > > > > <servlet-mapping> > > <servlet-name>default</servlet-name> > > <url-pattern>/app/*</url-pattern> > > </servlet-mapping> > > <servlet> > > <servlet-name>index</servlet-name> > > <jsp-file>/index.jsp</jsp-file> > > </servlet> > > <servlet-mapping> > > <servlet-name>index</servlet-name> > > <url-pattern>/*</url-pattern> > > </servlet-mapping> > > > > and an EJB or POJO like: > > > > @Path("rest") > > public class RestService { > > > > @Path("users") > > public List<Users> getUsers() { > > .... > > } > > } > > > > and for some reason the index.jsp is "trumping" the Rest endpoint for > > /rest/users. > > > > Is that correct? Reverting out those 2 commits does give us other issues > so > > it sounds like this may require a different fix potentially? > > > > Any thoughts? > > > > Jon > > > > On Mon, Jan 26, 2015 at 8:21 AM, Romain Manni-Bucau < > [email protected]> > > wrote: > > > >> Hello Thiago, > >> > >> if you map > >> > >> <servlet> > >> <servlet-name>index</servlet-name> > >> <jsp-file>/index.jsp</jsp-file> > >> </servlet> > >> <servlet-mapping> > >> <servlet-name>index</servlet-name> > >> <url-pattern>/*</url-pattern> > >> </servlet-mapping> > >> > >> then you explicitely ask all your calls to be mapped to index servlet > >> so it seems ok to me. > >> > >> Did I misunderstand you? > >> > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2015-01-26 3:00 GMT+01:00 Thiago Veronezi <[email protected]>: > >> > -1 -> The default servlet is catching the RS requests. > >> > > >> > Basically, in single-page-applications, I need to map the default > servlet > >> > in a special way... > >> > > >> > . > >> > . > >> > . > >> > <!-- The trick is to put all your static files under the same > directory > >> > and map the "default" servlet to it --> > >> > <servlet-mapping> > >> > <servlet-name>default</servlet-name> > >> > <url-pattern>/app/*</url-pattern> > >> > </servlet-mapping> > >> > > >> > <!-- Any other request will point to the "index.jsp" page. This way > YUI > >> > will be able to manage page transitions > >> > at the client side in case the user starts the application > from a > >> > permalink. --> > >> > <servlet> > >> > <servlet-name>index</servlet-name> > >> > <jsp-file>/index.jsp</jsp-file> > >> > </servlet> > >> > <servlet-mapping> > >> > <servlet-name>index</servlet-name> > >> > <url-pattern>/*</url-pattern> > >> > </servlet-mapping> > >> > . > >> > . > >> > . > >> > > >> > TomEE 1.7.2 returns "index.jsp" for all my rest calls (GET > >> > http://localhost:8080/myapp/rest/users, for example). > >> > > >> > After reverting back these two commits, the system gets back to > normal. > >> > > >> > https://git1-us-west.apache.org/repos/asf?p=tomee.git;a=commit;h=544806da419bc2f5ab8bc936a989ff99bc9d891b > >> > > >> > https://git1-us-west.apache.org/repos/asf?p=tomee.git;a=commit;h=cb135dd6344f93ed24888cafcc05d0cfbb0c62a9 > >> > > >> > @Romain, > >> > Can you take a look? I'm not sure what was the idea. > >> > > >> > []s, > >> > Thiago. > >> > > >> > > >> > On Sun, Jan 25, 2015 at 9:36 AM, Jonathan Gallimore < > >> > [email protected]> wrote: > >> > > >> >> Hi, > >> >> > >> >> Sorry, should have added that. It's: > >> >> > https://repository.apache.org/content/repositories/orgapachetomee-1045 > >> >> > >> >> Regards > >> >> > >> >> Jon > >> >> > >> >> > >> >> > >> >> > On 25 Jan 2015, at 14:19, jieryn <[email protected]> wrote: > >> >> > > >> >> > On Sat, Jan 24, 2015 at 4:20 PM, Jonathan Gallimore > >> >> > <[email protected]> wrote: > >> >> >> Maven Repo: > >> https://dist.apache.org/repos/dist/dev/tomee/staging-1045/ > >> >> > > >> >> > Where is the actual Maven artifact staging repository for this? So > my > >> >> > projects which depend on TomEE can be built and tested against the > >> >> > candidate. Thanks! > >> >> > >> >
