[JBoss JIRA] (WFLY-4621) RESTEasy SMIME doesn't work with WildFly current module setup
by Ron Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-4621?page=com.atlassian.jira.plugin.... ]
Ron Sigal commented on WFLY-4621:
---------------------------------
[~mkopecky], it looks like this issue just fell through the cracks. That was before we had your eagle eyes on the job. ;-)
> RESTEasy SMIME doesn't work with WildFly current module setup
> -------------------------------------------------------------
>
> Key: WFLY-4621
> URL: https://issues.jboss.org/browse/WFLY-4621
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 9.0.0.CR1
> Reporter: Weinan Li
> Assignee: Weinan Li
> Priority: Major
> Attachments: patch_WFLY-4621_all, patch_WFLY-4621_new
>
>
> RESTEasy provides the functions of SMIME encryption and here is an example that can be deployed into WildFly:
> https://github.com/liweinan/digital-signatures/tree/master/smime
> And currently resteasy-crypto module doesn't work properly in WildFly unless applied the following patch:
> {code:diff}
> power:modules weinanli$ git diff
> warning: LF will be replaced by CRLF in system/layers/base/org/bouncycastle/main/module.xml.
> The file will have its original line endings in your working directory.
> diff --git a/system/layers/base/org/bouncycastle/main/module.xml b/system/layers/base/org/bouncycastle/main/module.xml
> index 5d13395..83ae97c 100644
> --- a/system/layers/base/org/bouncycastle/main/module.xml
> +++ b/system/layers/base/org/bouncycastle/main/module.xml
> @@ -24,12 +24,17 @@
> <module xmlns="urn:jboss:module:1.3" name="org.bouncycastle">
> <resources>
> + <!--
> <resource-root path="bcprov-jdk15on-1.52.jar"/>
> <resource-root path="bcmail-jdk15on-1.52.jar"/>
> + -->
> + <resource-root path="bcprov-jdk16-1.46.jar"/>
> + <resource-root path="bcmail-jdk16-1.46.jar"/>
> <resource-root path="bcpkix-jdk15on-1.52.jar"/>
> </resources>
> <dependencies>
> <module name="javax.api"/>
> + <module name="javax.mail.api"/>
> + <module name="javax.activation.api"/>
> </dependencies>
> -
> </module>
> {code}
> After applying the above patch then the example can pass all the tests:
> {code}
> power:smime weinanli$ mvn -q clean package
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
> power:smime weinanli$ mvn -q wildfly:deploy
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
> May 11, 2015 9:24:27 PM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.3.0.Final
> May 11, 2015 9:24:27 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.0.Final
> May 11, 2015 9:24:27 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.7.Final
> power:smime weinanli$ mvn -q integration-test
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running org.jboss.resteasy.tests.smime.SMIMETest
> Encrypted Message From Server:
> Customer{name='Bill'}
> Signed Message From Server:
> Customer{name='Bill'}
> Customer{name='Bill'}
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.682 sec - in org.jboss.resteasy.tests.smime.SMIMETest
> Results :
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0
> power:smime weinanli$
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (WFLY-2752) Using an injected UriInfo object by the JAX-RS runtime environment does not work
by Ron Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-2752?page=com.atlassian.jira.plugin.... ]
Ron Sigal resolved WFLY-2752.
-----------------------------
Resolution: Out of Date
> Using an injected UriInfo object by the JAX-RS runtime environment does not work
> --------------------------------------------------------------------------------
>
> Key: WFLY-2752
> URL: https://issues.jboss.org/browse/WFLY-2752
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 8.0.0.CR1
> Reporter: Stan Zelivinski
> Assignee: Ron Sigal
> Priority: Major
>
> The code that works perfectly in WildFly.8.0.0.Beta:
> {code:java}
> package jdsu.vts.tcpcontroller.webservices.rest.resources;
> import java.net.URI;
> import javax.ws.rs.DELETE;
> import javax.ws.rs.GET;
> import javax.ws.rs.PUT;
> import javax.ws.rs.Path;
> import javax.ws.rs.PathParam;
> import javax.ws.rs.Produces;
> import javax.ws.rs.Consumes;
> import javax.ws.rs.core.Context;
> import javax.ws.rs.core.Response;
> import javax.ws.rs.core.UriInfo;
> import jdsu.vts.tcpcontroller.webservices.rest.application.V1_TCPController;
> import jdsu.vts.shared.transferobjects.V1_TCPSetups;
> @Path("/v1")
> public class V1_TCPControllerResource {
> @Context UriInfo uriInfo;
>
> @GET
> @Produces("application/json")
> public Response getControllers() {
> //String json = String.valueOf(m_testsMap.size());
> return Response.ok(V1_TCPController.getCollection()).build();
> }
>
> @PUT
> @Path("{id}")
> @Produces("application/json")
> public Response addController(@PathParam("id") String id) {
> V1_TCPController controller = V1_TCPController.find(id);
> if(controller != null) {
> return Response.status(Response.Status.CONFLICT).build();
> }
> controller = new V1_TCPController(id);
> URI uri = uriInfo.getAbsolutePathBuilder().path(id).build();
> return Response.created(uri).build();
> }
> }
> {code}
> does not work in WildFly.8.0.0.CR1. uriInfo is null in the call.
> Please help.
> Stan
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (WFLY-2752) Using an injected UriInfo object by the JAX-RS runtime environment does not work
by Ron Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-2752?page=com.atlassian.jira.plugin.... ]
Ron Sigal commented on WFLY-2752:
---------------------------------
[~stanzelivinski], we are not currently able to reproduce this problem, so I am closing the issue as out-of-date. You can re-open it if you still have trouble.
> Using an injected UriInfo object by the JAX-RS runtime environment does not work
> --------------------------------------------------------------------------------
>
> Key: WFLY-2752
> URL: https://issues.jboss.org/browse/WFLY-2752
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 8.0.0.CR1
> Reporter: Stan Zelivinski
> Assignee: Ron Sigal
> Priority: Major
>
> The code that works perfectly in WildFly.8.0.0.Beta:
> {code:java}
> package jdsu.vts.tcpcontroller.webservices.rest.resources;
> import java.net.URI;
> import javax.ws.rs.DELETE;
> import javax.ws.rs.GET;
> import javax.ws.rs.PUT;
> import javax.ws.rs.Path;
> import javax.ws.rs.PathParam;
> import javax.ws.rs.Produces;
> import javax.ws.rs.Consumes;
> import javax.ws.rs.core.Context;
> import javax.ws.rs.core.Response;
> import javax.ws.rs.core.UriInfo;
> import jdsu.vts.tcpcontroller.webservices.rest.application.V1_TCPController;
> import jdsu.vts.shared.transferobjects.V1_TCPSetups;
> @Path("/v1")
> public class V1_TCPControllerResource {
> @Context UriInfo uriInfo;
>
> @GET
> @Produces("application/json")
> public Response getControllers() {
> //String json = String.valueOf(m_testsMap.size());
> return Response.ok(V1_TCPController.getCollection()).build();
> }
>
> @PUT
> @Path("{id}")
> @Produces("application/json")
> public Response addController(@PathParam("id") String id) {
> V1_TCPController controller = V1_TCPController.find(id);
> if(controller != null) {
> return Response.status(Response.Status.CONFLICT).build();
> }
> controller = new V1_TCPController(id);
> URI uri = uriInfo.getAbsolutePathBuilder().path(id).build();
> return Response.created(uri).build();
> }
> }
> {code}
> does not work in WildFly.8.0.0.CR1. uriInfo is null in the call.
> Please help.
> Stan
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (WFLY-2495) ContainerXFilter not invoked when registered via DynamicFeature in JAX-RS
by Ron Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-2495?page=com.atlassian.jira.plugin.... ]
Ron Sigal resolved WFLY-2495.
-----------------------------
Resolution: Out of Date
> ContainerXFilter not invoked when registered via DynamicFeature in JAX-RS
> -------------------------------------------------------------------------
>
> Key: WFLY-2495
> URL: https://issues.jboss.org/browse/WFLY-2495
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 8.0.0.Beta1, 8.1.0.Final
> Reporter: Aslak Knutsen
> Assignee: Ron Sigal
> Priority: Major
>
> {code}
> @Provider
> public class DynamicServerLogggingFilterFeature implements DynamicFeature {
> @Override
> public void configure(ResourceInfo ri, FeatureContext fc) {
> if (MyResource.class.isAssignableFrom(ri.getResourceClass())
> && ri.getResourceMethod().isAnnotationPresent(GET.class)) {
> fc.register(new ServerLoggingFilter());
> }
> }
> }
> @Provider
> @ServerLogged
> public class ServerLoggingFilter implements ContainerRequestFilter, ContainerResponseFilter {
> ...
> }
> {code}
> DynamicServerLogggingFilterFeature is called the the ServerLoggingFilter is registered in the FeatureContext, but the filter(ContainerXContext crc) is never called on the ServerLoggingFilter.
> Sample: https://github.com/arun-gupta/javaee7-samples/tree/master/jaxrs/dynamicfi...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (WFLY-6097) Error response handling from bean validation ignores Accept header
by Ron Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-6097?page=com.atlassian.jira.plugin.... ]
Ron Sigal resolved WFLY-6097.
-----------------------------
Resolution: Out of Date
> Error response handling from bean validation ignores Accept header
> ------------------------------------------------------------------
>
> Key: WFLY-6097
> URL: https://issues.jboss.org/browse/WFLY-6097
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 10.0.0.Final
> Environment: Mac OS X El Captain
> java version "1.8.0_66"
> Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
> Reporter: Renann Prado
> Assignee: Ron Sigal
> Priority: Major
> Attachments: delivery-optimization-ear-1.0.Final.ear
>
>
> Basically I have a very simple application that has request validation in the REST endpoints.
> According to the documentation of RESTEasy, I should get a JSON error response if I put "application/json" in Accept header in the request.
> https://docs.jboss.org/resteasy/docs/3.0.13.Final/userguide/html/Validati...
> The mentioned feature worked just fine in Wildfly 9.0.2.Final. Now, however, it doesn't.
> I have tried to upgrade the dependencies in the pom.xml to use dependencies from Wildfly 10.0.0.Final, but still no luck. Though the attached application deploys just fine in Wildfly 9.0.2.Final and Wildfly 10.0.0.Final.
> In WF 9.0.2.Final I used to get the below error *JSON*
> {code:json}
> {
> "exception": null,
> "fieldViolations": [],
> "propertyViolations": [],
> "classViolations": [],
> "parameterViolations": [{
> "constraintType": "PARAMETER",
> "path": "registerLogisticsNetwork.arg0.name",
> "message": "may not be null",
> "value": ""
> }],
> "returnValueViolations": []
> }
> {code}
> In WF 10.0.0.Final I get this:
> {code}
> [PARAMETER]
> [registerLogisticsNetwork.arg0.name]
> [may not be null]
> []
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (WFLY-6097) Error response handling from bean validation ignores Accept header
by Ron Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-6097?page=com.atlassian.jira.plugin.... ]
Ron Sigal commented on WFLY-6097:
---------------------------------
According to [~gunnar.morling]'s experimentation, this problem was solved by RESTEASY-1264. The solution to RESTEASY-1264 has Fix Version 3.0.15.Final, and Wildfly 10.0.0.Final, the Affects Version in this issue, ships with RESTEasy 3.0.14.Final. I think we can assume, then, that this issue is out of date.
> Error response handling from bean validation ignores Accept header
> ------------------------------------------------------------------
>
> Key: WFLY-6097
> URL: https://issues.jboss.org/browse/WFLY-6097
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 10.0.0.Final
> Environment: Mac OS X El Captain
> java version "1.8.0_66"
> Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
> Reporter: Renann Prado
> Assignee: Ron Sigal
> Priority: Major
> Attachments: delivery-optimization-ear-1.0.Final.ear
>
>
> Basically I have a very simple application that has request validation in the REST endpoints.
> According to the documentation of RESTEasy, I should get a JSON error response if I put "application/json" in Accept header in the request.
> https://docs.jboss.org/resteasy/docs/3.0.13.Final/userguide/html/Validati...
> The mentioned feature worked just fine in Wildfly 9.0.2.Final. Now, however, it doesn't.
> I have tried to upgrade the dependencies in the pom.xml to use dependencies from Wildfly 10.0.0.Final, but still no luck. Though the attached application deploys just fine in Wildfly 9.0.2.Final and Wildfly 10.0.0.Final.
> In WF 9.0.2.Final I used to get the below error *JSON*
> {code:json}
> {
> "exception": null,
> "fieldViolations": [],
> "propertyViolations": [],
> "classViolations": [],
> "parameterViolations": [{
> "constraintType": "PARAMETER",
> "path": "registerLogisticsNetwork.arg0.name",
> "message": "may not be null",
> "value": ""
> }],
> "returnValueViolations": []
> }
> {code}
> In WF 10.0.0.Final I get this:
> {code}
> [PARAMETER]
> [registerLogisticsNetwork.arg0.name]
> [may not be null]
> []
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (WFCORE-4359) CommandFormatException: Invalid syntax... when using tab completion
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-4359?page=com.atlassian.jira.plugi... ]
James Perkins moved JBEAP-16503 to WFCORE-4359:
-----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-4359 (was: JBEAP-16503)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
Embedded
(was: CLI)
(was: Embedded)
Affects Version/s: (was: 7.3.0.CD15)
> CommandFormatException: Invalid syntax... when using tab completion
> -------------------------------------------------------------------
>
> Key: WFCORE-4359
> URL: https://issues.jboss.org/browse/WFCORE-4359
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Embedded
> Reporter: Miroslav Novak
> Assignee: James Perkins
> Priority: Major
>
> There is issue when tab completion is used in following malformed command:
> {code}
> [standalone@embedded /] /subsystem=modcluster/proxy=modcluster:add(advertise=false,proxies=mod_cluster-pro14:56:17,909 WARN [org.jboss.as.cli.impl.ValueTypeCompleter] (CLI Terminal Connection (uninterruptable)) Invalid syntax.: org.jboss.as.cli.CommandFormatException: Invalid syntax.
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.enteredState(ValueTypeCompleter.java:951)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser$ParsingContextImpl.enterState(StateParser.java:420)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.ValueTypeCompleter$PropertyListState$1.handle(ValueTypeCompleter.java:1248)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser$ParsingContextImpl.enterState(StateParser.java:421)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.ValueTypeCompleter$InitialValueState$1.handle(ValueTypeCompleter.java:1184)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser$ParsingContextImpl.parse(StateParser.java:261)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser.doParse(StateParser.java:150)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser.parseLine(StateParser.java:124)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser.parseLine(StateParser.java:117)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser.parseLine(StateParser.java:95)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser.parseLine(StateParser.java:75)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser.parse(StateParser.java:65)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.ValueTypeCompleter.parse(ValueTypeCompleter.java:401)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:381)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.operation.OperationRequestCompleter.completeWithValueCompleter(OperationRequestCompleter.java:413)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.operation.OperationRequestCompleter.completeProperties(OperationRequestCompleter.java:672)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:709)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:90)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:99)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.aesh.CLICompletionHandler.completeLegacyCommands(CLICompletionHandler.java:157)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.aesh.CLICompletionHandler.complete(CLICompletionHandler.java:133)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.CLICommandCompleter.doComplete(CLICommandCompleter.java:132)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.CLICommandCompleter.complete(CLICommandCompleter.java:54)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.aesh.CLICompletionHandler.complete(CLICompletionHandler.java:69)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.aesh.CLICompletionHandler.complete(CLICompletionHandler.java:45)
> at org.aesh//org.aesh.readline.completion.CompletionHandler.createCompletionList(CompletionHandler.java:135)
> at org.aesh//org.aesh.readline.completion.CompletionHandler.complete(CompletionHandler.java:103)
> at org.aesh//org.aesh.readline.action.mappings.Complete.accept(Complete.java:62)
> at org.aesh//org.aesh.readline.Readline$AeshInputProcessor.parse(Readline.java:246)
> at org.aesh//org.aesh.readline.Readline$AeshInputProcessor.access$100(Readline.java:174)
> at org.aesh//org.aesh.readline.Readline.readInput(Readline.java:95)
> at org.aesh//org.aesh.readline.Readline.access$1000(Readline.java:57)
> at org.aesh//org.aesh.readline.Readline$AeshInputProcessor.lambda$start$1(Readline.java:333)
> at org.aesh//org.aesh.terminal.EventDecoder.accept(EventDecoder.java:118)
> at org.aesh//org.aesh.terminal.EventDecoder.accept(EventDecoder.java:31)
> at org.aesh//org.aesh.io.Decoder.write(Decoder.java:133)
> at org.aesh//org.aesh.readline.tty.terminal.TerminalConnection.openBlocking(TerminalConnection.java:216)
> at org.aesh//org.aesh.readline.tty.terminal.TerminalConnection.openBlocking(TerminalConnection.java:203)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.ReadlineConsole$CLITerminalConnection.lambda$null$1(ReadlineConsole.java:178)
> at java.base/java.lang.Thread.run(Thread.java:834)
>
>
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0155: 'listener' may not be null",
> "rolled-back" => true
> }
> {code}
> where attribute {{proxies}} should take a list. Exception should not be thrown.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (LOGMGR-241) Expose the current LogContextSelector from the LogContext
by James Perkins (Jira)
James Perkins created LOGMGR-241:
------------------------------------
Summary: Expose the current LogContextSelector from the LogContext
Key: LOGMGR-241
URL: https://issues.jboss.org/browse/LOGMGR-241
Project: JBoss Log Manager
Issue Type: Enhancement
Components: core
Reporter: James Perkins
Assignee: James Perkins
Fix For: 2.1.7.Final, 2.2.0.Final, 3.0.0.Final
Currently you can set a {{LogContextSelector}} on a {{LogContext}} however there is no way to query the currently set selector. This could be useful in cases where you need to wrap a current selector in a new selector.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months