[JBoss JIRA] (WFLY-8000) Default Elytron realm names are confusing - use same values as Legacy security realms
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-8000?page=com.atlassian.jira.plugin.... ]
Josef Cacek updated WFLY-8000:
------------------------------
Labels: user_experience (was: )
> Default Elytron realm names are confusing - use same values as Legacy security realms
> -------------------------------------------------------------------------------------
>
> Key: WFLY-8000
> URL: https://issues.jboss.org/browse/WFLY-8000
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: user_experience
>
> The default application server profiles now contain Elytron subsystem configured (more in EAP7-543). The subsystem contains 2 properties realms, which copy behavior of security realms in legacy security. They use the same name as the original ones *ApplicationRealm* and *ManagementRealm*:
> {code:xml}
> <properties-realm name="ApplicationRealm">
> <users-properties path="application-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="ApplicationRealm"/>
> <groups-properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
> </properties-realm>
> <properties-realm name="ManagementRealm">
> <users-properties path="mgmt-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="ManagementRealm"/>
> <groups-properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
> </properties-realm>
> {code}
> The new Elytron realms must use different names than legacy ones. Otherwise customers/administrators may think about the Elytron realms as just references to the legacy security.
> *Suggested solution*
> Rename the default Elytron realms to something like *ElytronManagementRealm* or *ManagementElytronRealm*. So the configuration looks like:
> {code:xml}
> <properties-realm name="ApplicationElytronRealm">
> <users-properties path="application-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="ApplicationRealm"/>
> <groups-properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
> </properties-realm>
> <properties-realm name="ManagementElytronRealm">
> <users-properties path="mgmt-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="ManagementRealm"/>
> <groups-properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
> </properties-realm>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (WFLY-8000) Default Elytron realm names are confusing - use same values as Legacy security realms
by Josef Cacek (JIRA)
Josef Cacek created WFLY-8000:
---------------------------------
Summary: Default Elytron realm names are confusing - use same values as Legacy security realms
Key: WFLY-8000
URL: https://issues.jboss.org/browse/WFLY-8000
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Josef Cacek
Assignee: Darran Lofthouse
Priority: Blocker
The default application server profiles now contain Elytron subsystem configured (more in EAP7-543). The subsystem contains 2 properties realms, which copy behavior of security realms in legacy security. They use the same name as the original ones *ApplicationRealm* and *ManagementRealm*:
{code:xml}
<properties-realm name="ApplicationRealm">
<users-properties path="application-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="ApplicationRealm"/>
<groups-properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
</properties-realm>
<properties-realm name="ManagementRealm">
<users-properties path="mgmt-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="ManagementRealm"/>
<groups-properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
</properties-realm>
{code}
The new Elytron realms must use different names than legacy ones. Otherwise customers/administrators may think about the Elytron realms as just references to the legacy security.
*Suggested solution*
Rename the default Elytron realms to something like *ElytronManagementRealm* or *ManagementElytronRealm*. So the configuration looks like:
{code:xml}
<properties-realm name="ApplicationElytronRealm">
<users-properties path="application-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="ApplicationRealm"/>
<groups-properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
</properties-realm>
<properties-realm name="ManagementElytronRealm">
<users-properties path="mgmt-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="ManagementRealm"/>
<groups-properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
</properties-realm>
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (JGRP-2155) Weight loss program
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2155?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2155:
--------------------------------
If you want to create a JAR that doesn't contain tests and demos, you can create your own build.xml or pom.xml file which only includes a subset of the classes in the resulting JAR.
Alternatively, send me a PR for build.xml and/or pom.xml and I'll apply it. Note that it needs to preserve the defaults though and build the entire JAR by default. However, this would enable you to build your own JAR.
Logging is pluggable; you can use any logger you want.
> Weight loss program
> -------------------
>
> Key: JGRP-2155
> URL: https://issues.jboss.org/browse/JGRP-2155
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Yves Cuillerdier
> Assignee: Bela Ban
>
> JGroups jar is quite large and it is sometime desirable to shrink it some way.
> Currently the jar contains unnecessary class (demo, test and perf) and it is not possible to keep the only needed protocols using tools like Proguard (it's like having a server with all ports open).
> My suggestions are:
> h2. Move JGroups' side class
> Demo: Move the {{demo}} package to a maven module.
> Test and perf: Move the test package to the maven test source and generate test-source jars.
> Note that the {{MPerf$MPerfHeader}} must be removed from the {{jg-magic-map.xml}} file.
> h2.
> h2. Make JGroups Proguard compatible
> A classical way to shrink and optimize project is to use the *{{Proguard }}*tools.
> This tool cannot be used for JGroups mainly because of the two configuration files {{jg-magic-map.xml}} and {{jg-protocol-ids.xml}}.
> These two files contain all class files for all possible protocols, even those that are not required by the selected configuration for the project (for example, using {{fast.xml}} does not require {{ENCRYPT}}, {{TUNNEL}} and many more.)
> The problem is that Proguard could not understand these two files and removes all class because there is no entry points.
> One way to solve this may be to create Annotation (for example {{@MagicMap}} and {{@ProtocolIds}}) and remove the two files. These annotations could be searched by the initialization process in the class maintained by the Proguard tools. This should not affect the loading time as all relevant class are in the same package {{org.jgroups.protocols}}.
> This is not enough because some fields are initialized by reflection using hard coded name (for example "{{bind_add}}"). For such fields we need an Annotation like {{@KeepField}} to tell Proguard not to optimize, remove or rename the fields. For example:
> -keepclassmembers class * { @jgroups.annotations.KeepField <fields>; }
> This Annotation may also be used for class where instance are created by reflection (like {{GMS.GmsHeader}}).
> Last we need to specify the entry points for the project configuration else Proguard will still remove all. The xml configuration files (like {{fast.xml}}) should be kept to provide the protocols configuration.
> This is a matter of the Proguard configuration file. For example in a project using{{ fast.xml}}, we should have:
> -keep public class org.jgroups.protocols.UDP.** { *; }
> -keep public class org.jgroups.protocols.PING.** { *; }
> -keep public class org.jgroups.protocols.MERGE3.** { *; }
> -keep public class org.jgroups.protocols.FD_SOCK.** { *; }
> -keep public class org.jgroups.protocols.FD_ALL.** { *; }
> -keep public class org.jgroups.protocols.VERIFY_SUSPECT.** { *; }
> -keep public class org.jgroups.protocols.BARRIER.** { *; }
> -keep public class org.jgroups.protocols.pbcast.NAKACK2.** { *; }
> ... etc
> My 2 cents.
> Yves
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (ELY-680) No log messages comming from Elytron - kerberos
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-680?page=com.atlassian.jira.plugin.sy... ]
Martin Choma reopened ELY-680:
------------------------------
Verification failed.
Please implement reasonable toString() method on logged Objects.
{code:title-server.log}
09:56:25,124 TRACE [org.wildfly.security] (default task-34) Caching GSSContext sun.security.jgss.GSSContextImpl@57e9e7a0
09:56:25,135 TRACE [org.wildfly.security] (default task-35) Sending intermediate challenge: [B@633f813
09:56:25,135 TRACE [org.wildfly.security] (default task-35) Handling SecurityIdentityCallback: identity = org.wildfly.security.auth.server.SecurityIdentity@8f4177d
09:56:25,123 TRACE [org.wildfly.security] (default task-34) Using SpnegoAuthenticationMechanism to authenticate HTTP/localhost.localdomain(a)JBOSS.ORG using the following mechanisms: [[Lorg.ietf.jgss.Oid;@592e12f5]
{code}
> No log messages comming from Elytron - kerberos
> -----------------------------------------------
>
> Key: ELY-680
> URL: https://issues.jboss.org/browse/ELY-680
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
>
> Elytron is missing log messages related to kerberos authentication. These log messages should be added. See JBEAP-6041 for more details.
> I consider to be useful to have TRACE log messages at least in:
> - SpnegoAuthenticationMechanism
> - GSSCredentialSecurityFactory
> If there are more classes involved in kerberos authnetication include them as well.
> Kerberos issues are very specific. So it is very important to have as much trace information as possible. Therefore raising priority to Critical.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (WFLY-7999) JMS client dependencies doesn't contain a default wildfly-config.xml
by Josef Cacek (JIRA)
Josef Cacek created WFLY-7999:
---------------------------------
Summary: JMS client dependencies doesn't contain a default wildfly-config.xml
Key: WFLY-7999
URL: https://issues.jboss.org/browse/WFLY-7999
Project: WildFly
Issue Type: Bug
Components: JMS, Security
Reporter: Josef Cacek
Assignee: Jeff Mesnil
Priority: Critical
Using the {{wildfly-jms-client-bom}} dependency for JMS clients doesn't introduce a default {{wildfly-config.xml}} with Elytron client configuration. As the result, clients are not able to authenticate (e.g. using JBOSS-LOCAL-USER SASL mechanism).
The default configuration in {{wildfly-config.xml}} should allow similar behavior as with legacy security. So the following call should pass:
{code}
ConnectionFactory connectionFactory = (ConnectionFactory) namingContext.lookup("jms/RemoteConnectionFactory");
{code}
Currently the call throws exception:
{code}
SEVERE: Naming problem occured
javax.naming.CommunicationException: WFNAM00018: Failed to connect to remote host [Root exception is javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server are supported]
at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110)
at org.wildfly.naming.client.remote.RemoteContext.lookupNative(RemoteContext.java:91)
at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:78)
at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:64)
at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:123)
at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:113)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.wildfly.security.elytron.demo.JmsClient.main(JmsClient.java:45)
Caused by: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server are supported
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:412)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:239)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:466)
at org.jboss.remoting3.FutureConnection.connect(FutureConnection.java:113)
at org.jboss.remoting3.FutureConnection.init(FutureConnection.java:75)
at org.jboss.remoting3.FutureConnection.get(FutureConnection.java:151)
at org.jboss.remoting3.EndpointImpl.getConnection(EndpointImpl.java:422)
at org.jboss.remoting3.UncloseableEndpoint.getConnection(UncloseableEndpoint.java:57)
at org.jboss.remoting3.Endpoint.getConnection(Endpoint.java:105)
at org.wildfly.naming.client.remote.RemoteNamingProvider.lambda$new$0(RemoteNamingProvider.java:68)
at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentity(RemoteNamingProvider.java:126)
at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:108)
... 7 more
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (WFLY-7998) NPE in org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-7998?page=com.atlassian.jira.plugin.... ]
Alessio Soldano reassigned WFLY-7998:
-------------------------------------
Assignee: Jim Ma (was: Alessio Soldano)
> NPE in org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke
> ---------------------------------------------------------------------------
>
> Key: WFLY-7998
> URL: https://issues.jboss.org/browse/WFLY-7998
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Reporter: David Lloyd
> Assignee: Jim Ma
>
> The NPE is regularly encountered in a build of the {{invocation_integration}} branch. Ask me for more details if this problem cannot be reproduced locally.
> The log message in {{testsuite/integration/ws/target/jbossas/standalone/log/server.log}} is:
> {noformat}
> 2017-01-30 17:23:57,588 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default-workqueue-1) Application {http://www.jboss.org/jbossws/ws-extensions/wsrm}ReliableService#{http://www.jboss.org/jbossws/ws-e
> xtensions/wsrm}writeLogMessage has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault
> at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:162)
> at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:267)
> at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:128)
> at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:232)
> at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:85)
> at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:145)
> at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126)
> at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
> at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:278)
> at org.apache.cxf.ws.addressing.impl.InternalContextUtils$1.run(InternalContextUtils.java:321)
> at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:428)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:353)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:109)
> at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:169)
> at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
> ... 17 more
> {noformat}
> This error is preceded by the following stack trace which might or might not be related:
> {noformat}
> 2017-01-30 17:23:57,460 SEVERE [org.apache.cxf.ws.rm.RMCaptureOutInterceptor] (default task-19) Error persisting message: javax.xml.stream.XMLStreamException: Trying to write END_DOCUMENT when document has no r
> oot (ie. trying to output empty document).
> at com.ctc.wstx.sw.BaseStreamWriter.throwOutputError(BaseStreamWriter.java:1584)
> at com.ctc.wstx.sw.BaseStreamWriter.reportNwfStructure(BaseStreamWriter.java:1613)
> at com.ctc.wstx.sw.BaseStreamWriter._finishDocument(BaseStreamWriter.java:1439)
> at com.ctc.wstx.sw.BaseStreamWriter.close(BaseStreamWriter.java:247)
> at org.apache.cxf.staxutils.DelegatingXMLStreamWriter.close(DelegatingXMLStreamWriter.java:35)
> at org.apache.cxf.ws.rm.CapturingXMLWriter.getOutputStream(CapturingXMLWriter.java:397)
> at org.apache.cxf.ws.rm.RMCaptureOutInterceptor$CaptureEnd.handleMessage(RMCaptureOutInterceptor.java:271)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:83)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:252)
> at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:109)
> at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:218)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 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:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 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 org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1698)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1698)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1698)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1698)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:210)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (WFLY-7995) Packed deployment doesn't work
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7995?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-7995.
----------------------------------
Resolution: Rejected
Please use the forums to ask for help
> Packed deployment doesn't work
> ------------------------------
>
> Key: WFLY-7995
> URL: https://issues.jboss.org/browse/WFLY-7995
> Project: WildFly
> Issue Type: Bug
> Reporter: Ray Lloy BISSIELOU NZAO
> Assignee: Jason Greene
> Priority: Blocker
>
> Hello,
> I am new in Wildfly.
> I try to migrate my application form *JBoss EAP 6* to *wildfly-10.1.0.Final*.
> When I use a compressed archive wilth *JBoss EAP 6*, it works fine. But When I use the same compressed archive with *wildfly-10.1.0.Final*, I can't access to the index.jsp.
> When I look in %JBOSS_HOME%\standalone\tmp\Myapplication.ear.Myapplication.war
> there is nothing, my jsp are not compiled.
> Is there a way to fix it ?
> Thanks in advance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (WFLY-7998) NPE in org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke
by David Lloyd (JIRA)
David Lloyd created WFLY-7998:
---------------------------------
Summary: NPE in org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke
Key: WFLY-7998
URL: https://issues.jboss.org/browse/WFLY-7998
Project: WildFly
Issue Type: Bug
Components: Web Services
Reporter: David Lloyd
Assignee: Alessio Soldano
The NPE is regularly encountered in a build of the {{invocation_integration}} branch. Ask me for more details if this problem cannot be reproduced locally.
The log message in {{testsuite/integration/ws/target/jbossas/standalone/log/server.log}} is:
{noformat}
2017-01-30 17:23:57,588 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default-workqueue-1) Application {http://www.jboss.org/jbossws/ws-extensions/wsrm}ReliableService#{http://www.jboss.org/jbossws/ws-e
xtensions/wsrm}writeLogMessage has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault
at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:162)
at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:267)
at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:128)
at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:232)
at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:85)
at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:145)
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126)
at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:278)
at org.apache.cxf.ws.addressing.impl.InternalContextUtils$1.run(InternalContextUtils.java:321)
at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:428)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:353)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:109)
at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:169)
at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
... 17 more
{noformat}
This error is preceded by the following stack trace which might or might not be related:
{noformat}
2017-01-30 17:23:57,460 SEVERE [org.apache.cxf.ws.rm.RMCaptureOutInterceptor] (default task-19) Error persisting message: javax.xml.stream.XMLStreamException: Trying to write END_DOCUMENT when document has no r
oot (ie. trying to output empty document).
at com.ctc.wstx.sw.BaseStreamWriter.throwOutputError(BaseStreamWriter.java:1584)
at com.ctc.wstx.sw.BaseStreamWriter.reportNwfStructure(BaseStreamWriter.java:1613)
at com.ctc.wstx.sw.BaseStreamWriter._finishDocument(BaseStreamWriter.java:1439)
at com.ctc.wstx.sw.BaseStreamWriter.close(BaseStreamWriter.java:247)
at org.apache.cxf.staxutils.DelegatingXMLStreamWriter.close(DelegatingXMLStreamWriter.java:35)
at org.apache.cxf.ws.rm.CapturingXMLWriter.getOutputStream(CapturingXMLWriter.java:397)
at org.apache.cxf.ws.rm.RMCaptureOutInterceptor$CaptureEnd.handleMessage(RMCaptureOutInterceptor.java:271)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:83)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:252)
at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:109)
at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134)
at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:218)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
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:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
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 org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1698)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1698)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1698)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1698)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:210)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
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)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months