You can see it the opposite as well ie you go through http where you can not desire it.
50-50 case i think. Le 5 oct. 2015 13:52, "John D. Ament" <[email protected]> a écrit : > The fundamental problem (if I had to guess) is that let's say I'm testing a > REST API (heck even using the REST extension), persistence extension > doesn't know that my request went through since I'm controlling it, so its > call backs won't take effect. By running embedded, you're more likely to > not be inside the same transaction, which is one of the things being banked > on I'm sure. > > John > > On Mon, Oct 5, 2015 at 3:26 AM Alex Soto <[email protected]> wrote: > > > If there are bugs/improvements let s do it. I am thinking in terms of > doing > > the life of developers easier and in fact changing the protocol to > servlet > > dos not introduce (a priori) any back incompatibility but a lot of > > extensions are going to work with embedded mode. > > > > Alex. > > > > El dg, 4 oct 2015 a les 7:53 Romain Manni-Bucau <[email protected]> > va > > escriure: > > > > > Hi Alex > > > > > > Local protocol allows nicer start so very tempted to keep it like that. > > > Servlet protocol has few bugs/issues and is not what you target by > > default > > > with embedded adapters IMO. > > > Le 4 oct. 2015 01:25, "John D. Ament" <[email protected]> a écrit > : > > > > > > > Hey Alex, > > > > > > > > To be honest, I find the protocol section of arquillian the most > > > confusing > > > > for new users to pick up. Why should they care what the protocol > > > > transferring the test data is using? I remember at the beginning, > AS7 > > > had > > > > a JMX protocol. This made tons of sense, since it didn't impact the > > > > running application. No one understood why their tests stopped work > > > > though! Truth be told, the fact that most people end up relying on > > > > servlet, without even realizing that its the arquillian runtime > > starting > > > an > > > > HTTP request makes it confusing to understand scope. Basically, > users > > > end > > > > up relying on the servlet protocol to start their HTTP request for > > them, > > > > instead of starting an HTTP request for their test invocation. > > > > > > > > Just curious, is this out on discourse somewhere? I can continue my > > whine > > > > fest there :-) > > > > > > > > John > > > > > > > > On Sat, Oct 3, 2015 at 4:58 PM Alex Soto <[email protected]> wrote: > > > > > > > > > Hello mates, > > > > > > > > > > I send this email to start a discussion for a change on TomEE > > > Arquillian > > > > > Adapter. > > > > > > > > > > The other day, because of the book (Arquillian In Action), I > checked > > > the > > > > > protocol used by different adapters. I noticed that only Weld > adapter > > > and > > > > > TomEE embedded adapter are using the local protocol,all other ones > > are > > > > > using the Servlet 3.0 protocol. And maybe you are asking why this > is > > > > > important? Well the problem is that a lot of extensions requires > this > > > > > protocol to work, for example Arquillian Persistence extension or > > > > Arquillan > > > > > Warp extension. In case a user wants to use embedded TomEE and one > > > > > extension that requires servlet protocol, it would get a cryptic > > > > exception. > > > > > Of course there is a workaround and it is overriding the default > > > protocol > > > > > by using protocol special tag in arquillian.xml and adding the > > > > > servlet-protocol dependency. > > > > > > > > > > I think that it would be easier for everyone if all adapters works > in > > > the > > > > > same way. With the release of TomEE 7 I think it could be a good > > > > > opportunity to make this change in the Arquillian embedded adapter > as > > > > well > > > > > and align with the rest of the containers. > > > > > > > > > > The change to be done is very simple in terms of code (Adding one > > > > > dependency and change one String of the adapter). > > > > > > > > > > What do you think? From the point of view of Arquillian community > it > > > > would > > > > > be the logic step. > > > > > > > > > > Alex. > > > > > > > > > > > > > > >
