Menu
▾
▴
resteasy-users — A general discussion list for the projects end users of RESTEasy.
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2010 |
Jan
(1) |
Feb
(2) |
Mar
(6) |
Apr
(5) |
May
(1) |
Jun
(2) |
Jul
(2) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(6) |
Dec
(4) |
| 2011 |
Jan
(4) |
Feb
(18) |
Mar
(9) |
Apr
(7) |
May
(6) |
Jun
(13) |
Jul
(11) |
Aug
(7) |
Sep
(12) |
Oct
(28) |
Nov
(12) |
Dec
(11) |
| 2012 |
Jan
(20) |
Feb
(21) |
Mar
(19) |
Apr
(12) |
May
(44) |
Jun
(23) |
Jul
(14) |
Aug
(26) |
Sep
(23) |
Oct
(7) |
Nov
(42) |
Dec
(15) |
| 2013 |
Jan
(62) |
Feb
(20) |
Mar
(14) |
Apr
(52) |
May
(29) |
Jun
(46) |
Jul
(20) |
Aug
(55) |
Sep
(27) |
Oct
(53) |
Nov
(29) |
Dec
(21) |
| 2014 |
Jan
(35) |
Feb
(44) |
Mar
(12) |
Apr
(37) |
May
(24) |
Jun
(17) |
Jul
(13) |
Aug
(1) |
Sep
(4) |
Oct
(13) |
Nov
(1) |
Dec
(1) |
| 2015 |
Jan
(11) |
Feb
(8) |
Mar
(10) |
Apr
(7) |
May
(17) |
Jun
(11) |
Jul
(13) |
Aug
(14) |
Sep
(6) |
Oct
(3) |
Nov
(7) |
Dec
(3) |
| 2016 |
Jan
(1) |
Feb
(4) |
Mar
(8) |
Apr
(2) |
May
(2) |
Jun
(10) |
Jul
|
Aug
|
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
|
From: Gabriella T. <Gab...@ni...> - 2015-07-10 03:51:22
|
I updated my RestEasy libraries from 3.0.6 to 3.0.9 on Tomcat 8 and I get the error failed to execute javax.ws.rs.NotFoundException: Could not find resource for full path: http://<host>/archive/modules/0.3.1 where my web.xml file looks like <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http ://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com /xml/ns/javaee/web-app_3_0.xsd" version="3.0"> <display-name>riskscapemr_rest</display-name> <listener> <listener-class> org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap </listener-class> </listener> <servlet> <servlet-name>Resteasy</servlet-name> <servlet-class>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher</servlet-class> </servlet> <servlet-mapping> <servlet-name>Resteasy</servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping> <context-param> <param-name>resteasy.scan</param-name> <param-value>true</param-value> </context-param> <context-param> <param-name>resteasy.servlet.mapping.prefix</param-name> <param-value>/</param-value> </context-param> </web-app> Thanx Gaby |
|
From: Ron S. <rs...@re...> - 2015-07-10 02:55:20
|
Hi Danilo, Can we see the filter? -Ron On 07/02/2015 11:17 PM, Danilo Cominotti Marques wrote: > > Hello everyone, > > > I have been facing an intermittent issue with RESTEasy 3.0.10 from > WildFly 8.2 and I don't know how to interpret it. Once a day, I > usually see the following kind of log entry from WildFly/RESTEasy: > > > 16:11:46,385 ERROR [io.undertow.request] (default task-58) UT005023: > Exception handling request to /project/rest/entity/query: > org.jboss.resteasy.spi.UnhandledException: > java.util.ConcurrentModificationException > > at > org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:247) > [resteasy-jaxrs-3.0.10.Final.jar:] > > at > org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149) > [resteasy-jaxrs-3.0.10.Final.jar:] > > at > org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:432) > [resteasy-jaxrs-3.0.10.Final.jar:] > > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:376) > [resteasy-jaxrs-3.0.10.Final.jar:] > > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) > [resteasy-jaxrs-3.0.10.Final.jar:] > > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) > [resteasy-jaxrs-3.0.10.Final.jar:] > > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > [resteasy-jaxrs-3.0.10.Final.jar:] > > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > [resteasy-jaxrs-3.0.10.Final.jar:] > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > > at > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > > at > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > > at > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > > at > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > > at > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > > at > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > > at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [rt.jar:1.8.0_31] > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [rt.jar:1.8.0_31] > > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31] > > Caused by: java.util.ConcurrentModificationException > > at java.util.ArrayList$Itr.remove(ArrayList.java:873) > [rt.jar:1.8.0_31] > > at > org.jboss.resteasy.core.ServerResponseWriter.commitHeaders(ServerResponseWriter.java:225) > [resteasy-jaxrs-3.0.10.Final.jar:] > > at > org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:54) > [resteasy-jaxrs-3.0.10.Final.jar:] > > at > org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:427) > [resteasy-jaxrs-3.0.10.Final.jar:] > > ... 32 more > > > This seems to happen to "random" endpoints from the API, and I don't > know what the cause might be. I have a JAX-RS filter that sets a > cookie in most responses from the API, but I can't identify any > problems with it. > > > Please, does anyone have any ideas? > > > Thank you in advance for any help. > > > Respectfully yours, > > > Danilo Cominotti Marques > > > > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > > > _______________________________________________ > Resteasy-users mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-users |
|
From: Craig C. <cra...@gm...> - 2015-07-09 21:47:00
|
Hi all, I'm wondering if there's a way to get the remote client's hostname/ip address when we're using Netty. Normally we'd just use @Context HttpServletRequest and getRemoteAddr() method, but we're in Netty and don't have that available to us. Is there any way we could do this? Possibly writing an "interceptor" or whatever it's called now? We're using RestEasy 3.0.10.Final and netty 4.0.25.Final if that helps. Cheers, Craig |
|
From: Danilo C. M. <dco...@gm...> - 2015-07-03 03:17:57
|
Hello everyone,
I have been facing an intermittent issue with RESTEasy 3.0.10 from WildFly
8.2 and I don't know how to interpret it. Once a day, I usually see the
following kind of log entry from WildFly/RESTEasy:
16:11:46,385 ERROR [io.undertow.request] (default task-58) UT005023:
Exception handling request to /project/rest/entity/query:
org.jboss.resteasy.spi.UnhandledException:
java.util.ConcurrentModificationException
at
org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:247)
[resteasy-jaxrs-3.0.10.Final.jar:]
at
org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149)
[resteasy-jaxrs-3.0.10.Final.jar:]
at
org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:432)
[resteasy-jaxrs-3.0.10.Final.jar:]
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:376)
[resteasy-jaxrs-3.0.10.Final.jar:]
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
[resteasy-jaxrs-3.0.10.Final.jar:]
at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
[resteasy-jaxrs-3.0.10.Final.jar:]
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
[resteasy-jaxrs-3.0.10.Final.jar:]
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
[resteasy-jaxrs-3.0.10.Final.jar:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
[jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at
io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[rt.jar:1.8.0_31]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[rt.jar:1.8.0_31]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31]
Caused by: java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.remove(ArrayList.java:873)
[rt.jar:1.8.0_31]
at
org.jboss.resteasy.core.ServerResponseWriter.commitHeaders(ServerResponseWriter.java:225)
[resteasy-jaxrs-3.0.10.Final.jar:]
at
org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:54)
[resteasy-jaxrs-3.0.10.Final.jar:]
at
org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:427)
[resteasy-jaxrs-3.0.10.Final.jar:]
... 32 more
This seems to happen to "random" endpoints from the API, and I don't know
what the cause might be. I have a JAX-RS filter that sets a cookie in most
responses from the API, but I can't identify any problems with it.
Please, does anyone have any ideas?
Thank you in advance for any help.
Respectfully yours,
Danilo Cominotti Marques
|
|
From: Ron S. <rs...@re...> - 2015-06-24 02:44:08
|
Hi Matteo, I don't much about the subject, but Bill Burke has been hard at work on the JBoss project called Keycloak, which might be relevant: http://keycloak.jboss.org/ -Ron On 06/04/2015 02:08 AM, Matteo Cusmai wrote: > > Hi all, > I am going to develop a system with a list of rest services, based on > resteasy, and 2 front end, the first is an angularjs application and > the second is a mobile app. > > I need to use openam as idp and saml2 as security protocol. Is it > possible to secure the rest services with these technologies? There is > some documentation or examples? > > Thanks in advance. > Matteo. > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Resteasy-users mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-users |
|
From: Ron S. <rs...@re...> - 2015-06-24 02:34:35
|
Hi Joice, Any question pertaining to commercial usage of any of our products (or parts thereof) needs to go via the Customer Support Portal. [1] If you currently do not hold an entitlement for the product, then please contact sales. [2] [1] https://access.redhat.com/products/red-hat-jboss-enterprise-application-platform/support-information [2] http://www.redhat.com/en/about/contact/sales -Ron On 06/05/2015 06:31 AM, Joice Joy wrote: > Hi, > > I am trying to compile the Export Control Classification Number (ECCN) > for the third-party > software being used with one of our products. > > This is to facilitate the export of the product outside US. > > Could you help us in identifying whether the followingsoftware > currently has an ECCN number and the country of origin for the code. > Also could you help in identifying whether it contains any encryption > module that > causes it to use an ECCN number for export. > > Resteasy Atom Provider > RESTEasy CDI integration module > Resteasy Guice > Resteasy Hibernate Validator Provider > Resteasy Jackson Provider > Resteasy Jackson Provider > RESTEasy JAX-RS > RESTEasy JAX-RS Client/Server Testsuite > RESTEasy JAX-RS JSAPI > Resteasy JAXB Provider > Resteasy JBoss Modules > Resteasy Jettison Provider > Resteasy Multipart Provider > Resteasy Skeleton Key AS7 Modules > RESTEasy Skeleton Key Core > Resteasy YAML Provider > > Any help with this would be great. > If this is not the right contact, please forward this mail to the > correct person. > > > Thanks and Regards, > Joice Joy > Company - Comverse > > ------------------------------------------------------------------------------ > _______________________________________________ > Resteasy-users mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-users |
|
From: Ron S. <rs...@re...> - 2015-06-10 23:27:45
|
For the record, Ramesh created https://issues.jboss.org/browse/RESTEASY-1175. On 05/13/2015 09:38 PM, Ron Sigal wrote: > Hi Ramesh, > > Ok, I see that > > @Path("utf8") > @Produces("text/plain;charset=utf-8") > @POST > public String utf8() > { > System.out.println("TestResource.utf8()"); > return "ok"; > } > ... > @Test > public void testAcceptNoUtf8() throws Exception > { > ClientRequest request = new > ClientRequest("http://localhost:8081/utf8/"); > request.accept("text/plain"); > ClientResponse<?> response = request.post(); > Assert.assertEquals(200, response.getStatus()); > String entity = response.getEntity(String.class); > System.out.println("result: " + entity); > } > > results in > >> org.jboss.resteasy.spi.NotAcceptableException: RESTEASY001530: No >> match for accept header > > whereas > > @Path("nocharset") > @Produces("text/plain") > @POST > public String noCharset() > { > return "ok"; > } > > ... > > @Test > public void testAcceptUtf8No() throws Exception > { > ClientRequest request = new > ClientRequest("http://localhost:8081/nocharset/"); > request.accept("text/plain;charset=utf-8"); > ClientResponse<?> response = request.post(); > Assert.assertEquals(200, response.getStatus()); > String entity = response.getEntity(String.class); > System.out.println("result: " + entity); > } > > works fine. The relevant code is > > @Override > public boolean isCompatible(MediaType other) > { > boolean result; > if (other == null) > result = false; > if (getType().equals(MEDIA_TYPE_WILDCARD) || > other.getType().equals(MEDIA_TYPE_WILDCARD)) > result = true; > else if (getType().equalsIgnoreCase(other.getType()) && > (getSubtype().equals(MEDIA_TYPE_WILDCARD) || > other.getSubtype().equals(MEDIA_TYPE_WILDCARD))) > result = true; > else > { > if (getType().equalsIgnoreCase(other.getType()) > && > this.getSubtype().equalsIgnoreCase(other.getSubtype())) > { > if (getParameters() == null || getParameters().size() == 0) > { > result = true; > } > else > { > result = this.equals(other); > } > } > else > { > result = false; > } > } > return result; > } > > in org.jboss.resteasy.util.WeightedMediaType in the resteasy-jaxrs module. > > Very interesting. Honestly, I'm not sure how to think about this. The > JAX-RS 1.1 spec says "An implementation MUST NOT invoke a method whose > effective value of @Produces does not match the request Accept > header.", but I don't see where it ever actually defines "match". And > Resteasy passes the TCK tests. Really, I'm not even sure what "match" > SHOULD mean. We could get crazy and do full blown unification > (http://en.wikipedia.org/wiki/Unification_%28computer_science%29). Ugh. > > Resource matching is a very fundamental notion in JAX-RS, and I > wouldn't want to make any changes without being very careful. > > Any thoughts about how to interpret "match"? > > -Ron > > >> public boolean isCompatible(MediaType other) >> { >> boolean result; >> if (other == null) >> result = false; >> if (getType().equals(MEDIA_TYPE_WILDCARD) || >> other.getType().equals(MEDIA_TYPE_WILDCARD)) >> result = true; >> else if (getType().equalsIgnoreCase(other.getType()) && >> (getSubtype().equals(MEDIA_TYPE_WILDCARD) || >> other.getSubtype().equals(MEDIA_TYPE_WILDCARD))) >> result = true; >> else >> { >> if (getType().equalsIgnoreCase(other.getType()) >> && >> this.getSubtype().equalsIgnoreCase(other.getSubtype())) >> { >> if (getParameters() == null || getParameters().size() == 0) >> { >> result = true; >> } >> else >> { >> result = this.equals(other); >> } >> } >> else >> { >> result = false; >> } >> } >> return result; >> } > > On 05/12/2015 03:55 PM, Ramesh Reddy wrote: >> We are using under EAP 6.3 (2.3.8) and EAP 6.4 (2.3.9 or 2.3.10) >> >> ------------------------------------------------------------------------ >> >> Meant to reply to list. >> >> Anyway, it looks like Resteasy 2.3.10.Final, more or less. >> >> -Ron >> >> >> -------- Forwarded Message -------- >> Subject: Re: [Resteasy-users] Question about Accepts Header >> Date: Mon, 11 May 2015 21:19:24 -0400 >> From: Ron Sigal <rs...@re...> >> To: Ramesh Reddy <ra...@re...> >> >> >> >> Hi Ramesh, >> >> Which version of Resteasy are you using in Teiid? >> >> Thanks, >> Ron >> >> On 05/11/2015 05:05 PM, Ramesh Reddy wrote: >> > Hi, >> > >> > In Teiid we have used RestEasy to implement the OData layer. We are seeing an issue with "Accepts" header. It is described herehttps://issues.jboss.org/browse/TEIID-3471 see 2nd comment. Any pointers to resolve are appreciated. >> > >> > Thanks >> > >> > Ramesh.. >> > >> > ------------------------------------------------------------------------------ >> > One dashboard for servers and applications across Physical-Virtual-Cloud >> > Widest out-of-the-box monitoring support with 50+ applications >> > Performance metrics, stats and reports that give you Actionable Insights >> > Deep dive visibility with transaction tracing using APM Insight. >> >http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> > _______________________________________________ >> > Resteasy-users mailing list >> >Res...@li... >> >https://lists.sourceforge.net/lists/listinfo/resteasy-users >> >> >> >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across >> Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable >> Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> Resteasy-users mailing list >> Res...@li... >> https://lists.sourceforge.net/lists/listinfo/resteasy-users >> >> > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > _______________________________________________ > Resteasy-users mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-users |
|
From: Savvas A. M. <sav...@gm...> - 2015-06-08 23:05:14
|
Hi Rodrigo,
Well, I'm thinking that if your requirements are such that your application
cannot tolerate an eventual consistency of such a level then probably a
more "traditional" XA type of solution would be more appropriate for your
circumstances.
HTH,
Savvas
On 8 June 2015 at 19:02, Rodrigo Uchôa <rod...@gm...> wrote:
> Guys,
>
> Once again, thank you both for your help.
>
> Savvas, that's really an option we're considering. But like Michael said,
> it would be just a workaround, not really an "atomic transaction". But it
> is indeed one option. I'm still trying to weight which of the two pays off.
>
> Regards,
> Rodrigo.
>
> On Mon, Jun 8, 2015 at 8:28 AM, Michael Musgrove <mmu...@re...>
> wrote:
>
>> I am not sure this will always be the best solution if the inserts at
>> the two servers need to be treated as a single business operation.
>>
>> The solution you propose means that the inserts do not happen atomically
>> and therfore you will put Consistency and Isolation at risk - ie other
>> applications will see some of the inserts before both transactions have
>> committed.
>>
>> Mike
>>
>> Hi Rodrigo,
>>
>> Does this really have to be in the classical sense of a "distributed
>> transaction"? Can you not have App B embed a "undo" hypermedia link in its
>> response?
>>
>> Given the following steps:
>>
>> 1) App A starts transaction and inserts some rows
>> 2) App A makes REST call to app B
>> 3) App B inserts rows in a separate transaction and returns a 200
>> response including a "undo" hypermedia link
>> 5) App A commits own transaction
>>
>> If steps 1 or 2 fail App A rollsback transaction so no problem there.
>> If step 3 fails then a 500 response (or even a 4** one in case of
>> validation errors) will be returned in which case App A can again rollback
>> its transaction
>> If step 5 fails then App A makes a POST request to the "undo" URL
>>
>> Savvas
>>
>> On 2 June 2015 at 18:03, Michael Musgrove <mmu...@re...> wrote:
>>
>>> REST-AT and JTA are different transaction models. Unfortunately we
>>> only provide an "inbound bridge" to go from REST-AT to JTA but I think you
>>> need the other direction ie JTA to REST-AT.
>>>
>>> There may be a workaround for you though which I would need to
>>> experiment with. You would need to start a REST-AT transaction and emulate
>>> what we do with the "inbound bridge" by manually starting a bridge.
>>> Something similar to:
>>>
>>> 1) EJB in web app A will start a REST-AT transaction
>>> 2) EJB in web app A will start an InboundBridge (instead of the JTA
>>> transaction):
>>> InboundBridge inboundBridge =
>>> InboundBridgeManager.getInstance().createInboundBridge("enlistmentUrl from
>>> step 1");
>>> inboundBridge.start();
>>> 3) EJB in web app A will perform JTA work (insert some records in a
>>> database)
>>> 4) invoke REST endpoint in app B passing the enlistmentUrl in a Link
>>> header
>>> 5) Mark up the REST endpoint in app B (using the
>>> javax.transaction.Transactional annotation) - this will automatically start
>>> an instance of the inbound bridge
>>> 6) commit the REST-AT transaction started in step 1. This will cause the
>>> work done in B and in A to commit within the context of the single REST-AT
>>> transaction.
>>>
>>> The only other ways to we have for distributed transactions are:
>>>
>>> - "distributed remoting protocol" for JTA (think EJBs)
>>> - and of course we JTS too;
>>> - web services transactions (XTS, WS-AT)
>>> - BlackTie for C based clients
>>>
>>> Mike
>>>
>>> Mike,
>>>
>>> I have been reading the docs and taking a look at the code samples.
>>> I'm still unsure however if the protocol/api covers the scenario I'm in:
>>>
>>> I have a client web app (A), and a REST endpoint (B). Two separate
>>> applications. Client in web app A is not a REST endpoint itself, just a
>>> regular stateless EJB.
>>>
>>> So in my scenario the stateless EJB in web app A will start a
>>> transaction, insert some records in a database and invoke REST endpoint in
>>> app B, which in turn will also run a transaction to insert records in a
>>> database. We need to make sure these two transactions are atomic. That
>>> meaning, the two transactions should be only one.
>>>
>>> To me it seems that the protocol only covers scenarios where both
>>> participants in the transaction are REST resources, which in my case is not
>>> true. The client needs to participate in the transaction and it's just a
>>> regular EJB.
>>>
>>> Is this really the case?
>>>
>>> Regards!
>>>
>>> On Tue, May 26, 2015 at 1:43 PM, Rodrigo Uchôa <rod...@gm...>
>>> wrote:
>>>
>>>> Thanks a lot, Mike! Exactly what I needed.
>>>>
>>>> On Tue, May 26, 2015 at 6:06 AM, Michael Musgrove <mmu...@re...>
>>>> wrote:
>>>>
>>>>> The narayana transaction manager has a rest service that creates
>>>>> [transaction] Coordinator resources. These resources map onto conventional
>>>>> ACID transactions. It is up to your service to decide what to do when the
>>>>> "transaction" is completing. However, we also have a "JTA Bridge" that will
>>>>> detect when your JAX-RS service performs JTA work (JMS, JPA etc) and
>>>>> automatically enlist those XA participants with the currently active
>>>>> coordinator.
>>>>>
>>>>> Our on-line docs [1] contains descriptions of the [REST-AT] protocol
>>>>> and our implementation of it including a small section on the bridge [2].
>>>>> We have a number of quickstarts [3] that show it action including a
>>>>> quickstart that demonstrates how to enable and use the JTA (inbound) bridge
>>>>> [4].
>>>>>
>>>>> We also provide an integration API [5] that abstracts the mechanics of
>>>>> participating in REST-AT transactions - there is a high level description
>>>>> of it on our team blog [6].
>>>>>
>>>>>
>>>>> [1] http://narayana.io/documentation/
>>>>> [REST-AT]
>>>>> http://narayana.io/docs/specs/restat-v2-draft-8-2013-jul-29.pdf
>>>>> [2]
>>>>> http://narayana.io/docs/project/index.html#_interoperating_with_other_transaction_models
>>>>> [3] https://github.com/jbosstm/quickstart/tree/master/rts
>>>>> [4]
>>>>> https://github.com/jbosstm/quickstart/tree/master/rts/at/jta-service
>>>>> [5]
>>>>> http://narayana.io/docs/project/index.html#_support_for_java_based_services
>>>>> [6]
>>>>> http://jbossts.blogspot.co.uk/2013/07/out-of-box-support-for-restful.html
>>>>>
>>>>>
>>>>> I have an web application "A" that occasionally have to
>>>>> insert/update records that belong to another application, "B". To manage
>>>>> this requirement, application "B" expose some REST endpoints that
>>>>> application "A" will call whenever it needs.
>>>>>
>>>>> Problem is, we need to make sure that the inserts/updates occurring
>>>>> in both applications are atomic.
>>>>>
>>>>> Does anyone have done something similar and can point a solution? I
>>>>> know that there's a debate whether transactions in REST are conceptually
>>>>> wrong, but we're willing to break the rules in this case.
>>>>>
>>>>>
>>>>> OK let's not go there then (but when you say "we're willing to break
>>>>> the rules" you are already tacitly stating on which side of the argument
>>>>> you stand).
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>> Regards!
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> One dashboard for servers and applications across Physical-Virtual-Cloud
>>>>> Widest out-of-the-box monitoring support with 50+ applications
>>>>> Performance metrics, stats and reports that give you Actionable Insights
>>>>> Deep dive visibility with transaction tracing using APM Insight.http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Resteasy-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael Musgrove
>>>>> Red Hat UK Ltd, Transactions Team
>>>>> e: mmu...@re...
>>>>> t: +44 191 243 0870
>>>>>
>>>>> Registered in England and Wales under Company Registration No. 03798903
>>>>> Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Michael Musgrove
>>> Red Hat UK Ltd, Transactions Team
>>> e: mmu...@re...
>>> t: +44 191 243 0870
>>>
>>> Registered in England and Wales under Company Registration No. 03798903
>>> Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Resteasy-users mailing list
>>> Res...@li...
>>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>>
>>>
>>
>>
>> --
>> Michael Musgrove
>> Red Hat UK Ltd, Transactions Team
>> e: mmu...@re...
>> t: +44 191 243 0870
>>
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
>>
>>
>
|
|
From: Rodrigo U. <rod...@gm...> - 2015-06-08 18:02:48
|
Guys,
Once again, thank you both for your help.
Savvas, that's really an option we're considering. But like Michael said,
it would be just a workaround, not really an "atomic transaction". But it
is indeed one option. I'm still trying to weight which of the two pays off.
Regards,
Rodrigo.
On Mon, Jun 8, 2015 at 8:28 AM, Michael Musgrove <mmu...@re...>
wrote:
> I am not sure this will always be the best solution if the inserts at
> the two servers need to be treated as a single business operation.
>
> The solution you propose means that the inserts do not happen atomically
> and therfore you will put Consistency and Isolation at risk - ie other
> applications will see some of the inserts before both transactions have
> committed.
>
> Mike
>
> Hi Rodrigo,
>
> Does this really have to be in the classical sense of a "distributed
> transaction"? Can you not have App B embed a "undo" hypermedia link in its
> response?
>
> Given the following steps:
>
> 1) App A starts transaction and inserts some rows
> 2) App A makes REST call to app B
> 3) App B inserts rows in a separate transaction and returns a 200 response
> including a "undo" hypermedia link
> 5) App A commits own transaction
>
> If steps 1 or 2 fail App A rollsback transaction so no problem there.
> If step 3 fails then a 500 response (or even a 4** one in case of
> validation errors) will be returned in which case App A can again rollback
> its transaction
> If step 5 fails then App A makes a POST request to the "undo" URL
>
> Savvas
>
> On 2 June 2015 at 18:03, Michael Musgrove <mmu...@re...> wrote:
>
>> REST-AT and JTA are different transaction models. Unfortunately we only
>> provide an "inbound bridge" to go from REST-AT to JTA but I think you need
>> the other direction ie JTA to REST-AT.
>>
>> There may be a workaround for you though which I would need to experiment
>> with. You would need to start a REST-AT transaction and emulate what we do
>> with the "inbound bridge" by manually starting a bridge. Something similar
>> to:
>>
>> 1) EJB in web app A will start a REST-AT transaction
>> 2) EJB in web app A will start an InboundBridge (instead of the JTA
>> transaction):
>> InboundBridge inboundBridge =
>> InboundBridgeManager.getInstance().createInboundBridge("enlistmentUrl from
>> step 1");
>> inboundBridge.start();
>> 3) EJB in web app A will perform JTA work (insert some records in a
>> database)
>> 4) invoke REST endpoint in app B passing the enlistmentUrl in a Link
>> header
>> 5) Mark up the REST endpoint in app B (using the
>> javax.transaction.Transactional annotation) - this will automatically start
>> an instance of the inbound bridge
>> 6) commit the REST-AT transaction started in step 1. This will cause the
>> work done in B and in A to commit within the context of the single REST-AT
>> transaction.
>>
>> The only other ways to we have for distributed transactions are:
>>
>> - "distributed remoting protocol" for JTA (think EJBs)
>> - and of course we JTS too;
>> - web services transactions (XTS, WS-AT)
>> - BlackTie for C based clients
>>
>> Mike
>>
>> Mike,
>>
>> I have been reading the docs and taking a look at the code samples. I'm
>> still unsure however if the protocol/api covers the scenario I'm in:
>>
>> I have a client web app (A), and a REST endpoint (B). Two separate
>> applications. Client in web app A is not a REST endpoint itself, just a
>> regular stateless EJB.
>>
>> So in my scenario the stateless EJB in web app A will start a
>> transaction, insert some records in a database and invoke REST endpoint in
>> app B, which in turn will also run a transaction to insert records in a
>> database. We need to make sure these two transactions are atomic. That
>> meaning, the two transactions should be only one.
>>
>> To me it seems that the protocol only covers scenarios where both
>> participants in the transaction are REST resources, which in my case is not
>> true. The client needs to participate in the transaction and it's just a
>> regular EJB.
>>
>> Is this really the case?
>>
>> Regards!
>>
>> On Tue, May 26, 2015 at 1:43 PM, Rodrigo Uchôa <rod...@gm...>
>> wrote:
>>
>>> Thanks a lot, Mike! Exactly what I needed.
>>>
>>> On Tue, May 26, 2015 at 6:06 AM, Michael Musgrove <mmu...@re...>
>>> wrote:
>>>
>>>> The narayana transaction manager has a rest service that creates
>>>> [transaction] Coordinator resources. These resources map onto conventional
>>>> ACID transactions. It is up to your service to decide what to do when the
>>>> "transaction" is completing. However, we also have a "JTA Bridge" that will
>>>> detect when your JAX-RS service performs JTA work (JMS, JPA etc) and
>>>> automatically enlist those XA participants with the currently active
>>>> coordinator.
>>>>
>>>> Our on-line docs [1] contains descriptions of the [REST-AT] protocol
>>>> and our implementation of it including a small section on the bridge [2].
>>>> We have a number of quickstarts [3] that show it action including a
>>>> quickstart that demonstrates how to enable and use the JTA (inbound) bridge
>>>> [4].
>>>>
>>>> We also provide an integration API [5] that abstracts the mechanics of
>>>> participating in REST-AT transactions - there is a high level description
>>>> of it on our team blog [6].
>>>>
>>>>
>>>> [1] http://narayana.io/documentation/
>>>> [REST-AT]
>>>> http://narayana.io/docs/specs/restat-v2-draft-8-2013-jul-29.pdf
>>>> [2]
>>>> http://narayana.io/docs/project/index.html#_interoperating_with_other_transaction_models
>>>> [3] https://github.com/jbosstm/quickstart/tree/master/rts
>>>> [4]
>>>> https://github.com/jbosstm/quickstart/tree/master/rts/at/jta-service
>>>> [5]
>>>> http://narayana.io/docs/project/index.html#_support_for_java_based_services
>>>> [6]
>>>> http://jbossts.blogspot.co.uk/2013/07/out-of-box-support-for-restful.html
>>>>
>>>>
>>>> I have an web application "A" that occasionally have to
>>>> insert/update records that belong to another application, "B". To manage
>>>> this requirement, application "B" expose some REST endpoints that
>>>> application "A" will call whenever it needs.
>>>>
>>>> Problem is, we need to make sure that the inserts/updates occurring
>>>> in both applications are atomic.
>>>>
>>>> Does anyone have done something similar and can point a solution? I
>>>> know that there's a debate whether transactions in REST are conceptually
>>>> wrong, but we're willing to break the rules in this case.
>>>>
>>>>
>>>> OK let's not go there then (but when you say "we're willing to break
>>>> the rules" you are already tacitly stating on which side of the argument
>>>> you stand).
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>> Regards!
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> One dashboard for servers and applications across Physical-Virtual-Cloud
>>>> Widest out-of-the-box monitoring support with 50+ applications
>>>> Performance metrics, stats and reports that give you Actionable Insights
>>>> Deep dive visibility with transaction tracing using APM Insight.http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Resteasy-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Musgrove
>>>> Red Hat UK Ltd, Transactions Team
>>>> e: mmu...@re...
>>>> t: +44 191 243 0870
>>>>
>>>> Registered in England and Wales under Company Registration No. 03798903
>>>> Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
>>>>
>>>>
>>>
>>
>>
>> --
>> Michael Musgrove
>> Red Hat UK Ltd, Transactions Team
>> e: mmu...@re...
>> t: +44 191 243 0870
>>
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Resteasy-users mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>
>>
>
>
> --
> Michael Musgrove
> Red Hat UK Ltd, Transactions Team
> e: mmu...@re...
> t: +44 191 243 0870
>
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
>
>
|
|
From: Michael M. <mmu...@re...> - 2015-06-08 11:29:03
|
I am not sure this will always be the best solution if the inserts at
the two servers need to be treated as a single business operation.
The solution you propose means that the inserts do not happen atomically
and therfore you will put Consistency and Isolation at risk - ie other
applications will see some of the inserts before both transactions have
committed.
Mike
> Hi Rodrigo,
>
> Does this really have to be in the classical sense of a "distributed
> transaction"? Can you not have App B embed a "undo" hypermedia link in
> its response?
>
> Given the following steps:
>
> 1) App A starts transaction and inserts some rows
> 2) App A makes REST call to app B
> 3) App B inserts rows in a separate transaction and returns a 200
> response including a "undo" hypermedia link
> 5) App A commits own transaction
>
> If steps 1 or 2 fail App A rollsback transaction so no problem there.
> If step 3 fails then a 500 response (or even a 4** one in case of
> validation errors) will be returned in which case App A can again
> rollback its transaction
> If step 5 fails then App A makes a POST request to the "undo" URL
>
> Savvas
>
> On 2 June 2015 at 18:03, Michael Musgrove <mmu...@re...
> <mailto:mmu...@re...>> wrote:
>
> REST-AT and JTA are different transaction models. Unfortunately we
> only provide an "inbound bridge" to go from REST-AT to JTA but I
> think you need the other direction ie JTA to REST-AT.
>
> There may be a workaround for you though which I would need to
> experiment with. You would need to start a REST-AT transaction and
> emulate what we do with the "inbound bridge" by manually starting
> a bridge. Something similar to:
>
> 1) EJB in web app A will start a REST-AT transaction
> 2) EJB in web app A will start an InboundBridge (instead of the
> JTA transaction):
> InboundBridge inboundBridge =
> InboundBridgeManager.getInstance().createInboundBridge("enlistmentUrl
> from step 1");
> inboundBridge.start();
> 3) EJB in web app A will perform JTA work (insert some records in
> a database)
> 4) invoke REST endpoint in app B passing the enlistmentUrl in a
> Link header
> 5) Mark up the REST endpoint in app B (using the
> javax.transaction.Transactional annotation) - this will
> automatically start an instance of the inbound bridge
> 6) commit the REST-AT transaction started in step 1. This will
> cause the work done in B and in A to commit within the context of
> the single REST-AT transaction.
>
> The only other ways to we have for distributed transactions are:
>
> - "distributed remoting protocol" for JTA (think EJBs)
> - and of course we JTS too;
> - web services transactions (XTS, WS-AT)
> - BlackTie for C based clients
>
> Mike
>
>> Mike,
>>
>> I have been reading the docs and taking a look at the code
>> samples. I'm still unsure however if the protocol/api covers the
>> scenario I'm in:
>>
>> I have a client web app (A), and a REST endpoint (B). Two
>> separate applications. Client in web app A is not a REST endpoint
>> itself, just a regular stateless EJB.
>>
>> So in my scenario the stateless EJB in web app A will start a
>> transaction, insert some records in a database and invoke REST
>> endpoint in app B, which in turn will also run a transaction to
>> insert records in a database. We need to make sure these two
>> transactions are atomic. That meaning, the two transactions
>> should be only one.
>>
>> To me it seems that the protocol only covers scenarios where both
>> participants in the transaction are REST resources, which in my
>> case is not true. The client needs to participate in the
>> transaction and it's just a regular EJB.
>>
>> Is this really the case?
>>
>> Regards!
>>
>> On Tue, May 26, 2015 at 1:43 PM, Rodrigo Uchôa
>> <rod...@gm... <mailto:rod...@gm...>> wrote:
>>
>> Thanks a lot, Mike! Exactly what I needed.
>>
>> On Tue, May 26, 2015 at 6:06 AM, Michael Musgrove
>> <mmu...@re... <mailto:mmu...@re...>> wrote:
>>
>> The narayana transaction manager has a rest service that
>> creates [transaction] Coordinator resources. These
>> resources map onto conventional ACID transactions. It is
>> up to your service to decide what to do when the
>> "transaction" is completing. However, we also have a "JTA
>> Bridge" that will detect when your JAX-RS service
>> performs JTA work (JMS, JPA etc) and automatically enlist
>> those XA participants with the currently active coordinator.
>>
>> Our on-line docs [1] contains descriptions of the
>> [REST-AT] protocol and our implementation of it including
>> a small section on the bridge [2]. We have a number of
>> quickstarts [3] that show it action including a
>> quickstart that demonstrates how to enable and use the
>> JTA (inbound) bridge [4].
>>
>> We also provide an integration API [5] that abstracts the
>> mechanics of participating in REST-AT transactions -
>> there is a high level description of it on our team blog [6].
>>
>>
>> [1] http://narayana.io/documentation/
>> [REST-AT]
>> http://narayana.io/docs/specs/restat-v2-draft-8-2013-jul-29.pdf
>> [2]
>> http://narayana.io/docs/project/index.html#_interoperating_with_other_transaction_models
>> [3] https://github.com/jbosstm/quickstart/tree/master/rts
>> [4]
>> https://github.com/jbosstm/quickstart/tree/master/rts/at/jta-service
>> [5]
>> http://narayana.io/docs/project/index.html#_support_for_java_based_services
>> [6]
>> http://jbossts.blogspot.co.uk/2013/07/out-of-box-support-for-restful.html
>>
>>
>>> I have an web application "A" that occasionally have to
>>> insert/update records that belong to another
>>> application, "B". To manage this requirement,
>>> application "B" expose some REST endpoints that
>>> application "A" will call whenever it needs.
>>>
>>> Problem is, we need to make sure that the
>>> inserts/updates occurring in both applications are atomic.
>>>
>>> Does anyone have done something similar and can point a
>>> solution? I know that there's a debate whether
>>> transactions in REST are conceptually wrong, but we're
>>> willing to break the rules in this case.
>>
>> OK let's not go there then (but when you say "we're
>> willing to break the rules" you are already tacitly
>> stating on which side of the argument you stand).
>>
>> Mike
>>
>>
>>>
>>> Regards!
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> One dashboard for servers and applications across Physical-Virtual-Cloud
>>> Widest out-of-the-box monitoring support with 50+ applications
>>> Performance metrics, stats and reports that give you Actionable Insights
>>> Deep dive visibility with transaction tracing using APM Insight.
>>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>>
>>>
>>> _______________________________________________
>>> Resteasy-users mailing list
>>> Res...@li... <mailto:Res...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>
>>
>> --
>> Michael Musgrove
>> Red Hat UK Ltd, Transactions Team
>> e:mmu...@re... <mailto:mmu...@re...>
>> t:+44 191 243 0870 <tel:%2B44%20191%20243%200870>
>>
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
>>
>>
>>
>
>
> --
> Michael Musgrove
> Red Hat UK Ltd, Transactions Team
> e:mmu...@re... <mailto:mmu...@re...>
> t:+44 191 243 0870 <tel:%2B44%20191%20243%200870>
>
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> <mailto:Res...@li...>
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
--
Michael Musgrove
Red Hat UK Ltd, Transactions Team
e: mmu...@re...
t: +44 191 243 0870
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
|
|
From: Savvas A. M. <sav...@gm...> - 2015-06-06 17:13:21
|
Hi Rodrigo,
Does this really have to be in the classical sense of a "distributed
transaction"? Can you not have App B embed a "undo" hypermedia link in its
response?
Given the following steps:
1) App A starts transaction and inserts some rows
2) App A makes REST call to app B
3) App B inserts rows in a separate transaction and returns a 200 response
including a "undo" hypermedia link
5) App A commits own transaction
If steps 1 or 2 fail App A rollsback transaction so no problem there.
If step 3 fails then a 500 response (or even a 4** one in case of
validation errors) will be returned in which case App A can again rollback
its transaction
If step 5 fails then App A makes a POST request to the "undo" URL
Savvas
On 2 June 2015 at 18:03, Michael Musgrove <mmu...@re...> wrote:
> REST-AT and JTA are different transaction models. Unfortunately we only
> provide an "inbound bridge" to go from REST-AT to JTA but I think you need
> the other direction ie JTA to REST-AT.
>
> There may be a workaround for you though which I would need to experiment
> with. You would need to start a REST-AT transaction and emulate what we do
> with the "inbound bridge" by manually starting a bridge. Something similar
> to:
>
> 1) EJB in web app A will start a REST-AT transaction
> 2) EJB in web app A will start an InboundBridge (instead of the JTA
> transaction):
> InboundBridge inboundBridge =
> InboundBridgeManager.getInstance().createInboundBridge("enlistmentUrl from
> step 1");
> inboundBridge.start();
> 3) EJB in web app A will perform JTA work (insert some records in a
> database)
> 4) invoke REST endpoint in app B passing the enlistmentUrl in a Link header
> 5) Mark up the REST endpoint in app B (using the
> javax.transaction.Transactional annotation) - this will automatically start
> an instance of the inbound bridge
> 6) commit the REST-AT transaction started in step 1. This will cause the
> work done in B and in A to commit within the context of the single REST-AT
> transaction.
>
> The only other ways to we have for distributed transactions are:
>
> - "distributed remoting protocol" for JTA (think EJBs)
> - and of course we JTS too;
> - web services transactions (XTS, WS-AT)
> - BlackTie for C based clients
>
> Mike
>
> Mike,
>
> I have been reading the docs and taking a look at the code samples. I'm
> still unsure however if the protocol/api covers the scenario I'm in:
>
> I have a client web app (A), and a REST endpoint (B). Two separate
> applications. Client in web app A is not a REST endpoint itself, just a
> regular stateless EJB.
>
> So in my scenario the stateless EJB in web app A will start a
> transaction, insert some records in a database and invoke REST endpoint in
> app B, which in turn will also run a transaction to insert records in a
> database. We need to make sure these two transactions are atomic. That
> meaning, the two transactions should be only one.
>
> To me it seems that the protocol only covers scenarios where both
> participants in the transaction are REST resources, which in my case is not
> true. The client needs to participate in the transaction and it's just a
> regular EJB.
>
> Is this really the case?
>
> Regards!
>
> On Tue, May 26, 2015 at 1:43 PM, Rodrigo Uchôa <rod...@gm...>
> wrote:
>
>> Thanks a lot, Mike! Exactly what I needed.
>>
>> On Tue, May 26, 2015 at 6:06 AM, Michael Musgrove <mmu...@re...>
>> wrote:
>>
>>> The narayana transaction manager has a rest service that creates
>>> [transaction] Coordinator resources. These resources map onto conventional
>>> ACID transactions. It is up to your service to decide what to do when the
>>> "transaction" is completing. However, we also have a "JTA Bridge" that will
>>> detect when your JAX-RS service performs JTA work (JMS, JPA etc) and
>>> automatically enlist those XA participants with the currently active
>>> coordinator.
>>>
>>> Our on-line docs [1] contains descriptions of the [REST-AT] protocol and
>>> our implementation of it including a small section on the bridge [2]. We
>>> have a number of quickstarts [3] that show it action including a quickstart
>>> that demonstrates how to enable and use the JTA (inbound) bridge [4].
>>>
>>> We also provide an integration API [5] that abstracts the mechanics of
>>> participating in REST-AT transactions - there is a high level description
>>> of it on our team blog [6].
>>>
>>>
>>> [1] http://narayana.io/documentation/
>>> [REST-AT]
>>> http://narayana.io/docs/specs/restat-v2-draft-8-2013-jul-29.pdf
>>> [2]
>>> http://narayana.io/docs/project/index.html#_interoperating_with_other_transaction_models
>>> [3] https://github.com/jbosstm/quickstart/tree/master/rts
>>> [4] https://github.com/jbosstm/quickstart/tree/master/rts/at/jta-service
>>> [5]
>>> http://narayana.io/docs/project/index.html#_support_for_java_based_services
>>> [6]
>>> http://jbossts.blogspot.co.uk/2013/07/out-of-box-support-for-restful.html
>>>
>>>
>>> I have an web application "A" that occasionally have to insert/update
>>> records that belong to another application, "B". To manage this
>>> requirement, application "B" expose some REST endpoints that application
>>> "A" will call whenever it needs.
>>>
>>> Problem is, we need to make sure that the inserts/updates occurring in
>>> both applications are atomic.
>>>
>>> Does anyone have done something similar and can point a solution? I
>>> know that there's a debate whether transactions in REST are conceptually
>>> wrong, but we're willing to break the rules in this case.
>>>
>>>
>>> OK let's not go there then (but when you say "we're willing to break
>>> the rules" you are already tacitly stating on which side of the argument
>>> you stand).
>>>
>>> Mike
>>>
>>>
>>>
>>> Regards!
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> One dashboard for servers and applications across Physical-Virtual-Cloud
>>> Widest out-of-the-box monitoring support with 50+ applications
>>> Performance metrics, stats and reports that give you Actionable Insights
>>> Deep dive visibility with transaction tracing using APM Insight.http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>>
>>>
>>>
>>> _______________________________________________
>>> Resteasy-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>>
>>>
>>>
>>> --
>>> Michael Musgrove
>>> Red Hat UK Ltd, Transactions Team
>>> e: mmu...@re...
>>> t: +44 191 243 0870
>>>
>>> Registered in England and Wales under Company Registration No. 03798903
>>> Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
>>>
>>>
>>
>
>
> --
> Michael Musgrove
> Red Hat UK Ltd, Transactions Team
> e: mmu...@re...
> t: +44 191 243 0870
>
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
|
|
From: Joice J. <joi...@gm...> - 2015-06-05 10:31:13
|
Hi, I am trying to compile the Export Control Classification Number (ECCN) for the third-party software being used with one of our products. This is to facilitate the export of the product outside US. Could you help us in identifying whether the followingsoftware currently has an ECCN number and the country of origin for the code. Also could you help in identifying whether it contains any encryption module that causes it to use an ECCN number for export. Resteasy Atom Provider RESTEasy CDI integration module Resteasy Guice Resteasy Hibernate Validator Provider Resteasy Jackson Provider Resteasy Jackson Provider RESTEasy JAX-RS RESTEasy JAX-RS Client/Server Testsuite RESTEasy JAX-RS JSAPI Resteasy JAXB Provider Resteasy JBoss Modules Resteasy Jettison Provider Resteasy Multipart Provider Resteasy Skeleton Key AS7 Modules RESTEasy Skeleton Key Core Resteasy YAML Provider Any help with this would be great. If this is not the right contact, please forward this mail to the correct person. Thanks and Regards, Joice Joy Company - Comverse |
|
From: Matteo C. <cus...@gm...> - 2015-06-04 06:08:26
|
Hi all, I am going to develop a system with a list of rest services, based on resteasy, and 2 front end, the first is an angularjs application and the second is a mobile app. I need to use openam as idp and saml2 as security protocol. Is it possible to secure the rest services with these technologies? There is some documentation or examples? Thanks in advance. Matteo. |
|
From: Michael M. <mmu...@re...> - 2015-06-02 17:03:20
|
REST-AT and JTA are different transaction models. Unfortunately we only
provide an "inbound bridge" to go from REST-AT to JTA but I think you
need the other direction ie JTA to REST-AT.
There may be a workaround for you though which I would need to
experiment with. You would need to start a REST-AT transaction and
emulate what we do with the "inbound bridge" by manually starting a
bridge. Something similar to:
1) EJB in web app A will start a REST-AT transaction
2) EJB in web app A will start an InboundBridge (instead of the JTA
transaction):
InboundBridge inboundBridge =
InboundBridgeManager.getInstance().createInboundBridge("enlistmentUrl
from step 1");
inboundBridge.start();
3) EJB in web app A will perform JTA work (insert some records in a
database)
4) invoke REST endpoint in app B passing the enlistmentUrl in a Link header
5) Mark up the REST endpoint in app B (using the
javax.transaction.Transactional annotation) - this will automatically
start an instance of the inbound bridge
6) commit the REST-AT transaction started in step 1. This will cause the
work done in B and in A to commit within the context of the single
REST-AT transaction.
The only other ways to we have for distributed transactions are:
- "distributed remoting protocol" for JTA (think EJBs)
- and of course we JTS too;
- web services transactions (XTS, WS-AT)
- BlackTie for C based clients
Mike
> Mike,
>
> I have been reading the docs and taking a look at the code samples.
> I'm still unsure however if the protocol/api covers the scenario I'm in:
>
> I have a client web app (A), and a REST endpoint (B). Two separate
> applications. Client in web app A is not a REST endpoint itself, just
> a regular stateless EJB.
>
> So in my scenario the stateless EJB in web app A will start a
> transaction, insert some records in a database and invoke REST
> endpoint in app B, which in turn will also run a transaction to insert
> records in a database. We need to make sure these two transactions are
> atomic. That meaning, the two transactions should be only one.
>
> To me it seems that the protocol only covers scenarios where both
> participants in the transaction are REST resources, which in my case
> is not true. The client needs to participate in the transaction and
> it's just a regular EJB.
>
> Is this really the case?
>
> Regards!
>
> On Tue, May 26, 2015 at 1:43 PM, Rodrigo Uchôa
> <rod...@gm... <mailto:rod...@gm...>> wrote:
>
> Thanks a lot, Mike! Exactly what I needed.
>
> On Tue, May 26, 2015 at 6:06 AM, Michael Musgrove
> <mmu...@re... <mailto:mmu...@re...>> wrote:
>
> The narayana transaction manager has a rest service that
> creates [transaction] Coordinator resources. These resources
> map onto conventional ACID transactions. It is up to your
> service to decide what to do when the "transaction" is
> completing. However, we also have a "JTA Bridge" that will
> detect when your JAX-RS service performs JTA work (JMS, JPA
> etc) and automatically enlist those XA participants with the
> currently active coordinator.
>
> Our on-line docs [1] contains descriptions of the [REST-AT]
> protocol and our implementation of it including a small
> section on the bridge [2]. We have a number of quickstarts [3]
> that show it action including a quickstart that demonstrates
> how to enable and use the JTA (inbound) bridge [4].
>
> We also provide an integration API [5] that abstracts the
> mechanics of participating in REST-AT transactions - there is
> a high level description of it on our team blog [6].
>
>
> [1] http://narayana.io/documentation/
> [REST-AT]
> http://narayana.io/docs/specs/restat-v2-draft-8-2013-jul-29.pdf
> [2]
> http://narayana.io/docs/project/index.html#_interoperating_with_other_transaction_models
> [3] https://github.com/jbosstm/quickstart/tree/master/rts
> [4]
> https://github.com/jbosstm/quickstart/tree/master/rts/at/jta-service
> [5]
> http://narayana.io/docs/project/index.html#_support_for_java_based_services
> [6]
> http://jbossts.blogspot.co.uk/2013/07/out-of-box-support-for-restful.html
>
>
>> I have an web application "A" that occasionally have to
>> insert/update records that belong to another application,
>> "B". To manage this requirement, application "B" expose some
>> REST endpoints that application "A" will call whenever it needs.
>>
>> Problem is, we need to make sure that the inserts/updates
>> occurring in both applications are atomic.
>>
>> Does anyone have done something similar and can point a
>> solution? I know that there's a debate whether transactions
>> in REST are conceptually wrong, but we're willing to break
>> the rules in this case.
>
> OK let's not go there then (but when you say "we're willing to
> break the rules" you are already tacitly stating on which side
> of the argument you stand).
>
> Mike
>
>
>>
>> Regards!
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>
>>
>> _______________________________________________
>> Resteasy-users mailing list
>> Res...@li... <mailto:Res...@li...>
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
> --
> Michael Musgrove
> Red Hat UK Ltd, Transactions Team
> e:mmu...@re... <mailto:mmu...@re...>
> t:+44 191 243 0870 <tel:%2B44%20191%20243%200870>
>
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
>
>
>
--
Michael Musgrove
Red Hat UK Ltd, Transactions Team
e: mmu...@re...
t: +44 191 243 0870
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
|
|
From: Rodrigo U. <rod...@gm...> - 2015-06-02 15:51:58
|
Mike, I have been reading the docs and taking a look at the code samples. I'm still unsure however if the protocol/api covers the scenario I'm in: I have a client web app (A), and a REST endpoint (B). Two separate applications. Client in web app A is not a REST endpoint itself, just a regular stateless EJB. So in my scenario the stateless EJB in web app A will start a transaction, insert some records in a database and invoke REST endpoint in app B, which in turn will also run a transaction to insert records in a database. We need to make sure these two transactions are atomic. That meaning, the two transactions should be only one. To me it seems that the protocol only covers scenarios where both participants in the transaction are REST resources, which in my case is not true. The client needs to participate in the transaction and it's just a regular EJB. Is this really the case? Regards! On Tue, May 26, 2015 at 1:43 PM, Rodrigo Uchôa <rod...@gm...> wrote: > Thanks a lot, Mike! Exactly what I needed. > > On Tue, May 26, 2015 at 6:06 AM, Michael Musgrove <mmu...@re...> > wrote: > >> The narayana transaction manager has a rest service that creates >> [transaction] Coordinator resources. These resources map onto conventional >> ACID transactions. It is up to your service to decide what to do when the >> "transaction" is completing. However, we also have a "JTA Bridge" that will >> detect when your JAX-RS service performs JTA work (JMS, JPA etc) and >> automatically enlist those XA participants with the currently active >> coordinator. >> >> Our on-line docs [1] contains descriptions of the [REST-AT] protocol and >> our implementation of it including a small section on the bridge [2]. We >> have a number of quickstarts [3] that show it action including a quickstart >> that demonstrates how to enable and use the JTA (inbound) bridge [4]. >> >> We also provide an integration API [5] that abstracts the mechanics of >> participating in REST-AT transactions - there is a high level description >> of it on our team blog [6]. >> >> >> [1] http://narayana.io/documentation/ >> [REST-AT] http://narayana.io/docs/specs/restat-v2-draft-8-2013-jul-29.pdf >> [2] >> http://narayana.io/docs/project/index.html#_interoperating_with_other_transaction_models >> [3] https://github.com/jbosstm/quickstart/tree/master/rts >> [4] https://github.com/jbosstm/quickstart/tree/master/rts/at/jta-service >> [5] >> http://narayana.io/docs/project/index.html#_support_for_java_based_services >> [6] >> http://jbossts.blogspot.co.uk/2013/07/out-of-box-support-for-restful.html >> >> >> I have an web application "A" that occasionally have to insert/update >> records that belong to another application, "B". To manage this >> requirement, application "B" expose some REST endpoints that application >> "A" will call whenever it needs. >> >> Problem is, we need to make sure that the inserts/updates occurring in >> both applications are atomic. >> >> Does anyone have done something similar and can point a solution? I >> know that there's a debate whether transactions in REST are conceptually >> wrong, but we're willing to break the rules in this case. >> >> >> OK let's not go there then (but when you say "we're willing to break the >> rules" you are already tacitly stating on which side of the argument you >> stand). >> >> Mike >> >> >> >> Regards! >> >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight.http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> >> >> >> _______________________________________________ >> Resteasy-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/resteasy-users >> >> >> >> -- >> Michael Musgrove >> Red Hat UK Ltd, Transactions Team >> e: mmu...@re... >> t: +44 191 243 0870 >> >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) >> >> > |
|
From: Rodrigo U. <rod...@gm...> - 2015-05-26 16:43:30
|
Thanks a lot, Mike! Exactly what I needed. On Tue, May 26, 2015 at 6:06 AM, Michael Musgrove <mmu...@re...> wrote: > The narayana transaction manager has a rest service that creates > [transaction] Coordinator resources. These resources map onto conventional > ACID transactions. It is up to your service to decide what to do when the > "transaction" is completing. However, we also have a "JTA Bridge" that will > detect when your JAX-RS service performs JTA work (JMS, JPA etc) and > automatically enlist those XA participants with the currently active > coordinator. > > Our on-line docs [1] contains descriptions of the [REST-AT] protocol and > our implementation of it including a small section on the bridge [2]. We > have a number of quickstarts [3] that show it action including a quickstart > that demonstrates how to enable and use the JTA (inbound) bridge [4]. > > We also provide an integration API [5] that abstracts the mechanics of > participating in REST-AT transactions - there is a high level description > of it on our team blog [6]. > > > [1] http://narayana.io/documentation/ > [REST-AT] http://narayana.io/docs/specs/restat-v2-draft-8-2013-jul-29.pdf > [2] > http://narayana.io/docs/project/index.html#_interoperating_with_other_transaction_models > [3] https://github.com/jbosstm/quickstart/tree/master/rts > [4] https://github.com/jbosstm/quickstart/tree/master/rts/at/jta-service > [5] > http://narayana.io/docs/project/index.html#_support_for_java_based_services > [6] > http://jbossts.blogspot.co.uk/2013/07/out-of-box-support-for-restful.html > > > I have an web application "A" that occasionally have to insert/update > records that belong to another application, "B". To manage this > requirement, application "B" expose some REST endpoints that application > "A" will call whenever it needs. > > Problem is, we need to make sure that the inserts/updates occurring in > both applications are atomic. > > Does anyone have done something similar and can point a solution? I know > that there's a debate whether transactions in REST are conceptually wrong, > but we're willing to break the rules in this case. > > > OK let's not go there then (but when you say "we're willing to break the > rules" you are already tacitly stating on which side of the argument you > stand). > > Mike > > > > Regards! > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight.http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > > _______________________________________________ > Resteasy-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/resteasy-users > > > > -- > Michael Musgrove > Red Hat UK Ltd, Transactions Team > e: mmu...@re... > t: +44 191 243 0870 > > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) > > |
|
From: Michael M. <mmu...@re...> - 2015-05-26 09:06:52
|
The narayana transaction manager has a rest service that creates [transaction] Coordinator resources. These resources map onto conventional ACID transactions. It is up to your service to decide what to do when the "transaction" is completing. However, we also have a "JTA Bridge" that will detect when your JAX-RS service performs JTA work (JMS, JPA etc) and automatically enlist those XA participants with the currently active coordinator. Our on-line docs [1] contains descriptions of the [REST-AT] protocol and our implementation of it including a small section on the bridge [2]. We have a number of quickstarts [3] that show it action including a quickstart that demonstrates how to enable and use the JTA (inbound) bridge [4]. We also provide an integration API [5] that abstracts the mechanics of participating in REST-AT transactions - there is a high level description of it on our team blog [6]. [1] http://narayana.io/documentation/ [REST-AT] http://narayana.io/docs/specs/restat-v2-draft-8-2013-jul-29.pdf [2] http://narayana.io/docs/project/index.html#_interoperating_with_other_transaction_models [3] https://github.com/jbosstm/quickstart/tree/master/rts [4] https://github.com/jbosstm/quickstart/tree/master/rts/at/jta-service [5] http://narayana.io/docs/project/index.html#_support_for_java_based_services [6] http://jbossts.blogspot.co.uk/2013/07/out-of-box-support-for-restful.html > I have an web application "A" that occasionally have to insert/update > records that belong to another application, "B". To manage this > requirement, application "B" expose some REST endpoints that > application "A" will call whenever it needs. > > Problem is, we need to make sure that the inserts/updates occurring in > both applications are atomic. > > Does anyone have done something similar and can point a solution? I > know that there's a debate whether transactions in REST are > conceptually wrong, but we're willing to break the rules in this case. OK let's not go there then (but when you say "we're willing to break the rules" you are already tacitly stating on which side of the argument you stand). Mike > > Regards! > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > _______________________________________________ > Resteasy-users mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-users -- Michael Musgrove Red Hat UK Ltd, Transactions Team e: mmu...@re... t: +44 191 243 0870 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) |
|
From: Rodrigo U. <rod...@gm...> - 2015-05-25 21:28:32
|
I have an web application "A" that occasionally have to insert/update records that belong to another application, "B". To manage this requirement, application "B" expose some REST endpoints that application "A" will call whenever it needs. Problem is, we need to make sure that the inserts/updates occurring in both applications are atomic. Does anyone have done something similar and can point a solution? I know that there's a debate whether transactions in REST are conceptually wrong, but we're willing to break the rules in this case. Regards! |
|
From: Gervasio A. <ger...@gl...> - 2015-05-21 20:18:27
|
Hello all,
I have some concerns about CacheControlInterceptor:
1. I was debugging and I found CacheControlInterceptor has only one
CacheControl instance, with the values of the last initCacheControl method
call, which means, if I have, for example, two classes @Cache annotated,
with different values, CacheControlInterceptor on postProcess, will always
return the same values for all requests.
In code, this is the mentioned example:
@Path("/foo")
@Cache(*maxAge = 3600, sMaxAge = 3600*, mustRevalidate = false,
proxyRevalidate = true, isPrivate = false, noTransform = true)
public class Resource1 {
@GET
public String getFoo() {
...
}
}
@Path("/bar")
@Cache(*maxAge = 500, sMaxAge = 500*, mustRevalidate = false,
proxyRevalidate = true, isPrivate = false, noTransform = true)
public class Resource2 {
@GET
public String getBar() {
...
}
}
*Assuming Resource2 is parsed first for CacheControlInterceptor *, when
reaching GET <host>/foo I get in the response headers:
Cache-Control → no-transform, proxy-revalidate, s-maxage=3600, max-age=3600
And when reaching GET <host>/bar I also get in the response headers:
Cache-Control → no-transform, proxy-revalidate, s-maxage=3600, max-age=3600
while expected: s-maxage=500, max-age=500
2. Why 304 responses are not being included in postProcess method? They are
also good ones when using ETag checks.
What should be the best way to enhance CacheControlInterceptor to also
include those 304 on postProcess? Just implementing a PostProcessInterceptor
and registring it as @Provider?
Thanks in advance for your help.
Gervasio
--
The information contained in this e-mail may be confidential. It has been
sent for the sole use of the intended recipient(s). If the reader of this
message is not an intended recipient, you are hereby notified that any
unauthorized review, use, disclosure, dissemination, distribution or
copying of this communication, or any of its contents,
is strictly prohibited. If you have received it by mistake please let us
know by e-mail immediately and delete it from your system. Many thanks.
La información contenida en este mensaje puede ser confidencial. Ha sido
enviada para el uso exclusivo del destinatario(s) previsto. Si el lector de
este mensaje no fuera el destinatario previsto, por el presente queda Ud.
notificado que cualquier lectura, uso, publicación, diseminación,
distribución o copiado de esta comunicación o su contenido está
estrictamente prohibido. En caso de que Ud. hubiera recibido este mensaje
por error le agradeceremos notificarnos por e-mail inmediatamente y
eliminarlo de su sistema. Muchas gracias.
|
|
From: Przemyslaw W. <prz...@go...> - 2015-05-14 11:04:57
|
On 14.05.2015 03:38, Ron Sigal wrote: > Very interesting. Honestly, I'm not sure how to think about this. The > JAX-RS 1.1 spec says "An implementation MUST NOT invoke a method whose > effective value of @Produces does not match the request Accept header.", > but I don't see where it ever actually defines "match". And Resteasy > passes the TCK tests. Really, I'm not even sure what "match" SHOULD > mean. We could get crazy and do full blown unification > (http://en.wikipedia.org/wiki/Unification_%28computer_science%29). Ugh. > > Resource matching is a very fundamental notion in JAX-RS, and I wouldn't > want to make any changes without being very careful. > > Any thoughts about how to interpret "match"? Certainly the decisive answer would be: in the same way as HTTP spec does. But unfortunately, I can't find relevant spec part that explicitly says that content type of 'type/subtype;key=value' matches Accept header of 'type/subtype'. The examples in [1] suggests so, as does the practice of browser 'Accept' header. So, in my opinion, the @Produces("text/plain;charset=utf-8") should be considered as matching the relevant client's request.accept("text/plain"); Przemek |
|
From: Przemyslaw W. <prz...@go...> - 2015-05-14 11:04:09
|
On 14.05.2015 12:34, Przemyslaw Wesolek wrote: > Certainly the decisive answer would be: in the same way as HTTP spec > does. But unfortunately, I can't find relevant spec part that explicitly > says that content type of 'type/subtype;key=value' matches Accept header > of 'type/subtype'. The examples in [1] suggests so, as does the practice > of browser 'Accept' header. Sorry, forgotten reference is: [1] https://tools.ietf.org/html/rfc7231#section-5.3.2 Przemek |
|
From: Ron S. <rs...@re...> - 2015-05-14 01:38:55
|
Hi Ramesh,
Ok, I see that
@Path("utf8")
@Produces("text/plain;charset=utf-8")
@POST
public String utf8()
{
System.out.println("TestResource.utf8()");
return "ok";
}
...
@Test
public void testAcceptNoUtf8() throws Exception
{
ClientRequest request = new
ClientRequest("http://localhost:8081/utf8/");
request.accept("text/plain");
ClientResponse<?> response = request.post();
Assert.assertEquals(200, response.getStatus());
String entity = response.getEntity(String.class);
System.out.println("result: " + entity);
}
results in
> org.jboss.resteasy.spi.NotAcceptableException: RESTEASY001530: No
> match for accept header
whereas
@Path("nocharset")
@Produces("text/plain")
@POST
public String noCharset()
{
return "ok";
}
...
@Test
public void testAcceptUtf8No() throws Exception
{
ClientRequest request = new
ClientRequest("http://localhost:8081/nocharset/");
request.accept("text/plain;charset=utf-8");
ClientResponse<?> response = request.post();
Assert.assertEquals(200, response.getStatus());
String entity = response.getEntity(String.class);
System.out.println("result: " + entity);
}
works fine. The relevant code is
@Override
public boolean isCompatible(MediaType other)
{
boolean result;
if (other == null)
result = false;
if (getType().equals(MEDIA_TYPE_WILDCARD) ||
other.getType().equals(MEDIA_TYPE_WILDCARD))
result = true;
else if (getType().equalsIgnoreCase(other.getType()) &&
(getSubtype().equals(MEDIA_TYPE_WILDCARD) ||
other.getSubtype().equals(MEDIA_TYPE_WILDCARD)))
result = true;
else
{
if (getType().equalsIgnoreCase(other.getType())
&& this.getSubtype().equalsIgnoreCase(other.getSubtype()))
{
if (getParameters() == null || getParameters().size() == 0)
{
result = true;
}
else
{
result = this.equals(other);
}
}
else
{
result = false;
}
}
return result;
}
in org.jboss.resteasy.util.WeightedMediaType in the resteasy-jaxrs module.
Very interesting. Honestly, I'm not sure how to think about this. The
JAX-RS 1.1 spec says "An implementation MUST NOT invoke a method whose
effective value of @Produces does not match the request Accept header.",
but I don't see where it ever actually defines "match". And Resteasy
passes the TCK tests. Really, I'm not even sure what "match" SHOULD
mean. We could get crazy and do full blown unification
(http://en.wikipedia.org/wiki/Unification_%28computer_science%29). Ugh.
Resource matching is a very fundamental notion in JAX-RS, and I wouldn't
want to make any changes without being very careful.
Any thoughts about how to interpret "match"?
-Ron
> public boolean isCompatible(MediaType other)
> {
> boolean result;
> if (other == null)
> result = false;
> if (getType().equals(MEDIA_TYPE_WILDCARD) ||
> other.getType().equals(MEDIA_TYPE_WILDCARD))
> result = true;
> else if (getType().equalsIgnoreCase(other.getType()) &&
> (getSubtype().equals(MEDIA_TYPE_WILDCARD) ||
> other.getSubtype().equals(MEDIA_TYPE_WILDCARD)))
> result = true;
> else
> {
> if (getType().equalsIgnoreCase(other.getType())
> &&
> this.getSubtype().equalsIgnoreCase(other.getSubtype()))
> {
> if (getParameters() == null || getParameters().size() == 0)
> {
> result = true;
> }
> else
> {
> result = this.equals(other);
> }
> }
> else
> {
> result = false;
> }
> }
> return result;
> }
On 05/12/2015 03:55 PM, Ramesh Reddy wrote:
> We are using under EAP 6.3 (2.3.8) and EAP 6.4 (2.3.9 or 2.3.10)
>
> ------------------------------------------------------------------------
>
> Meant to reply to list.
>
> Anyway, it looks like Resteasy 2.3.10.Final, more or less.
>
> -Ron
>
>
> -------- Forwarded Message --------
> Subject: Re: [Resteasy-users] Question about Accepts Header
> Date: Mon, 11 May 2015 21:19:24 -0400
> From: Ron Sigal <rs...@re...>
> To: Ramesh Reddy <ra...@re...>
>
>
>
> Hi Ramesh,
>
> Which version of Resteasy are you using in Teiid?
>
> Thanks,
> Ron
>
> On 05/11/2015 05:05 PM, Ramesh Reddy wrote:
> > Hi,
> >
> > In Teiid we have used RestEasy to implement the OData layer. We are seeing an issue with "Accepts" header. It is described herehttps://issues.jboss.org/browse/TEIID-3471 see 2nd comment. Any pointers to resolve are appreciated.
> >
> > Thanks
> >
> > Ramesh..
> >
> > ------------------------------------------------------------------------------
> > One dashboard for servers and applications across Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> >http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > _______________________________________________
> > Resteasy-users mailing list
> >Res...@li...
> >https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across
> Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable
> Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
|
|
From: Ramesh R. <ra...@re...> - 2015-05-12 19:55:37
|
We are using under EAP 6.3 (2.3.8) and EAP 6.4 (2.3.9 or 2.3.10) ----- Original Message ----- > Meant to reply to list. > Anyway, it looks like Resteasy 2.3.10.Final, more or less. > -Ron > -------- Forwarded Message -------- > Subject: Re: [Resteasy-users] Question about Accepts Header > Date: Mon, 11 May 2015 21:19:24 -0400 > From: Ron Sigal <rs...@re...> > To: Ramesh Reddy <ra...@re...> > Hi Ramesh, > Which version of Resteasy are you using in Teiid? > Thanks, > Ron > On 05/11/2015 05:05 PM, Ramesh Reddy wrote: > > Hi, > > > > In Teiid we have used RestEasy to implement the OData layer. We are seeing > > an issue with "Accepts" header. It is described here > > https://issues.jboss.org/browse/TEIID-3471 see 2nd comment. Any pointers > > to resolve are appreciated. > > > > Thanks > > > > Ramesh.. > > > > ------------------------------------------------------------------------------ > > One dashboard for servers and applications across Physical-Virtual-Cloud > > Widest out-of-the-box monitoring support with 50+ applications > > Performance metrics, stats and reports that give you Actionable Insights > > Deep dive visibility with transaction tracing using APM Insight. > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > _______________________________________________ > > Resteasy-users mailing list > > Res...@li... > > > https://lists.sourceforge.net/lists/listinfo/resteasy-users > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Resteasy-users mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-users |
|
From: Guy R. <guy...@gm...> - 2015-05-12 04:47:06
|
Ron, thanks for the reply. We figured out that having XML in the
Produces clause appears to be causing this issue. Our plan is to remove
that clause, and just allow JSON. When we do that, the method works
without error.
--
Guy Rouillier
------ Original Message ------
From: "Ron Sigal" <rs...@re...>
To: res...@li...
Sent: 5/11/2015 8:53:03 PM
Subject: Re: [Resteasy-users] Client proxy issue deserializing
Response.Status
>Hi Guy,
>
>Maybe there's a problem with the media type produced by your resource
>method.
>
>The attached TestResponseStatus works for me. However, when I comment
>out the @Produces annotation:
>
>> @Path("/")
>> public static class TestResourceImpl
>> {
>> @POST
>> @Path("post")
>>// @Produces("text/plain")
>> public Response.Status post()
>> {
>> return Response.Status.OK;
>> }
>> }
>
>I get
>
>>SEVERE: Failed executing POST /post
>>org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not
>>find MessageBodyWriter for response object of type:
>>javax.ws.rs.core.Response$Status of media type:
>>application/octet-stream
>> at
>>org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:67)
>> at
>>org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:427)
>> at
>>org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:376)
>> at
>>org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
>> at
>>org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
>> at
>>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>> at
>>org.jboss.resteasy.plugins.server.tjws.TJWSServletDispatcher.service(TJWSServletDispatcher.java:40)
>> at
>>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>> at Acme.Serve.Serve$ServeConnection.runServlet(Serve.java:2331)
>> at Acme.Serve.Serve$ServeConnection.parseRequest(Serve.java:2285)
>> at Acme.Serve.Serve$ServeConnection.run(Serve.java:2057)
>> at Acme.Utils$ThreadPool$PooledThread.run(Utils.java:1402)
>> at java.lang.Thread.run(Thread.java:745)
>>
>>status: Internal Server Error
>
>Is that what you are seeing?
>
>-Ron
>
>On 05/04/2015 03:01 PM, Guy Rouillier wrote:
>>We have a webservice POST method that returns a Response.Status object
>>as the entity. I've debugged this running method to verify that the
>>return value is Response.Status.OK.
>>
>>We use the RestEasy client proxy to invoke our webservice methods.
>>The
>>approach works well for us, and our developers find the approach easy
>>to
>>use. However, in this case, the proxy is deserializing this return
>>object as Response.Status.INTERNAL_SERVER_ERROR.
>>
>>Any idea on why this would happen?
>>
>>Thanks.
>>
>>--
>>Guy Rouillier
>>
>>
>>---
>>This email has been checked for viruses by Avast antivirus software.
>>http://www.avast.com
>>
>>
>>------------------------------------------------------------------------------
>>One dashboard for servers and applications across
>>Physical-Virtual-Cloud
>>Widest out-of-the-box monitoring support with 50+ applications
>>Performance metrics, stats and reports that give you Actionable
>>Insights
>>Deep dive visibility with transaction tracing using APM Insight.
>>http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>_______________________________________________
>>Resteasy-users mailing list
>>Res...@li...
>>https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
|
|
From: Ron S. <rs...@re...> - 2015-05-12 01:28:11
|
I meant to reply to list.
-------- Forwarded Message --------
Subject: Re: [Resteasy-developers] Maven build fails for 3.0.10.Final
tag and master branch
Date: Mon, 11 May 2015 13:04:04 -0400
From: Ron Sigal <rs...@re...>
To: Konstantin Gribov <gr...@gm...>
Hi Konstantin,
In your version of TestSecureProcessing, do you see
> void doMaxAttributesFails() throws Exception
> {
> DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
> System.out.println("dbf.getClass(): " + dbf.getClass());
> if
> ("org.apache.xerces.jaxp.DocumentBuilderFactoryImpl".equals(dbf.getClass().getName()))
> {
> System.out.println("Testing with Red Hat version of Xerces,
> skipping max attributes test");
> return;
> }
If I remember correctly, the JDK version of Xerces has a max attribute
property, and the Red Hat version of Xerces does not. Note that the
"redhat-xerces" profile in resteasy-jaxrs will use the Red Hat version.
By default, the version in the JDK should get used. Could you try to
figure out which version is being used when you run the tests?
Thanks,
Ron
Could you show me the
On 03/26/2015 06:21 PM, Konstantin Gribov wrote:
> Hi, Ron.
>
> It builds fine now (after merging my PR
> https://github.com/resteasy/Resteasy/pull/624) on both openjdk7 and
> oracle jdk7. But I'm still building it without tests because current
> master (eda61d9824652ee3cc16983ae8de1d08b1397a31) still fails on
> performing tests on "RESTEasy JAX-RS Implementation":
>
> Failed tests:
> TestIIOImageProvider.testPostJPEGIMage:81
> TestSecureProcessing.testSecurityTrueDTDsTrueExpansionFalse:291->doTestSkipFailsFailsSkip:304->doMaxAttributesFails:391
> null
> TestSecureProcessing.testSecurityTrueDTDsTrueExpansionTrue:298->doTestSkipFailsFailsSkip:304->doMaxAttributesFails:391
> null
> TestSecureProcessing.testSecurityDefaultDTDsDefaultExpansionDefault:116->doTestSkipFailsFailsSkip:304->doMaxAttributesFails:391
> null
> TestSecureProcessing.testSecurityDefaultDTDsDefaultExpansionFalse:123->doTestSkipFailsFailsSkip:304->doMaxAttributesFails:391
> null
> TestSecureProcessing.testSecurityDefaultDTDsDefaultExpansionTrue:130->doTestSkipFailsFailsSkip:304->doMaxAttributesFails:391
> null
> TestSecureProcessing.testSecurityDefaultDTDsFalseExpansionDefault:137->doTestFailsFailsPassesFails:317->doMaxAttributesFails:391
> null
> TestSecureProcessing.testSecurityDefaultDTDsFalseExpansionFalse:144->doTestFailsFailsPassesFails:317->doMaxAttributesFails:391
> null
> TestSecureProcessing.testSecurityDefaultDTDsFalseExpansionTrue:151->doTestFailsFailsPassesPasses:325->doMaxAttributesFails:391
> null
> TestSecureProcessing.testSecurityDefaultDTDsTrueExpansionDefault:158->doTestSkipFailsFailsSkip:304->doMaxAttributesFails:391
> null
> TestSecureProcessing.testSecurityDefaultDTDsTrueExpansionFalse:165->doTestSkipFailsFailsSkip:304->doMaxAttributesFails:391
> null
> TestSecureProcessing.testSecurityDefaultDTDsTrueExpansionTrue:172->doTestSkipFailsFailsSkip:304->doMaxAttributesFails:391
> null
> TestSecureProcessing.testSecurityTrueDTDsDefaultExpansionDefault:242->doTestSkipFailsFailsSkip:304->doMaxAttributesFails:391
> null
> TestSecureProcessing.testSecurityTrueDTDsDefaultExpansionFalse:249->doTestSkipFailsFailsSkip:304->doMaxAttributesFails:391
> null
> TestSecureProcessing.testSecurityTrueDTDsDefaultExpansionTrue:256->doTestSkipFailsFailsSkip:304->doMaxAttributesFails:391
> null
> TestSecureProcessing.testSecurityTrueDTDsFalseExpansionDefault:263->doTestFailsFailsPassesFails:317->doMaxAttributesFails:391
> null
> TestSecureProcessing.testSecurityTrueDTDsFalseExpansionFalse:270->doTestFailsFailsPassesFails:317->doMaxAttributesFails:391
> null
> TestSecureProcessing.testSecurityTrueDTDsFalseExpansionTrue:277->doTestFailsFailsPassesPasses:325->doMaxAttributesFails:391
> null
> TestSecureProcessing.testSecurityTrueDTDsTrueExpansionDefault:284->doTestSkipFailsFailsSkip:304->doMaxAttributesFails:391
> null
>
> --
> Best regards,
> Konstantin Gribov
>
> сб, 14 марта 2015 г. в 6:38, Ron Sigal <rs...@re...
> <mailto:rs...@re...>>:
>
> Hi Konstantin,
>
> It builds for me. Which JDK are you using?
>
> -Ron
>
>
> On 02/11/2015 11:02 AM, Konstantin Gribov wrote:
>> Hi, folks.
>>
>> Currently `mvn clean install` invocation fails even with
>> `-DskipTests=true`.
>>
>> Build fails because maven can't find
>> `javax.enterprise.inject.spi.Extension` when building
>> `org/jboss/resteasy/plugins/validation/GeneralValidatorImpl.java`
>> in *Resteasy Validator Provider BV 1.1*
>>
>> When building with tests turned on it fails earlier, on running
>> tests in restesy-jaxrs module.
>>
>> Related logs (with and without tests run) can be found at [1].
>>
>> [1]: https://gist.github.com/grossws/a6f6395c1337f61e43cd
>>
>> --
>> Best regards,
>> Konstantin Gribov
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now.http://goparallel.sourceforge.net/
>>
>>
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li... <mailto:Res...@li...>
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel
> Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your
> hub for all
> things parallel software development, from weekly thought
> leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and
> join the
> conversation now.
> http://goparallel.sourceforge.net/_______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> <mailto:Res...@li...>
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
|
10 messages has been excluded from this view by a project administrator.
