[JBoss JIRA] (JBASMP-52) jboss-as:deploy deploys ear but doesn't deploy contained ejb module
by Matías Blasi (JIRA)
Matías Blasi created JBASMP-52:
----------------------------------
Summary: jboss-as:deploy deploys ear but doesn't deploy contained ejb module
Key: JBASMP-52
URL: https://issues.jboss.org/browse/JBASMP-52
Project: JBoss AS Maven Plugins
Issue Type: Bug
Components: deploy
Affects Versions: 7.4.Final
Environment: Linux hostname 3.7.10-gentoo #1 SMP Fri Aug 30 17:01:59 ART 2013 x86_64 Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz GenuineIntel GNU/Linux
Reporter: Matías Blasi
Assignee: James Perkins
I have a simple ear application (build with maven-ear-plugin).
This application contains just a persistence-unit definition (persistence.xml) and a ejb-module.
The ejb module is another maven build, containing some ejb3, handled with maven-ejb-plugin.
The ear file is correctly built:
myapp.ear
|
+ META-INF/application.xml
+ lib/allmylibs.jar
+ myejb.jar
When trying to deploy the ear with the jboss-as:deploy, the application is deployed (the persistence unit deployment logs in server.log), but no ejb is registered, anyway, no errors in log, and BUILD SUCCESFUL after mvn command.
Finally, an ear file is present under $JBOSS_HOME/standalone/data/content
The strange thing is that if I get that generated ear file, I can succesfully deploy it through the management console, or by copying it to a folder scanned by a deployment-scanner (in both cases the ejbs are correctly deployed)
Nothing found in google! :(
I tried with all the plugin version from 7.1.1 to 7.4.
Also a lot of tries with different maven-ear-plugin and maven-jboss-as-plugin configuration options.... no lucky after two days of work.
Regards,
Matías.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (JBAS-9548) JBoss 5.0 log file is stopped getting updated after a while
by Ramesh Kodali (JIRA)
Ramesh Kodali created JBAS-9548:
-----------------------------------
Summary: JBoss 5.0 log file is stopped getting updated after a while
Key: JBAS-9548
URL: https://issues.jboss.org/browse/JBAS-9548
Project: Application Server 3 4 5 and 6
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: JBossAS-5.0.1.GA
Environment: Java 2.6, JBoss 5.1
Reporter: Ramesh Kodali
Assignee: Alessio Soldano
We are using log back xml to configure application specific log file and copied the log back XML in JBoss class path. After server restarts, JBoss is generating the log files successfully. It was working from some time even in production. Recently we have noticed a weird issue in our dev environment that, application logs are writing in to log file and stopped writing after a while. We have to restart the JBoss to get back the Log files status. This issue seems coming continuously now a days. I would like to know is it some thing related to JBoss or more of environment issue.
Here below the log back configuration we had
<appender name="FILE"
class="ch.qos.logback.core.rolling.RollingFileAppender">
<File>${jboss.server.log.dir}/cbs2.log</File>
<Append>true</Append>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<FileNamePattern>${jboss.server.log.dir}/cbs2.%d{yyyy-MM-dd}.%i.log.gz
</FileNamePattern>
<timeBasedFileNamingAndTriggeringPolicy
class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
<maxFileSize>200MB</maxFileSize>
</timeBasedFileNamingAndTriggeringPolicy>
</rollingPolicy>
<layout class="ch.qos.logback.classic.PatternLayout">
<Pattern>%d{yyyy-MM-dd;HH:mm:ss.SSS} [%thread] %-5level %logger{36} [%M:%L]
[%X{id}->%X{bcId}:%X{userId}:%X{loginId}] - %msg%n</Pattern>
</layout>
</appender>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (WFLY-2208) CLI over HTTP should switch to / be redirected to https automatically.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-2208:
--------------------------------------
Summary: CLI over HTTP should switch to / be redirected to https automatically.
Key: WFLY-2208
URL: https://issues.jboss.org/browse/WFLY-2208
Project: WildFly
Issue Type: Enhancement
Components: CLI, Domain Management
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 8.0.0.Beta1
When using the native interface a TLS upgrade was already automatically in place once a keystore was added to the linked realm.
With the switch to http with an upgrade there is no automatic switch to https.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (WFLY-2207) CLI Unable to connect using https-remoting address.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-2207:
--------------------------------------
Summary: CLI Unable to connect using https-remoting address.
Key: WFLY-2207
URL: https://issues.jboss.org/browse/WFLY-2207
Project: WildFly
Issue Type: Bug
Components: CLI
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Priority: Critical
Fix For: 8.0.0.Beta1
The CLI is failing to connect over https with the following: -
{code}
[disconnected /] connect https-remoting://localhost:9993
The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (DROOLS-194) Add support in KIE to register custom Wagons
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-194?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-194.
--------------------------------
Fix Version/s: 6.0.0.CR5
Resolution: Done
> Add support in KIE to register custom Wagons
> --------------------------------------------
>
> Key: DROOLS-194
> URL: https://issues.jboss.org/browse/DROOLS-194
> Project: Drools
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Kurt Stam
> Assignee: Mario Fusco
> Fix For: 6.0.0.CR5
>
> Attachments: kie-srampwagon.tgz
>
>
> The ManualWagonProvider subclass of Aether in KIE registers the HTTPWagon. It should be possible to add your own Wagon through config our automated machinery when another Wagon is put on the classpath and references in the build/extensions of a MavenProject. To get the SrampWagon to work we used the following code:
> {quote}
> private static class ManualWagonProvider implements WagonProvider {
> public Wagon lookup( String roleHint ) throws Exception {
> if ( "http".equals( roleHint ) ) {
> return new AhcWagon();
> }
> if ( "sramp".equals( roleHint ) ) {
> return new SrampWagon();
> }
> return null;
> }
> public void release( Wagon wagon ) { }
> }
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (DROOLS-194) Add support in KIE to register custom Wagons
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-194?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-194:
----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> Add support in KIE to register custom Wagons
> --------------------------------------------
>
> Key: DROOLS-194
> URL: https://issues.jboss.org/browse/DROOLS-194
> Project: Drools
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Kurt Stam
> Assignee: Mario Fusco
> Attachments: kie-srampwagon.tgz
>
>
> The ManualWagonProvider subclass of Aether in KIE registers the HTTPWagon. It should be possible to add your own Wagon through config our automated machinery when another Wagon is put on the classpath and references in the build/extensions of a MavenProject. To get the SrampWagon to work we used the following code:
> {quote}
> private static class ManualWagonProvider implements WagonProvider {
> public Wagon lookup( String roleHint ) throws Exception {
> if ( "http".equals( roleHint ) ) {
> return new AhcWagon();
> }
> if ( "sramp".equals( roleHint ) ) {
> return new SrampWagon();
> }
> return null;
> }
> public void release( Wagon wagon ) { }
> }
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (WFLY-2200) NoSuchElementException after upgrade from Beta13 to Beta14
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2200?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-2200.
-------------------------------
Resolution: Done
> NoSuchElementException after upgrade from Beta13 to Beta14
> ----------------------------------------------------------
>
> Key: WFLY-2200
> URL: https://issues.jboss.org/browse/WFLY-2200
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Beta1
>
>
> I just switched to a newer WildFly snapshot having Undertow 1.0.0.Beta14. But I'm getting the following stacktrace caused by HttpServletRequestImpl.getParameterNames(). This error didn't happen with 1.0.0.Beta13.
> {code}
> SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-45) Error Rendering View[/index.xhtml]: java.util.NoSuchElementException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929) [rt.jar:1.7.0_40]
> at java.util.HashMap$KeyIterator.next(HashMap.java:960) [rt.jar:1.7.0_40]
> at io.undertow.servlet.spec.HttpServletRequestImpl.getParameterNames(HttpServletRequestImpl.java:605) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at com.sun.faces.context.RequestParameterMap.getEntryIterator(RequestParameterMap.java:126) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.context.BaseContextMap$EntrySet.iterator(BaseContextMap.java:166) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.context.BaseContextMap$BaseSet.size(BaseContextMap.java:154) [jsf-impl-2.1.26.jar:2.1.26]
> at java.util.Collections$UnmodifiableCollection.size(Collections.java:1055) [rt.jar:1.7.0_40]
> at java.util.AbstractMap.size(AbstractMap.java:84) [rt.jar:1.7.0_40]
> at java.util.AbstractMap.isEmpty(AbstractMap.java:93) [rt.jar:1.7.0_40]
> at java.util.Collections$UnmodifiableMap.isEmpty(Collections.java:1336) [rt.jar:1.7.0_40]
> at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:330) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:199) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.util.DevTools.debugHtml(DevTools.java:186) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.tag.ui.UIDebug.writeDebugOutput(UIDebug.java:140) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.tag.ui.UIDebug.encodeBegin(UIDebug.java:122) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1817) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jsf-api-2.1.26.jar:2.1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (WFLY-2200) NoSuchElementException after upgrade from Beta13 to Beta14
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2200?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-2200:
-----------------------------------
Fixed in Undertow Beta 16
> NoSuchElementException after upgrade from Beta13 to Beta14
> ----------------------------------------------------------
>
> Key: WFLY-2200
> URL: https://issues.jboss.org/browse/WFLY-2200
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Beta1
>
>
> I just switched to a newer WildFly snapshot having Undertow 1.0.0.Beta14. But I'm getting the following stacktrace caused by HttpServletRequestImpl.getParameterNames(). This error didn't happen with 1.0.0.Beta13.
> {code}
> SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-45) Error Rendering View[/index.xhtml]: java.util.NoSuchElementException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929) [rt.jar:1.7.0_40]
> at java.util.HashMap$KeyIterator.next(HashMap.java:960) [rt.jar:1.7.0_40]
> at io.undertow.servlet.spec.HttpServletRequestImpl.getParameterNames(HttpServletRequestImpl.java:605) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at com.sun.faces.context.RequestParameterMap.getEntryIterator(RequestParameterMap.java:126) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.context.BaseContextMap$EntrySet.iterator(BaseContextMap.java:166) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.context.BaseContextMap$BaseSet.size(BaseContextMap.java:154) [jsf-impl-2.1.26.jar:2.1.26]
> at java.util.Collections$UnmodifiableCollection.size(Collections.java:1055) [rt.jar:1.7.0_40]
> at java.util.AbstractMap.size(AbstractMap.java:84) [rt.jar:1.7.0_40]
> at java.util.AbstractMap.isEmpty(AbstractMap.java:93) [rt.jar:1.7.0_40]
> at java.util.Collections$UnmodifiableMap.isEmpty(Collections.java:1336) [rt.jar:1.7.0_40]
> at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:330) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:199) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.util.DevTools.debugHtml(DevTools.java:186) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.tag.ui.UIDebug.writeDebugOutput(UIDebug.java:140) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.tag.ui.UIDebug.encodeBegin(UIDebug.java:122) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1817) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jsf-api-2.1.26.jar:2.1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months