[JBoss JIRA] (WFLY-4177) Deployment info should not accept wildcard as server-group parameter
by Filippe Spolti (JIRA)
[ https://issues.jboss.org/browse/WFLY-4177?page=com.atlassian.jira.plugin.... ]
Filippe Spolti updated WFLY-4177:
---------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/396
> Deployment info should not accept wildcard as server-group parameter
> --------------------------------------------------------------------
>
> Key: WFLY-4177
> URL: https://issues.jboss.org/browse/WFLY-4177
> Project: WildFly
> Issue Type: Enhancement
> Components: CLI
> Affects Versions: 9.0.0.Alpha1
> Environment: All environments.
> Reporter: Filippe Spolti
> Assignee: Filippe Spolti
> Priority: Optional
> Labels: core
> Fix For: No Release
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Actually the deployment-info in a domain mode accepts the wildcard *, but when the * is given the CLI lists only the last server-group in the list, not all. The help says:
> - single server group with a state report about each deployment in the
> domain with regard to the selected server group.
> In this case, the --server-group argument is required and its value
> must be a specific server group name, not a wildcard expression.
> The output of the command is a table with headers NAME, RUNTIME-NAME and STATE.
> Ex:
> [domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
> NAME RUNTIME-NAME STATE
> test.war test.war not added
> After the change:
> [domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
> Wildcards are note permited here, please give a valid server-group name.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4177) Deployment info should not accept wildcard as server-group parameter
by Filippe Spolti (JIRA)
[ https://issues.jboss.org/browse/WFLY-4177?page=com.atlassian.jira.plugin.... ]
Filippe Spolti updated WFLY-4177:
---------------------------------
Summary: Deployment info should not accept wildcard as server-group parameter (was: Deployment info should not accept wildcard in the server-group name)
> Deployment info should not accept wildcard as server-group parameter
> --------------------------------------------------------------------
>
> Key: WFLY-4177
> URL: https://issues.jboss.org/browse/WFLY-4177
> Project: WildFly
> Issue Type: Enhancement
> Components: CLI
> Affects Versions: 9.0.0.Alpha1
> Environment: All environments.
> Reporter: Filippe Spolti
> Assignee: Filippe Spolti
> Priority: Optional
> Labels: core
> Fix For: No Release
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Actually the deployment-info in a domain mode accepts the wildcard *, but when the * is given the CLI lists only the last server-group in the list, not all. The help says:
> - single server group with a state report about each deployment in the
> domain with regard to the selected server group.
> In this case, the --server-group argument is required and its value
> must be a specific server group name, not a wildcard expression.
> The output of the command is a table with headers NAME, RUNTIME-NAME and STATE.
> Ex:
> [domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
> NAME RUNTIME-NAME STATE
> test.war test.war not added
> After the change:
> [domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
> Wildcards are note permited here, please give a valid server-group name.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4177) Deployment info should not accept wildcard in the server-group name
by Filippe Spolti (JIRA)
[ https://issues.jboss.org/browse/WFLY-4177?page=com.atlassian.jira.plugin.... ]
Filippe Spolti updated WFLY-4177:
---------------------------------
Description:
Actually the deployment-info in a domain mode accepts the wildcard '*' but when the '*' is given the CLI lists only the last server-group in the list, not all. The help says:
- single server group with a state report about each deployment in the
domain with regard to the selected server group.
In this case, the --server-group argument is required and its value
must be a specific server group name, not a wildcard expression.
The output of the command is a table with headers NAME, RUNTIME-NAME and STATE.
Ex:
[domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
NAME RUNTIME-NAME STATE
test.war test.war not added
After the change:
[domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
Wildcards are note permited here, please give a valid server-group name.
was:
Actually the deployment-info in a domain mode accepts the wildcard "*" but when the "*" is given the CLI lists only the last server-group in the list, not all. The help says:
- single server group with a state report about each deployment in the
domain with regard to the selected server group.
In this case, the --server-group argument is required and its value
must be a specific server group name, not a wildcard expression.
The output of the command is a table with headers NAME, RUNTIME-NAME and STATE.
Ex:
[domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
NAME RUNTIME-NAME STATE
test.war test.war not added
After the change:
[domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
Wildcards are note permited here, please give a valid server-group name.
> Deployment info should not accept wildcard in the server-group name
> -------------------------------------------------------------------
>
> Key: WFLY-4177
> URL: https://issues.jboss.org/browse/WFLY-4177
> Project: WildFly
> Issue Type: Enhancement
> Components: CLI
> Affects Versions: 9.0.0.Alpha1
> Environment: All environments.
> Reporter: Filippe Spolti
> Assignee: Filippe Spolti
> Priority: Optional
> Labels: core
> Fix For: No Release
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Actually the deployment-info in a domain mode accepts the wildcard '*' but when the '*' is given the CLI lists only the last server-group in the list, not all. The help says:
> - single server group with a state report about each deployment in the
> domain with regard to the selected server group.
> In this case, the --server-group argument is required and its value
> must be a specific server group name, not a wildcard expression.
> The output of the command is a table with headers NAME, RUNTIME-NAME and STATE.
> Ex:
> [domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
> NAME RUNTIME-NAME STATE
> test.war test.war not added
> After the change:
> [domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
> Wildcards are note permited here, please give a valid server-group name.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4177) Deployment info should not accept wildcard in the server-group name
by Filippe Spolti (JIRA)
[ https://issues.jboss.org/browse/WFLY-4177?page=com.atlassian.jira.plugin.... ]
Filippe Spolti updated WFLY-4177:
---------------------------------
Description:
Actually the deployment-info in a domain mode accepts the wildcard * but when the * is given the CLI lists only the last server-group in the list, not all. The help says:
- single server group with a state report about each deployment in the
domain with regard to the selected server group.
In this case, the --server-group argument is required and its value
must be a specific server group name, not a wildcard expression.
The output of the command is a table with headers NAME, RUNTIME-NAME and STATE.
Ex:
[domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
NAME RUNTIME-NAME STATE
test.war test.war not added
After the change:
[domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
Wildcards are note permited here, please give a valid server-group name.
was:
Actually the deployment-info in a domain mode accepts the wildcard '*' but when the '*' is given the CLI lists only the last server-group in the list, not all. The help says:
- single server group with a state report about each deployment in the
domain with regard to the selected server group.
In this case, the --server-group argument is required and its value
must be a specific server group name, not a wildcard expression.
The output of the command is a table with headers NAME, RUNTIME-NAME and STATE.
Ex:
[domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
NAME RUNTIME-NAME STATE
test.war test.war not added
After the change:
[domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
Wildcards are note permited here, please give a valid server-group name.
> Deployment info should not accept wildcard in the server-group name
> -------------------------------------------------------------------
>
> Key: WFLY-4177
> URL: https://issues.jboss.org/browse/WFLY-4177
> Project: WildFly
> Issue Type: Enhancement
> Components: CLI
> Affects Versions: 9.0.0.Alpha1
> Environment: All environments.
> Reporter: Filippe Spolti
> Assignee: Filippe Spolti
> Priority: Optional
> Labels: core
> Fix For: No Release
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Actually the deployment-info in a domain mode accepts the wildcard * but when the * is given the CLI lists only the last server-group in the list, not all. The help says:
> - single server group with a state report about each deployment in the
> domain with regard to the selected server group.
> In this case, the --server-group argument is required and its value
> must be a specific server group name, not a wildcard expression.
> The output of the command is a table with headers NAME, RUNTIME-NAME and STATE.
> Ex:
> [domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
> NAME RUNTIME-NAME STATE
> test.war test.war not added
> After the change:
> [domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
> Wildcards are note permited here, please give a valid server-group name.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4177) Deployment info should not accept wildcard in the server-group name
by Filippe Spolti (JIRA)
[ https://issues.jboss.org/browse/WFLY-4177?page=com.atlassian.jira.plugin.... ]
Filippe Spolti updated WFLY-4177:
---------------------------------
Description:
Actually the deployment-info in a domain mode accepts the wildcard *, but when the * is given the CLI lists only the last server-group in the list, not all. The help says:
- single server group with a state report about each deployment in the
domain with regard to the selected server group.
In this case, the --server-group argument is required and its value
must be a specific server group name, not a wildcard expression.
The output of the command is a table with headers NAME, RUNTIME-NAME and STATE.
Ex:
[domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
NAME RUNTIME-NAME STATE
test.war test.war not added
After the change:
[domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
Wildcards are note permited here, please give a valid server-group name.
was:
Actually the deployment-info in a domain mode accepts the wildcard * but when the * is given the CLI lists only the last server-group in the list, not all. The help says:
- single server group with a state report about each deployment in the
domain with regard to the selected server group.
In this case, the --server-group argument is required and its value
must be a specific server group name, not a wildcard expression.
The output of the command is a table with headers NAME, RUNTIME-NAME and STATE.
Ex:
[domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
NAME RUNTIME-NAME STATE
test.war test.war not added
After the change:
[domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
Wildcards are note permited here, please give a valid server-group name.
> Deployment info should not accept wildcard in the server-group name
> -------------------------------------------------------------------
>
> Key: WFLY-4177
> URL: https://issues.jboss.org/browse/WFLY-4177
> Project: WildFly
> Issue Type: Enhancement
> Components: CLI
> Affects Versions: 9.0.0.Alpha1
> Environment: All environments.
> Reporter: Filippe Spolti
> Assignee: Filippe Spolti
> Priority: Optional
> Labels: core
> Fix For: No Release
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Actually the deployment-info in a domain mode accepts the wildcard *, but when the * is given the CLI lists only the last server-group in the list, not all. The help says:
> - single server group with a state report about each deployment in the
> domain with regard to the selected server group.
> In this case, the --server-group argument is required and its value
> must be a specific server group name, not a wildcard expression.
> The output of the command is a table with headers NAME, RUNTIME-NAME and STATE.
> Ex:
> [domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
> NAME RUNTIME-NAME STATE
> test.war test.war not added
> After the change:
> [domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
> Wildcards are note permited here, please give a valid server-group name.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4177) Deployment info should not accept wildcard in the server-group name
by Filippe Spolti (JIRA)
[ https://issues.jboss.org/browse/WFLY-4177?page=com.atlassian.jira.plugin.... ]
Filippe Spolti updated WFLY-4177:
---------------------------------
Security: (was: Red Hat Internal)
> Deployment info should not accept wildcard in the server-group name
> -------------------------------------------------------------------
>
> Key: WFLY-4177
> URL: https://issues.jboss.org/browse/WFLY-4177
> Project: WildFly
> Issue Type: Enhancement
> Components: CLI
> Affects Versions: 9.0.0.Alpha1
> Environment: All environments.
> Reporter: Filippe Spolti
> Assignee: Filippe Spolti
> Priority: Optional
> Labels: core
> Fix For: No Release
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Actually the deployment-info in a domain mode accepts the wildcard "*" but when the "*" is given the CLI lists only the last server-group in the list, not all. The help says:
> - single server group with a state report about each deployment in the
> domain with regard to the selected server group.
> In this case, the --server-group argument is required and its value
> must be a specific server group name, not a wildcard expression.
> The output of the command is a table with headers NAME, RUNTIME-NAME and STATE.
> Ex:
> [domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
> NAME RUNTIME-NAME STATE
> test.war test.war not added
> After the change:
> [domain@localhost:9990 /] deployment-info --name=test.war --server-group=*
> Wildcards are note permited here, please give a valid server-group name.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4176) ClassLoader permissions bug in org.glassfish.enterprise.concurrent.ContextServiceImpl
by James Perkins (JIRA)
James Perkins created WFLY-4176:
-----------------------------------
Summary: ClassLoader permissions bug in org.glassfish.enterprise.concurrent.ContextServiceImpl
Key: WFLY-4176
URL: https://issues.jboss.org/browse/WFLY-4176
Project: WildFly
Issue Type: Enhancement
Components: EE
Reporter: James Perkins
Assignee: Eduardo Martins
The [{{org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase}}|https://github.com/wildfly/wildfly/blob/master/testsuite/integration/web/src/test/java/org/jboss/as/test/integration/ee/concurrent/DefaultContextServiceServletTestCase.java] fails due to the {{org.glassfish.enterprise.concurrent.ContextServiceImpl.createContextualProxy}} attempting to get a class loader without the proper permissions.
Stack Trace:
{code}
14:53:57,032 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /war-example/simple: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/war-example.war/WEB-INF/classes <no signer certificates>)" of "null")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:270)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:172)
at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1517)
at java.lang.Class.getClassLoader(Class.java:679)
at org.glassfish.enterprise.concurrent.ContextServiceImpl.createContextualProxy(ContextServiceImpl.java:137)
at org.glassfish.enterprise.concurrent.ContextServiceImpl.createContextualProxy(ContextServiceImpl.java:125)
at org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceTestServlet.doGet(DefaultContextServiceTestServlet.java:58)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:172)
at java.security.AccessController.doPrivileged(Native Method)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:169)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:767)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
The runtime permissions added to the test will need to be removed once this issue is resolved.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4174) Xalan Linkage error : TransformerConfigurationException
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-4174?page=com.atlassian.jira.plugin.... ]
David Lloyd updated WFLY-4174:
------------------------------
Forum Reference: https://developer.jboss.org/thread/242194
> Xalan Linkage error : TransformerConfigurationException
> -------------------------------------------------------
>
> Key: WFLY-4174
> URL: https://issues.jboss.org/browse/WFLY-4174
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final
> Environment: Wildfly 8.1 & 8.2-Final
> JDK 1.7.0_45 & 1.7.0_71
> Windows & Linux
> Reporter: Stephen Kay
> Assignee: David Lloyd
> Priority: Critical
>
> Please note that this bug wasn't present on JBoss 7.1 / same WAR artifact
> This is full staktrace from our applicaion.
> 11:13:32,130 SEVERE ch.mitsa.credoc.ui.views.messages.MessagesTable (default task-9) Error getting message payload: : javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:369) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:383) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:418) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:765) rt.jar:1.7.0_71
> at _redirected.TransformerFactory.newTransformer(_TransformerFactory.java:132) jboss-modules.jar:1.3.3.Final
> at ch.mitsa.credoc.format.swift.impl.SwiftFormatter.getPrettyPrintedPayload(SwiftFormatter.java:196)
> at ch.mitsa.credoc.engine.service.OutputService.getPrettyPrintedMessage(OutputService.java:54)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) rt.jar:1.7.0_71
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) rt.jar:1.7.0_71
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) rt.jar:1.7.0_71
> at java.lang.reflect.Method.invoke(Method.java:606) rt.jar:1.7.0_71
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) wildfly-weld-8.2.0.Final.jar:8.2.0.Final
> (...)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4174) Xalan Linkage error : TransformerConfigurationException
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-4174?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-4174:
-----------------------------------
It looks like (on windows at least) this was probably introduced by this commit: https://github.com/wildfly/wildfly/commit/ab3d35ea which re-introduced the defunct "-jaxpmodule" flag (but only to the windows .bat scripts).
> Xalan Linkage error : TransformerConfigurationException
> -------------------------------------------------------
>
> Key: WFLY-4174
> URL: https://issues.jboss.org/browse/WFLY-4174
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final
> Environment: Wildfly 8.1 & 8.2-Final
> JDK 1.7.0_45 & 1.7.0_71
> Windows & Linux
> Reporter: Stephen Kay
> Assignee: David Lloyd
> Priority: Critical
>
> Please note that this bug wasn't present on JBoss 7.1 / same WAR artifact
> This is full staktrace from our applicaion.
> 11:13:32,130 SEVERE ch.mitsa.credoc.ui.views.messages.MessagesTable (default task-9) Error getting message payload: : javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:369) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:383) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:418) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:765) rt.jar:1.7.0_71
> at _redirected.TransformerFactory.newTransformer(_TransformerFactory.java:132) jboss-modules.jar:1.3.3.Final
> at ch.mitsa.credoc.format.swift.impl.SwiftFormatter.getPrettyPrintedPayload(SwiftFormatter.java:196)
> at ch.mitsa.credoc.engine.service.OutputService.getPrettyPrintedMessage(OutputService.java:54)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) rt.jar:1.7.0_71
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) rt.jar:1.7.0_71
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) rt.jar:1.7.0_71
> at java.lang.reflect.Method.invoke(Method.java:606) rt.jar:1.7.0_71
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) wildfly-weld-8.2.0.Final.jar:8.2.0.Final
> (...)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years