Hi Romain,

Thanks for fixing it on 1.7.x.
I will check the rest of my apps now.... hmmm... tomorrow. :)
Meanwhile I will try to run the tests locally.

[]s,
Thiago.


On Mon, Jan 26, 2015 at 8:55 AM, Romain Manni-Bucau <[email protected]>
wrote:

> Pushed an enhancement,
>
> idea is to check if servlet mapping explicitely maps the servlet in
> the jaxrs subcontext.
>
> I'll let you review the fix (in CxfJAXRSFilter) and the few tests I
> added in arquillian-tomee-jaxrs-test (AvoidConflict*Test) - on
> develop.
>
> If it is not ok for everybody we can end up having a flag to switch
> back to real servlet.
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-26 11:58 GMT+01:00 Thiago Veronezi <[email protected]>:
> > Hi guys,
> >
> > I won't have much time to check it further today, but I was able to
> update
> > this project so you can use as example.
> >
> > https://github.com/tveronezi/rssreader
> >
> > It works on 1.7.1, but it crashes on 1.7.2.
> >
> > []s,
> > Thiago.
> >
> >
> >
> >
> > On Mon, Jan 26, 2015 at 5:52 AM, Jean-Louis Monteiro <
> > [email protected]> wrote:
> >
> >> 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!
> >> > >> >>
> >> > >>
> >> >
> >>
>

Reply via email to