[JBoss JIRA] (WFLY-4147) WildFly full feature pack references unresolved artifact
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4147?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-4147.
----------------------------------
Fix Version/s: 9.0.0.Alpha1
Resolution: Done
> WildFly full feature pack references unresolved artifact
> --------------------------------------------------------
>
> Key: WFLY-4147
> URL: https://issues.jboss.org/browse/WFLY-4147
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Affects Versions: 9.0.0.Alpha1
> Reporter: Stan Silvert
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Alpha1
>
>
> I have a server-provisioning.xml outside of the WildFly build. It looks like this:
> {code:xml}
> <server-provisioning xmlns="urn:wildfly:server-provisioning:1.0">
> <feature-packs>
> <feature-pack groupId="org.wildfly" artifactId="wildfly-feature-pack" version="${project.version}"/>
> </feature-packs>
> </server-provisioning>
> {code}
> When I build, I get:
> {noformat}
> [ERROR] Failed to execute goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha6:build (server-provisioning) on project wildfly-build: Execution ser
> ver-provisioning of goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha6:build failed: java.lang.RuntimeException: java.lang.RuntimeException: fai
> led to resolve artifact org.wildfly:wildfly-client-all:jar:9.0.0.Alpha1: Failure to find org.wildfly:wildfly-client-all:jar:9.0.0.Alpha1 in http://repository.jboss.org/ne
> xus/content/groups/public/ was cached in the local repository, resolution will not be reattempted until the update interval of jboss-public-repository-group has elapsed o
> r updates are forced -> [Help 1]
> {noformat}
> The problem is that wildfly-client-all is not pushed to the Maven repo. This will only work if wildfly-client-all is already in your local repo.
> Looks like wildfly-client-all simply should not be referenced in the feature pack.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month
[JBoss JIRA] (WFLY-4147) WildFly full feature pack references unresolved artifact
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4147?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4147:
--------------------------------------
I have released the wildfly-client-all artefact.
> WildFly full feature pack references unresolved artifact
> --------------------------------------------------------
>
> Key: WFLY-4147
> URL: https://issues.jboss.org/browse/WFLY-4147
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Affects Versions: 9.0.0.Alpha1
> Reporter: Stan Silvert
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Alpha1
>
>
> I have a server-provisioning.xml outside of the WildFly build. It looks like this:
> {code:xml}
> <server-provisioning xmlns="urn:wildfly:server-provisioning:1.0">
> <feature-packs>
> <feature-pack groupId="org.wildfly" artifactId="wildfly-feature-pack" version="${project.version}"/>
> </feature-packs>
> </server-provisioning>
> {code}
> When I build, I get:
> {noformat}
> [ERROR] Failed to execute goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha6:build (server-provisioning) on project wildfly-build: Execution ser
> ver-provisioning of goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha6:build failed: java.lang.RuntimeException: java.lang.RuntimeException: fai
> led to resolve artifact org.wildfly:wildfly-client-all:jar:9.0.0.Alpha1: Failure to find org.wildfly:wildfly-client-all:jar:9.0.0.Alpha1 in http://repository.jboss.org/ne
> xus/content/groups/public/ was cached in the local repository, resolution will not be reattempted until the update interval of jboss-public-repository-group has elapsed o
> r updates are forced -> [Help 1]
> {noformat}
> The problem is that wildfly-client-all is not pushed to the Maven repo. This will only work if wildfly-client-all is already in your local repo.
> Looks like wildfly-client-all simply should not be referenced in the feature pack.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month
[JBoss JIRA] (WFLY-4043) Cannot load custom login module
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4043?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-4043:
----------------------------------------
Have you asked about this on the forums? Setting up a security domain with a RealmDirect login-module and then having the security-realm use that JAAS security domain seems circular to me.
I understand why there could be an issue here -- the quickstart counts on the fact that LoginContext will use the TCCL to load the login module class, and when the EJB call is made, the TCCL is the deployment's classloader, so the class is visible. It doesn't surprise me that the deployment classloader is not the TCCL when other call patterns are used.
The basic solution to that would be to package the login module code in a module in the $WILDFLY_HOME/modules dir and use the "login-module" element's "module" attribute to specify the name of the module. But I'm not sure if you really want to package the login module class in the deployment, or if that's just something you're doing because the quickstart did it that way.
> Cannot load custom login module
> -------------------------------
>
> Key: WFLY-4043
> URL: https://issues.jboss.org/browse/WFLY-4043
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.1.0.Final
> Environment: Java 1.8.0_25
> Reporter: Rostyslav Smirnov
> Assignee: Jason Greene
>
> When security realm authentication is configured to use JAAS domain, it is not possible to use custom login module, because there is no loader present for deployed classes. LoginContext attempts to load the login module class and fails with ClassNotFoundException.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month
[JBoss JIRA] (WFLY-1077) JDK ORB Subsystem
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-1077?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski commented on WFLY-1077:
--------------------------------------
Transaction testsuite integration tests:
I have checked part of transaction testsuite which is responsible for checking transaction propagation and recovery: TxPropagationCrashRecoveryTestCase, JMSCrashRecoveryTestCase, JMSLrcoCrashRecoveryTestCase tests. I have run those test on narayana 5.0.3 branch with JBTM-2255 fix merged in the following configurations:
wildfly<->wildfly
eap<->wildfly
wildfly<->eap
In each of those cases all tests are passed.
> JDK ORB Subsystem
> -----------------
>
> Key: WFLY-1077
> URL: https://issues.jboss.org/browse/WFLY-1077
> Project: WildFly
> Issue Type: Feature Request
> Components: IIOP
> Reporter: Dimitris Andreadis
> Assignee: Tomasz Adamski
>
> Implement a JDK ORB subsystem that can act as a replacement for the JacORB subsystem.
> AFAIK, most/all JDK ORBs are based on the Sun ORB.
> Ideally the 2 ORBs (JDK & JacORB) would be both supported in case we need to go through a transition period, or we need to support a particular interop scenario for which interop communication has issues.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month
[JBoss JIRA] (WFLY-1077) JDK ORB Subsystem
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-1077?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski commented on WFLY-1077:
--------------------------------------
JBoss EAP (Jacorb) <-> Wildfly (IIOP-OpenJDK) compatibility test 2
Configuration:
Web application consisting of secure servlet and transactional EJB deployed on server A.
EAR with transaction EJB deployed on server B.
Execution:
1. User opens web browser and authenicates using basic logging.
2. Bean on server A authenticates Principal.
3. Bean on server A starts JTS transaction.
4. Bean on server A invokes remotely (using iiop) bean on server B.
5. Bean on server B authenicates Principal.
6. Bean on server B writes data to mock XAResource.
7. 2 phase commit protocol starts.
8. Byteman script kill server B during prepare.
9. Checks are made to assure that transaction has been rolled back on both servers.
Result:
There was a problem with reference narrowing which works differently in JacORB and Openjdk ORB.
After fix to narrow problem is made tests in jboss-eap=A;wildfly=B and jboss-eap=B;wildfly=A are passed - transaction is rolled back on both servers.
>From interoperability point of view it was important to check that IOR which is stored and used during recovery to construct object reference between two different ORB instances work correctly - it does.
> JDK ORB Subsystem
> -----------------
>
> Key: WFLY-1077
> URL: https://issues.jboss.org/browse/WFLY-1077
> Project: WildFly
> Issue Type: Feature Request
> Components: IIOP
> Reporter: Dimitris Andreadis
> Assignee: Tomasz Adamski
>
> Implement a JDK ORB subsystem that can act as a replacement for the JacORB subsystem.
> AFAIK, most/all JDK ORBs are based on the Sun ORB.
> Ideally the 2 ORBs (JDK & JacORB) would be both supported in case we need to go through a transition period, or we need to support a particular interop scenario for which interop communication has issues.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month
[JBoss JIRA] (WFCORE-443) Domain directory-grouping should group directories by server name when set to by-server
by James Perkins (JIRA)
James Perkins created WFCORE-443:
------------------------------------
Summary: Domain directory-grouping should group directories by server name when set to by-server
Key: WFCORE-443
URL: https://issues.jboss.org/browse/WFCORE-443
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: James Perkins
Assignee: James Perkins
Currently if the {{/host=master/directory-grouping=by-server}} is set the same directory will be used for all servers if the {{jboss.server.xxx.dir}} is overridden. For example of the {{jboss.server.log.dir}} is overridden all servers in the group write to the same {{server.log}} file. They should be in {{$jboss.server.log.dir/server-name/}} directory.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month
[JBoss JIRA] (WFLY-4126) java.lang.ExceptionInInitializerError when invoking BIRT service
by Chezy Palani (JIRA)
[ https://issues.jboss.org/browse/WFLY-4126?page=com.atlassian.jira.plugin.... ]
Chezy Palani commented on WFLY-4126:
------------------------------------
No, we are not using any custom ExpressionFactory.
> java.lang.ExceptionInInitializerError when invoking BIRT service
> ----------------------------------------------------------------
>
> Key: WFLY-4126
> URL: https://issues.jboss.org/browse/WFLY-4126
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Windows 7 and JDK 1.8
> Reporter: Chezy Palani
> Assignee: Stuart Douglas
> Attachments: server.log.2014-11-25
>
>
> There was no error during the deployment of the Application. Even hitting landing page works fine. When our service is invoked, we get this exception.
> Context Path:
> /actuatejavacomponent
> Servlet Path:
> /iv
> Path Info:
> null
> Query String:
> __report=%2fPublic%2fBIRT%20and%20BIRT%20Studio%20Examples%2fCustomer%20Dashboard%2erptdocument&closex=true&__vp=workgroup&showBanner=true&showBreadCrumb=false&locale=en_US
> Stack Trace
> javax.servlet.ServletException: java.lang.ExceptionInInitializerError
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:198)
> io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:279)
> com.actuate.iv.presentation.aggregation.IVBaseFragment.service(IVBaseFragment.java:261)
> com.actuate.iv.servlet.IVHttpDispatcher.handleRequest(IVHttpDispatcher.java:144)
> com.actuate.iv.servlet.IVServlet.doGet(IVServlet.java:261)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month
[JBoss JIRA] (WFLY-4043) Cannot load custom login module
by Rostyslav Smirnov (JIRA)
[ https://issues.jboss.org/browse/WFLY-4043?page=com.atlassian.jira.plugin.... ]
Rostyslav Smirnov commented on WFLY-4043:
-----------------------------------------
Login module is configured via [https://github.com/wildfly/quickstart/blob/master/ejb-security-plus/confi...]:
<security-domain name="quickstart-domain" cache-type="default">
<authentication>
<login-module name="DelegationLoginModule" code="org.jboss.as.quickstarts.ejb_security_plus.SaslPlusLoginModule" flag="optional">
<module-option name="password-stacking" value="useFirstPass"/>
</login-module>
<login-module code="RealmDirect" flag="required">
<module-option name="password-stacking" value="useFirstPass"/>
</login-module>
</authentication>
</security-domain>
> Cannot load custom login module
> -------------------------------
>
> Key: WFLY-4043
> URL: https://issues.jboss.org/browse/WFLY-4043
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.1.0.Final
> Environment: Java 1.8.0_25
> Reporter: Rostyslav Smirnov
> Assignee: Jason Greene
>
> When security realm authentication is configured to use JAAS domain, it is not possible to use custom login module, because there is no loader present for deployed classes. LoginContext attempts to load the login module class and fails with ClassNotFoundException.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month
[JBoss JIRA] (WFLY-4126) java.lang.ExceptionInInitializerError when invoking BIRT service
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4126?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4126:
--------------------------------------
Are you deploying a custom ExpressionFactory implementation in your app somewhere? I think something is going wrong with expression factory creation somehow.
> java.lang.ExceptionInInitializerError when invoking BIRT service
> ----------------------------------------------------------------
>
> Key: WFLY-4126
> URL: https://issues.jboss.org/browse/WFLY-4126
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Windows 7 and JDK 1.8
> Reporter: Chezy Palani
> Assignee: Stuart Douglas
> Attachments: server.log.2014-11-25
>
>
> There was no error during the deployment of the Application. Even hitting landing page works fine. When our service is invoked, we get this exception.
> Context Path:
> /actuatejavacomponent
> Servlet Path:
> /iv
> Path Info:
> null
> Query String:
> __report=%2fPublic%2fBIRT%20and%20BIRT%20Studio%20Examples%2fCustomer%20Dashboard%2erptdocument&closex=true&__vp=workgroup&showBanner=true&showBreadCrumb=false&locale=en_US
> Stack Trace
> javax.servlet.ServletException: java.lang.ExceptionInInitializerError
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:198)
> io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:279)
> com.actuate.iv.presentation.aggregation.IVBaseFragment.service(IVBaseFragment.java:261)
> com.actuate.iv.servlet.IVHttpDispatcher.handleRequest(IVHttpDispatcher.java:144)
> com.actuate.iv.servlet.IVServlet.doGet(IVServlet.java:261)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month