[JBoss JIRA] (WFLY-958) There's no way to enforce security on an in-vm connection in AS7
by Justin Bertram (JIRA)
[ https://issues.jboss.org/browse/WFLY-958?page=com.atlassian.jira.plugin.s... ]
Justin Bertram updated WFLY-958:
--------------------------------
Description: When AS7 starts org.jboss.as.messaging.jms.JMSService sets up a default security override for in-vm connections. There is no way to disable this override and there should be. (was: When AS7 starts org.jboss.as.messaging.jms.JMSService sets up a default security override for in-vm connections. There is no way to disable this override and there should be.
Note: When securing the default in-vm connection automated XA transaction recovery is a concern. I don't believe there's currently any way to specify credentials for it. We'll likely need a HORNETQ JIRA to take care of that. )
> There's no way to enforce security on an in-vm connection in AS7
> ----------------------------------------------------------------
>
> Key: WFLY-958
> URL: https://issues.jboss.org/browse/WFLY-958
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMS
> Reporter: Justin Bertram
> Assignee: Andy Taylor
>
> When AS7 starts org.jboss.as.messaging.jms.JMSService sets up a default security override for in-vm connections. There is no way to disable this override and there should be.
--
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
10 years, 11 months
[JBoss JIRA] (DROOLS-336) Property Reactivity fails on phreak
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-336?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-336:
------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1029071|https://bugzilla.redhat.com/show_bug.cgi?id=1029071] from ON_QA to VERIFIED
> Property Reactivity fails on phreak
> -----------------------------------
>
> Key: DROOLS-336
> URL: https://issues.jboss.org/browse/DROOLS-336
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.0.1.Final
>
>
> In LeftInputAdapterNode a modifyByPass happens, for a sink that has not been reached before. So it thinks it's new, and thus propagates as an insert
> The real bug comes in doInsertObject method. It creates a child LT here, even though once it enters doInsertSegmentMemory the mask intersect fails. This leaves a child LT, that is not propagated. Next time update is called, as the LT is there it thinks it's a modify and propagates as a modify - but it never reached the beta node or the LeftMemory, and thus the memory corruption.
--
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
10 years, 11 months
[JBoss JIRA] (WFLY-808) LdapExtLoginModule fails with follow referral
by Peter Skopek (JIRA)
[ https://issues.jboss.org/browse/WFLY-808?page=com.atlassian.jira.plugin.s... ]
Peter Skopek closed WFLY-808.
-----------------------------
Resolution: Done
Closing this issue as test cases mentioned here are working fine and BZ https://bugzilla.redhat.com/show_bug.cgi?id=901138 is also closed.
> LdapExtLoginModule fails with follow referral
> ---------------------------------------------
>
> Key: WFLY-808
> URL: https://issues.jboss.org/browse/WFLY-808
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Environment: Probably not relevant, but Win 7 64, tried on jdk 6 and 7 64-bit.
> Reporter: Alexander Torstling
> Assignee: Peter Skopek
> Labels: activedirectory, authentication, authorization, ldap, objectfactory, references
> Attachments: ldap-referral-test.zip, secured-webapp.war
>
>
> We connect to AD with LdapExtLoginModule. It so happens that AD keeps references to some external trees (such as "DomainDnsZones" and "ForestDnsZones") in the root of the LDAP tree. So when you configure LdapExtLoginModule to search any root, it will hit these referrals.
> This normally fails with a standard
> {code}
> javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
> {code}
> . This is not the whole story, though. If you enable the module option
> {code}<module-option name="throwValidateError" value="true"/>{code}
> , you get a more complete stack trace:
> {code}
> 09:18:14,724 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (http--127.0.0.1-8080-2) Login failure: javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:270) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0]
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784) [rt.jar:1.7.0]
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0]
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0]
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0]
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0]
> at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381) [jbossweb-7.0.13.Final.jar:]
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19) [classes:]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
> Caused by: javax.naming.PartialResultException [Root exception is javax.naming.NotContextException: Cannot create context for: ldap://DomainDnsZones.global.scd.company.com/DC=DomainDnsZones,DC=global,...; remaining name 'dc=global,dc=scd,dc=company,dc=com']
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:242) [rt.jar:1.7.0]
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:189) [rt.jar:1.7.0]
> at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:534) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:445) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> ... 29 more
> Caused by: javax.naming.NotContextException: Cannot create context for: ldap://DomainDnsZones.global.scd.company.com/DC=DomainDnsZones,DC=global,...; remaining name 'dc=global,dc=scd,dc=company,dc=com'
> at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:141) [rt.jar:1.7.0]
> at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150) [rt.jar:1.7.0]
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:357) [rt.jar:1.7.0]
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:226) [rt.jar:1.7.0]
> ... 34 more
> {code}
> When debugging this error, I concluded that the culprit is that ObjectFactoryBuilder doesn't resolve the reference correctly. getObjectInstance returns the reference instead of resolving it at the following location:
> {code}
> at org.jboss.as.naming.context.ObjectFactoryBuilder.getObjectInstance(ObjectFactoryBuilder.java:87)
> at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:300)
> at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:111)
> at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150)
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:357)
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:226)
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:189)
> at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:534)
> at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:445)
> at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312)
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
> at java.security.AccessController.doPrivileged(AccessController.java:-1)
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
> at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214)
> at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381)
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19)
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
> at java.lang.Thread.run(Thread.java:722)
> {code}
> The relevant bit of code is:
> {code}
> public Object getObjectInstance(final Object ref, final Name name, final Context nameCtx, final Hashtable<?, ?> environment) throws Exception {
> final ClassLoader classLoader = SecurityActions.getContextClassLoader();
> if(classLoader == null) {
> return ref;
> }
> {code}
> So this bit of code doesn't resolve the ref it the context classloader is null. Instead of aborting, it returns the ref unresolved. LdapReferralContext gets very confused when NamingManager doesn't resolve the reference, and throws the aforementioned NotContextException.
> When debugging where the context classloader is set to null I found the following location:
> {code}
> http--127.0.0.1-8080-2@12911 daemon, prio=5, in group 'main', status: 'RUNNING'
> at java.lang.Thread.setContextClassLoader(Thread.java:1480)
> at org.jboss.security.auth.spi.SecurityActions$2.run(SecurityActions.java:59)
> at org.jboss.security.auth.spi.SecurityActions$2.run(SecurityActions.java:56)
> at java.security.AccessController.doPrivileged(AccessController.java:-1)
> at org.jboss.security.auth.spi.SecurityActions.setContextClassLoader(SecurityActions.java:55)
> at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:435)
> at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312)
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
> at java.security.AccessController.doPrivileged(AccessController.java:-1)
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
> at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214)
> at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381)
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19)
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
> at java.lang.Thread.run(Thread.java:722)
> {code}
> Unfortunately I haven't been able to find the source code for this location. But it is clear that LdapExtLoginModule does set the context classloader to null in validatePassword. I haven't come up with any way of avoiding this.
> While trying to circumvent this bug I tried to avoid following the AD referral. This doesn't seem to be possible, though. When setting "java.naming.referral" to "ignore", you would expect that the login would succeed. But as documented at http://docs.oracle.com/javase/jndi/tutorial/ldap/referral/jndi.html , some LDAP implementations might still throw a PartialResultException. This is indeed what I get:
> {code}
> Caused by: javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'dc=global,dc=scd,dc=company,dc=com'
> {code}
> Spring points this out at http://static.springsource.org/spring-ldap/site/apidocs/org/springframewo... and has a way of supressing these exceptions: "ignorePartialResultException".
> With JBoss lacking this, I am stuck between a rock and a hard place. I cannot enable referrals due to the null context class loader bug, and I cannot disable them due to the PartialResultException bug.
> So I would call this one a blocker. Any suggestions are greatly appreciated, as we are stuck upgrading to AS 7. This is a regression, by the way, since "follow" used to work on AS 5.1.0.GA which we are upgrading from.
> The only way of avoiding this problem that I've found is to narrow the tree which you search through in AD in such a way that you avoid hitting the referrals at all. There are a couple of related bugs and forum posts (see for instance https://issues.jboss.org/browse/AS7-2085), but I don't think any of them really nailed the problem down. It's pretty tricky since you don't even get a relevant stacktrace unless you enable "throwValidateError".
> Thanks
--
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
10 years, 11 months
[JBoss JIRA] (JBJCA-1126) ConnectorTestCase should import both packages
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-1126:
--------------------------------------
Summary: ConnectorTestCase should import both packages
Key: JBJCA-1126
URL: https://issues.jboss.org/browse/JBJCA-1126
Project: IronJacamar
Issue Type: Bug
Components: Code Generator
Affects Versions: 1.1.2.Final
Reporter: Jesper Pedersen
Assignee: Jeff Zhang
Fix For: 1.1.3.Final
The ConnectorTestCase should use the addPackage method to add the classes for the resource adapter.
In case of bi-directional resource adapters both the top-level package plus the inflow package should be added
--
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
10 years, 11 months
[JBoss JIRA] (WFLY-2643) JBOSS_LOG_DIR is checked but not used to set jboss.server.log.dir
by Stian Lund (JIRA)
[ https://issues.jboss.org/browse/WFLY-2643?page=com.atlassian.jira.plugin.... ]
Stian Lund updated WFLY-2643:
-----------------------------
Description:
In standalone/domain start scripts (standalone.sh/bat) the value of environment variable JBOSS_LOG_DIR is checked for:
{code}
# determine the default log dir, if not set
if [ "x$JBOSS_LOG_DIR" = "x" ]; then
JBOSS_LOG_DIR="$JBOSS_BASE_DIR/log"
fi
{code}
However, this is not actually used to set the value of Java property jboss.server.log.dir.
{code}
-Djboss.home.dir="$JBOSS_HOME"
-Djboss.server.base.dir="$JBOSS_BASE_DIR"
"$SERVER_OPTS"
{code}
(It should be set at the same place)
This leads Jboss/Wildfly/EAP to assume the default value of $JBOSS_BASE_DIR/log.
This is a problem for those who want to override the location of the server.log files.
was:
In standalone/domain start scripts (standalone.sh/bat) the value of environment variable JBOSS_LOG_DIR is checked for:
{code}
# determine the default log dir, if not set
if [ "x$JBOSS_LOG_DIR" = "x" ]; then
JBOSS_LOG_DIR="$JBOSS_BASE_DIR/log"
fi
{code}
However, this is not actually used to set the value of Java property jboss.server.log.dir.
{code}
-Djboss.home.dir=\"$JBOSS_HOME\" \
-Djboss.server.base.dir=\"$JBOSS_BASE_DIR\" \
"$SERVER_OPTS"
{code}
(It should be set at the same place)
This leads Jboss/Wildfly/EAP to assume the default value of $JBOSS_BASE_DIR/log.
This is a problem for those who want to override the location of the server.log files.
> JBOSS_LOG_DIR is checked but not used to set jboss.server.log.dir
> -----------------------------------------------------------------
>
> Key: WFLY-2643
> URL: https://issues.jboss.org/browse/WFLY-2643
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging, Server
> Affects Versions: JBoss AS7 7.1.1.Final, 8.0.0.Beta1
> Environment: All
> Reporter: Stian Lund
> Assignee: James Perkins
> Labels: jbossas, logging, wildfly
>
> In standalone/domain start scripts (standalone.sh/bat) the value of environment variable JBOSS_LOG_DIR is checked for:
> {code}
> # determine the default log dir, if not set
> if [ "x$JBOSS_LOG_DIR" = "x" ]; then
> JBOSS_LOG_DIR="$JBOSS_BASE_DIR/log"
> fi
> {code}
> However, this is not actually used to set the value of Java property jboss.server.log.dir.
> {code}
> -Djboss.home.dir="$JBOSS_HOME"
> -Djboss.server.base.dir="$JBOSS_BASE_DIR"
> "$SERVER_OPTS"
> {code}
> (It should be set at the same place)
> This leads Jboss/Wildfly/EAP to assume the default value of $JBOSS_BASE_DIR/log.
> This is a problem for those who want to override the location of the server.log files.
--
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
10 years, 11 months
[JBoss JIRA] (WFLY-2643) JBOSS_LOG_DIR is checked but not used to set jboss.server.log.dir
by Stian Lund (JIRA)
[ https://issues.jboss.org/browse/WFLY-2643?page=com.atlassian.jira.plugin.... ]
Stian Lund updated WFLY-2643:
-----------------------------
Workaround Description:
Workaround:
Set value of jboss.server.log.dir in standalone/domain.conf which is sourced by the startup script (value JBOSS_CONF)
{code}
JAVA_OPTS="$JAVA_OPTS -Djboss.server.log.dir=$JBOSS_LOG_DIR"
{code}
was:
Workaround:
Set value of jboss.server.log.dir in standalone/domain.conf which is sourced by the startup script (value JBOSS_CONF)
JAVA_OPTS="$JAVA_OPTS -Djboss.server.log.dir=$JBOSS_LOG_DIR"
> JBOSS_LOG_DIR is checked but not used to set jboss.server.log.dir
> -----------------------------------------------------------------
>
> Key: WFLY-2643
> URL: https://issues.jboss.org/browse/WFLY-2643
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging, Server
> Affects Versions: JBoss AS7 7.1.1.Final, 8.0.0.Beta1
> Environment: All
> Reporter: Stian Lund
> Assignee: James Perkins
> Labels: jbossas, logging, wildfly
>
> In standalone/domain start scripts (standalone.sh/bat) the value of environment variable JBOSS_LOG_DIR is checked for:
> {code}
> # determine the default log dir, if not set
> if [ "x$JBOSS_LOG_DIR" = "x" ]; then
> JBOSS_LOG_DIR="$JBOSS_BASE_DIR/log"
> fi
> {code}
> However, this is not actually used to set the value of Java property jboss.server.log.dir.
> {code}
> -Djboss.home.dir=\"$JBOSS_HOME\" \
> -Djboss.server.base.dir=\"$JBOSS_BASE_DIR\" \
> "$SERVER_OPTS"
> {code}
> (It should be set at the same place)
> This leads Jboss/Wildfly/EAP to assume the default value of $JBOSS_BASE_DIR/log.
> This is a problem for those who want to override the location of the server.log files.
--
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
10 years, 11 months
[JBoss JIRA] (WFLY-2638) jboss-javaee6-webapp on WildFly Beta2-SNAPSHOT - JSF fails with ViewExpiredException
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/WFLY-2638?page=com.atlassian.jira.plugin.... ]
Lukáš Fryč updated WFLY-2638:
-----------------------------
Summary: jboss-javaee6-webapp on WildFly Beta2-SNAPSHOT - JSF fails with ViewExpiredException (was: jboss-javaee6-quickstarts on WildFly Beta2-SNAPSHOT - JSF fails with ViewExpiredException)
> jboss-javaee6-webapp on WildFly Beta2-SNAPSHOT - JSF fails with ViewExpiredException
> ------------------------------------------------------------------------------------
>
> Key: WFLY-2638
> URL: https://issues.jboss.org/browse/WFLY-2638
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.CR1
> Environment: WildFly Beta2-SNAPSHOT (revision 95aa9c0ad64a2feccfc97ccb2c1194e9ac83872d )
> Reporter: Lukáš Fryč
> Assignee: Farah Juma
> Attachments: jboss-javaee6-webapp.war
>
>
> Steps to reproduce:
> 1. create a {{jboss-javaee6-webapp}} from [archetype|https://github.com/jboss-developer/jboss-eap-archetypes/tree/ma...] or via JBoss Tools Central (Create from scratch > Java EE Web Project)
> 2. navigate browser to application http://localhost:8080/jboss-javaee6-webapp/index.jsf
> 2. do any action leading to postback, such as clicking Register button
> Detailed debug log is here:
> https://gist.github.com/lfryc/53145a9cc5e568e5792e
> Stack trace:
> {code}
> Context Path:/jboss-javaee6-webapp
> Servlet Path:/index.jsf
> Path Info:null
> Query String:null
> Stack Trace
> javax.servlet.ServletException: viewId:/index.jsf - View /index.jsf could not be restored.
> javax.faces.webapp.FacesServlet.service(FacesServlet.java:659)
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87)
> 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:81)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65)
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:238)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:225)
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:71)
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:144)
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:655)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> java.lang.Thread.run(Thread.java:744)
> {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
10 years, 11 months