[JBoss JIRA] (WFLY-1686) Use HAL release stream version number in console footer
by Harald Pehl (JIRA)
[ https://issues.jboss.org/browse/WFLY-1686?page=com.atlassian.jira.plugin.... ]
Harald Pehl updated WFLY-1686:
------------------------------
Description:
Currently the version number of the Core Console is displayed in the footer of the Admin Console. This should be changed to the version number of the HAL Release Stream. There can be more than one HAL Release Stream based on one Core Console Version:
{code}
Core Console 1.5.4.Final --> HAL Release Stream 1.5.4.Final
--> HAL Release Stream 1.5.5.Final
{code}
was:
Currently the version number of the Core Console is displayed in the footer of the Admin Console. This should be changed to the version number of the HAL Release Stream. There can be more than one HAL Release Stream based on one Core Console Version:
{code}
Core Console 1.6.3.Final --> HAL Release Stream 1.6.3.1.Final
--> HAL Release Stream 1.6.3.2.Final
{code}
> Use HAL release stream version number in console footer
> -------------------------------------------------------
>
> Key: WFLY-1686
> URL: https://issues.jboss.org/browse/WFLY-1686
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Console
> Reporter: Harald Pehl
> Assignee: Harald Pehl
>
> Currently the version number of the Core Console is displayed in the footer of the Admin Console. This should be changed to the version number of the HAL Release Stream. There can be more than one HAL Release Stream based on one Core Console Version:
> {code}
> Core Console 1.5.4.Final --> HAL Release Stream 1.5.4.Final
> --> HAL Release Stream 1.5.5.Final
> {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] (SECURITY-746) EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/SECURITY-746?page=com.atlassian.jira.plug... ]
arjan tijms updated SECURITY-746:
---------------------------------
Description:
After a user has successfully authenticated with JASPIC it's not possible to access any method in a secured EJB bean, irrespective of the actual security constraints.
The problem is that when an EJB is "secured" an extra interceptor is added to the chain: {{org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor}}.
This interceptor calls {{org.jboss.as.security.service.SimpleSecurityManager.push}}, which tries to establish a new stacked security context by attempting a login to a JAAS login module associated with the security domain.
However, when the caller authenticated via a JASPIC auth module, there isn't necessarily such a JAAS login module (the JASPIC auth module is not required to call a JAAS login module, and even if it did it may not be the JAAS login module JBoss knows about).
The problematic part in {{SimpleSecurityManager}}:
{code}
public void push(final String securityDomain, final String runAs, final String runAsPrincipal, final Set<String> extraRoles) {
boolean contextPushed = false;
boolean securityContextEstablished = false;
final SecurityContext previous = SecurityContextAssociation.getSecurityContext();
try {
contexts.push(previous);
contextPushed = true;
SecurityContext current = establishSecurityContext(securityDomain);
securityContextEstablished = true;
if (previous != null) {
current.setSubjectInfo(previous.getSubjectInfo());
current.setIncomingRunAs(previous.getOutgoingRunAs());
}
RunAs currentRunAs = current.getIncomingRunAs();
boolean trusted = currentRunAs != null && currentRunAs instanceof RunAsIdentity;
if (trusted == false) {
boolean authenticated = false;
if (SecurityActions.remotingContextIsSet()) {
// ...
}
// If we have a trusted identity no need for a re-auth.
if (authenticated == false) {
// THIS WILL EVENTUALLY ATTEMPT A JAAS LOGIN WHICH FAILS
authenticated = authenticate(current, null);
}
{code}
The (condensed) stack that will lead to an exception is the following:
{noformat}
javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(Principal, Object)
org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(Principal, Object, Subject)
org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(Principal, Object, Subject)
org.jboss.as.security.service.SimpleSecurityManager.authenticate(SecurityContext, Subject)
org.jboss.as.security.service.SimpleSecurityManager.push(String, String, String, Set<String>)
org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor(SecurityContextInterceptorHolder)
{noformat}
Since the {{SimpleSecurityManager}} is already doing a check to see if the call is remote or not, I wonder if it could not simply accept the existing security context as-is for local calls (not even start a new context) or just consider the existing security context as trusted for local calls just like a {{RunAS}} identity.
Note that this depends on SECURITY-744 and SECURITY-745, since otherwise there is no valid security context at all.
was:
After a user has successfully authenticated with JASPIC it's not possible to access any method in a secured EJB bean, irrespective of the actual security constraints.
The problem is that when an EJB is "secured" an extra interceptor is added to the chain: {{org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor}}.
This interceptor calls {{org.jboss.as.security.service.SimpleSecurityManager.push}}, which tries to establish a new stacked security context by attempting a login to a JAAS login module associated with the security domain.
However, when the caller authenticated via a JASPIC auth module, there isn't necessarily such a JAAS login module (the JASPIC auth module is not required to call a JAAS login module, and even if it did it may not be the JAAS login module JBoss knows about).
The problematic part in {{SimpleSecurityManager}}:
{code}
public void push(final String securityDomain, final String runAs, final String runAsPrincipal, final Set<String> extraRoles) {
boolean contextPushed = false;
boolean securityContextEstablished = false;
final SecurityContext previous = SecurityContextAssociation.getSecurityContext();
try {
contexts.push(previous);
contextPushed = true;
SecurityContext current = establishSecurityContext(securityDomain);
securityContextEstablished = true;
if (previous != null) {
current.setSubjectInfo(previous.getSubjectInfo());
current.setIncomingRunAs(previous.getOutgoingRunAs());
}
RunAs currentRunAs = current.getIncomingRunAs();
boolean trusted = currentRunAs != null && currentRunAs instanceof RunAsIdentity;
if (trusted == false) {
boolean authenticated = false;
if (SecurityActions.remotingContextIsSet()) {
// ...
}
// If we have a trusted identity no need for a re-auth.
if (authenticated == false) {
// THIS WILL EVENTUALLY ATTEMPT A JAAS LOGIN WHICH FAILS
authenticated = authenticate(current, null);
}
{code}
The (condensed) stack that will lead to an exception is the following:
{noformat}
javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(Principal, Object)
org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(Principal, Object, Subject)
org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(Principal, Object, Subject)
org.jboss.as.security.service.SimpleSecurityManager.authenticate(SecurityContext, Subject)
org.jboss.as.security.service.SimpleSecurityManager.push(String, String, String, Set<String>)
org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor(SecurityContextInterceptorHolder)
{noformat}
Since the {{SimpleSecurityManager}} is already doing a check to see if the call is remote or not, I wonder if it could not simply accept the existing security context as-is for local calls (not even start a new context) or just consider the existing security context as trusted for local calls just like a {{RunAS}} identity.
> EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
> ------------------------------------------------------------------------------------------------
>
> Key: SECURITY-746
> URL: https://issues.jboss.org/browse/SECURITY-746
> Project: PicketBox
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: arjan tijms
> Assignee: Anil Saldhana
> Labels: authentication, ejb, jaspi, jaspic, security, security-context
>
> After a user has successfully authenticated with JASPIC it's not possible to access any method in a secured EJB bean, irrespective of the actual security constraints.
> The problem is that when an EJB is "secured" an extra interceptor is added to the chain: {{org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor}}.
> This interceptor calls {{org.jboss.as.security.service.SimpleSecurityManager.push}}, which tries to establish a new stacked security context by attempting a login to a JAAS login module associated with the security domain.
> However, when the caller authenticated via a JASPIC auth module, there isn't necessarily such a JAAS login module (the JASPIC auth module is not required to call a JAAS login module, and even if it did it may not be the JAAS login module JBoss knows about).
> The problematic part in {{SimpleSecurityManager}}:
> {code}
> public void push(final String securityDomain, final String runAs, final String runAsPrincipal, final Set<String> extraRoles) {
> boolean contextPushed = false;
> boolean securityContextEstablished = false;
> final SecurityContext previous = SecurityContextAssociation.getSecurityContext();
> try {
> contexts.push(previous);
> contextPushed = true;
> SecurityContext current = establishSecurityContext(securityDomain);
> securityContextEstablished = true;
> if (previous != null) {
> current.setSubjectInfo(previous.getSubjectInfo());
> current.setIncomingRunAs(previous.getOutgoingRunAs());
> }
> RunAs currentRunAs = current.getIncomingRunAs();
> boolean trusted = currentRunAs != null && currentRunAs instanceof RunAsIdentity;
> if (trusted == false) {
>
> boolean authenticated = false;
> if (SecurityActions.remotingContextIsSet()) {
> // ...
> }
> // If we have a trusted identity no need for a re-auth.
> if (authenticated == false) {
> // THIS WILL EVENTUALLY ATTEMPT A JAAS LOGIN WHICH FAILS
> authenticated = authenticate(current, null);
> }
> {code}
> The (condensed) stack that will lead to an exception is the following:
> {noformat}
> javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
> org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(Principal, Object)
> org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(Principal, Object, Subject)
> org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(Principal, Object, Subject)
> org.jboss.as.security.service.SimpleSecurityManager.authenticate(SecurityContext, Subject)
> org.jboss.as.security.service.SimpleSecurityManager.push(String, String, String, Set<String>)
> org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor(SecurityContextInterceptorHolder)
> {noformat}
> Since the {{SimpleSecurityManager}} is already doing a check to see if the call is remote or not, I wonder if it could not simply accept the existing security context as-is for local calls (not even start a new context) or just consider the existing security context as trusted for local calls just like a {{RunAS}} identity.
> Note that this depends on SECURITY-744 and SECURITY-745, since otherwise there is no valid security context at all.
--
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] (SECURITY-746) EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
by arjan tijms (JIRA)
arjan tijms created SECURITY-746:
------------------------------------
Summary: EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
Key: SECURITY-746
URL: https://issues.jboss.org/browse/SECURITY-746
Project: PicketBox
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: arjan tijms
Assignee: Anil Saldhana
After a user has successfully authenticated with JASPIC it's not possible to access any method in a secured EJB bean, irrespective of the actual security constraints.
The problem is that when an EJB is "secured" an extra interceptor is added to the chain: {{org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor}}.
This interceptor calls {{org.jboss.as.security.service.SimpleSecurityManager.push}}, which tries to establish a new stacked security context by attempting a login to a JAAS login module associated with the security domain.
However, when the caller authenticated via a JASPIC auth module, there isn't necessarily such a JAAS login module (the JASPIC auth module is not required to call a JAAS login module, and even if it did it may not be the JAAS login module JBoss knows about).
The problematic part in {{SimpleSecurityManager}}:
{code}
public void push(final String securityDomain, final String runAs, final String runAsPrincipal, final Set<String> extraRoles) {
boolean contextPushed = false;
boolean securityContextEstablished = false;
final SecurityContext previous = SecurityContextAssociation.getSecurityContext();
try {
contexts.push(previous);
contextPushed = true;
SecurityContext current = establishSecurityContext(securityDomain);
securityContextEstablished = true;
if (previous != null) {
current.setSubjectInfo(previous.getSubjectInfo());
current.setIncomingRunAs(previous.getOutgoingRunAs());
}
RunAs currentRunAs = current.getIncomingRunAs();
boolean trusted = currentRunAs != null && currentRunAs instanceof RunAsIdentity;
if (trusted == false) {
boolean authenticated = false;
if (SecurityActions.remotingContextIsSet()) {
// ...
}
// If we have a trusted identity no need for a re-auth.
if (authenticated == false) {
// THIS WILL EVENTUALLY ATTEMPT A JAAS LOGIN WHICH FAILS
authenticated = authenticate(current, null);
}
{code}
The (condensed) stack that will lead to an exception is the following:
{noformat}
javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(Principal, Object)
org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(Principal, Object, Subject)
org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(Principal, Object, Subject)
org.jboss.as.security.service.SimpleSecurityManager.authenticate(SecurityContext, Subject)
org.jboss.as.security.service.SimpleSecurityManager.push(String, String, String, Set<String>)
org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor(SecurityContextInterceptorHolder)
{noformat}
Since the {{SimpleSecurityManager}} is already doing a check to see if the call is remote or not, I wonder if it could not simply accept the existing security context as-is for local calls (not even start a new context) or just consider the existing security context as trusted for local calls just like a {{RunAS}} identity.
--
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-1406) Hibernate cannot process package-info.java any more
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1406?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-1406:
------------------------------------------
I just re-build Hibernate-ORM 4.3.0.Beta3, made the small change below in PackageInfoArchiveEntryHandler.java, replaced hibernate-entitymanager-4.3.0.Beta3.jar in WildFly:
the issue is gone.
Original line 71:
{code}
.replace( separatorChar, '.' );
{code}
New line 71:
{code}
.replace( '/', '.' );
{code}
But now I've definitely to leave for vacation.
> Hibernate cannot process package-info.java any more
> ---------------------------------------------------
>
> Key: WFLY-1406
> URL: https://issues.jboss.org/browse/WFLY-1406
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Alpha2
> Reporter: Juergen Zimmermann
> Attachments: javap.log, server.log, server.log.zip, shop2.war, tar.log
>
>
> I tried the snapshot which contains Hibernate 4.3.0.Beta2. However, package-info.java files are causing problems. For instance, the package de.shop.artikelverwaltung.domain has a package-info.java which causes a NoClassDefFoundError:
> "IllegalName: de/shop/artikelverwaltung/domain.package-info". Please see the stacktrace below.
> Here is an example for package-info.java which was working with WildFly 8.0.0.Alpha1:
> @XmlAccessorType(FIELD)
> @Vetoed
> package de.shop.artikelverwaltung.domain;
> import static javax.xml.bind.annotation.XmlAccessType.FIELD;
> import javax.enterprise.inject.Vetoed;
> import javax.xml.bind.annotation.XmlAccessorType;
> The stacktrace:
> ...
> 09:29:53,880 WARN [org.jboss.modules] Failed to define class de/shop/artikelverwaltung/domain.package-info in Module "deployment.shop2.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link de/shop/artikelverwaltung/domain/package-info (Module "deployment.shop2.war:main" from Service Module Loader)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:427) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:260) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:75) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:526) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:188) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader.findClass(ClassLoaderServiceImpl.java:218) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:423) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356) [rt.jar:1.7.0_21]
> at org.hibernate.annotations.common.util.ReflectHelper.classForName(ReflectHelper.java:160) [hibernate-commons-annotations-4.0.2.Final.jar:4.0.2.Final]
> at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.packageForName(JavaReflectionManager.java:121) [hibernate-commons-annotations-4.0.2.Final.jar:4.0.2.Final]
> at org.hibernate.cfg.AnnotationBinder.bindPackage(AnnotationBinder.java:262) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.cfg.Configuration.addPackage(Configuration.java:792) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildHibernateConfiguration(EntityManagerFactoryBuilderImpl.java:1174) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:839) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory(HibernatePersistenceProvider.java:142) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:213) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.access$800(PersistenceUnitServiceImpl.java:58) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:107) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.lang.NoClassDefFoundError: IllegalName: de/shop/artikelverwaltung/domain.package-info
> at java.lang.ClassLoader.preDefineClass(ClassLoader.java:646) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:785) [rt.jar:1.7.0_21]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:344) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:422) [jboss-modules.jar:1.2.0.Final]
> ... 28 more
--
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] (LOGMGR-58) Handler rollback gets null instance reference if prepare are invoked
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-58?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on LOGMGR-58:
-----------------------------------------------
pkremens(a)redhat.com made a comment on [bug 975559|https://bugzilla.redhat.com/show_bug.cgi?id=975559]
Verified on EAP 6.1.1 ER4
> Handler rollback gets null instance reference if prepare are invoked
> --------------------------------------------------------------------
>
> Key: LOGMGR-58
> URL: https://issues.jboss.org/browse/LOGMGR-58
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 1.4.2.Final, 1.5.0.Beta1, 2.0.0.Beta1
>
>
> When a forget/rollback is executed after a prepare the instance has already been removed from the refs. The reference should be held so that it can added back to the refs.
> The least evasive solution is to not invoke the {{applyPostCreate()}} in the prepare. This will require examination of all implementations to make sure values are set, but references are not removed in this phase.
> The other option would be to add a commit step only invoked from the commit phase where references could be removed.
--
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] (LOGMGR-58) Handler rollback gets null instance reference if prepare are invoked
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-58?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on LOGMGR-58:
-----------------------------------------------
pkremens(a)redhat.com changed the Status of [bug 975559|https://bugzilla.redhat.com/show_bug.cgi?id=975559] from ON_QA to VERIFIED
> Handler rollback gets null instance reference if prepare are invoked
> --------------------------------------------------------------------
>
> Key: LOGMGR-58
> URL: https://issues.jboss.org/browse/LOGMGR-58
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 1.4.2.Final, 1.5.0.Beta1, 2.0.0.Beta1
>
>
> When a forget/rollback is executed after a prepare the instance has already been removed from the refs. The reference should be held so that it can added back to the refs.
> The least evasive solution is to not invoke the {{applyPostCreate()}} in the prepare. This will require examination of all implementations to make sure values are set, but references are not removed in this phase.
> The other option would be to add a commit step only invoked from the commit phase where references could be removed.
--
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