[JBoss JIRA] Updated: (JBAS-3194) Proxies for HAServiceMBeanSupport subclass unbound across cluster when any instance undeployed
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3194?page=all ]
Brian Stansberry updated JBAS-3194:
-----------------------------------
Fix Version/s: JBossAS-4.0.5.CR1
(was: JBossAS-4.0.6.CR1)
This is already fixed for 4.0.5.CR1; need to resolve a test failure on HEAD before closing.
> Proxies for HAServiceMBeanSupport subclass unbound across cluster when any instance undeployed
> ----------------------------------------------------------------------------------------------
>
> Key: JBAS-3194
> URL: http://jira.jboss.com/jira/browse/JBAS-3194
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: JBossAS-4.0.4.CR2, JBossAS-4.0.3 SP1, JBossAS-4.0.3 Final
> Reporter: Brian Stansberry
> Assigned To: Brian Stansberry
> Fix For: JBossAS-4.0.5.CR1
>
>
> ProxyFactoryHA registers a JMX notification listener for the shutdown of its target service and removes the proxy from JNDI on receipt of the notification. HAServiceMBeanSupport broadcasts its JMX notifications *across the cluster*. The effect of this is that the ProxyFactoryHA on all cluster nodes will receive the notification when any one instance of the service undeploys. The effect is all proxies across the cluster are removed from JNDI.
> Test org.jboss.test.cluster.jmx.test.HAInvokerUnitTestCase demonstrates this.
> Following is a deliberately created stacktrace showing the origin of a notification that caused an invalid removal from JNDI:
> 2006-05-08 01:51:53,703 DEBUG [org.jboss.proxy.generic.ProxyFactoryHA] About to stop: disabling remote access to mbean jboss.test:service=HAService
> 2006-05-08 01:51:53,703 DEBUG [org.jboss.proxy.generic.ProxyFactoryHA] java.lang.Exception: stacktrace
> java.lang.Exception: stacktrace
> at org.jboss.proxy.generic.ProxyFactoryHA.containerIsAboutToStop(ProxyFactoryHA.java:169)
> at org.jboss.proxy.generic.ProxyFactoryHA$StateChangeListener.handleNotification(ProxyFactoryHA.java:231)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.notification.NotificationListenerProxy.invoke(NotificationListenerProxy.java:153)
> at $Proxy10.handleNotification(Unknown Source)
> at org.jboss.mx.util.JBossNotificationBroadcasterSupport.handleNotification(JBossNotificationBroadcasterSupport.java:127)
> at org.jboss.mx.util.JBossNotificationBroadcasterSupport.sendNotification(JBossNotificationBroadcasterSupport.java:110)
> at org.jboss.ha.jmx.HAServiceMBeanSupport._receiveRemoteNotification(HAServiceMBeanSupport.java:393)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330)
> at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:1017)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:597)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:497)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:320)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:725)
> at org.jgroups.JChannel.up(JChannel.java:1041)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:377)
> at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:393)
> at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:141)
> at org.jgroups.stack.UpHandler.run(Protocol.java:60)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 11 months
[JBoss JIRA] Updated: (JBAS-2283) Custom header based authentication
by Anil Saldhana (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2283?page=all ]
Anil Saldhana updated JBAS-2283:
--------------------------------
Summary: Custom header based authentication (was: Look into custom header based authentication)
> Custom header based authentication
> ----------------------------------
>
> Key: JBAS-2283
> URL: http://jira.jboss.com/jira/browse/JBAS-2283
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Tomcat) service, Security
> Reporter: Scott M Stark
> Assigned To: Anil Saldhana
> Fix For: JBossAS-5.0.0.CR1, JBossAS-4.0.5.GA
>
> Attachments: B19006.pdf, B19008v2.pdf, B19013.pdf
>
>
> We have been getting requests for custom authentication methods based around prorpietary headers/logic. The following attachments describe the oracle COREid product.
> B19006.pdf - high level overview of how the product works
> B19008v2.pdf - details of authentication protocol (p. 85 - 92)
> B19013.pdf - documentation about API
> Likely the most important part is assuming a user is who the HTTP_OBLIX_UID header says they are. The COREid server and the firewall should protect the server from unauthorized access.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 11 months
[JBoss JIRA] Updated: (JBAS-2283) Look into custom header based authentication
by Anil Saldhana (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2283?page=all ]
Anil Saldhana updated JBAS-2283:
--------------------------------
Fix Version/s: JBossAS-4.0.5.GA
JBossAS-5.0.0.CR1
(was: JBossAS-5.0.1.CR1)
I have a HeaderAuthenticator that has cleared SiteMinder and RSA Cleartrust. It will not take me time to make this into a generic header based authenticator.
> Look into custom header based authentication
> --------------------------------------------
>
> Key: JBAS-2283
> URL: http://jira.jboss.com/jira/browse/JBAS-2283
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Tomcat) service, Security
> Reporter: Scott M Stark
> Assigned To: Anil Saldhana
> Fix For: JBossAS-5.0.0.CR1, JBossAS-4.0.5.GA
>
> Attachments: B19006.pdf, B19008v2.pdf, B19013.pdf
>
>
> We have been getting requests for custom authentication methods based around prorpietary headers/logic. The following attachments describe the oracle COREid product.
> B19006.pdf - high level overview of how the product works
> B19008v2.pdf - details of authentication protocol (p. 85 - 92)
> B19013.pdf - documentation about API
> Likely the most important part is assuming a user is who the HTTP_OBLIX_UID header says they are. The COREid server and the firewall should protect the server from unauthorized access.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 11 months
[JBoss JIRA] Updated: (JBAS-3194) Proxies for HAServiceMBeanSupport subclass unbound across cluster when any instance undeployed
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3194?page=all ]
Brian Stansberry updated JBAS-3194:
-----------------------------------
Assignee: Brian Stansberry (was: Scott Marlow)
Scott, feeling a bit under the weather so want something not to intense to do today, so I'm going to fix this one :)
> Proxies for HAServiceMBeanSupport subclass unbound across cluster when any instance undeployed
> ----------------------------------------------------------------------------------------------
>
> Key: JBAS-3194
> URL: http://jira.jboss.com/jira/browse/JBAS-3194
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: JBossAS-4.0.4.CR2, JBossAS-4.0.3 SP1, JBossAS-4.0.3 Final
> Reporter: Brian Stansberry
> Assigned To: Brian Stansberry
> Fix For: JBossAS-4.0.6.CR1
>
>
> ProxyFactoryHA registers a JMX notification listener for the shutdown of its target service and removes the proxy from JNDI on receipt of the notification. HAServiceMBeanSupport broadcasts its JMX notifications *across the cluster*. The effect of this is that the ProxyFactoryHA on all cluster nodes will receive the notification when any one instance of the service undeploys. The effect is all proxies across the cluster are removed from JNDI.
> Test org.jboss.test.cluster.jmx.test.HAInvokerUnitTestCase demonstrates this.
> Following is a deliberately created stacktrace showing the origin of a notification that caused an invalid removal from JNDI:
> 2006-05-08 01:51:53,703 DEBUG [org.jboss.proxy.generic.ProxyFactoryHA] About to stop: disabling remote access to mbean jboss.test:service=HAService
> 2006-05-08 01:51:53,703 DEBUG [org.jboss.proxy.generic.ProxyFactoryHA] java.lang.Exception: stacktrace
> java.lang.Exception: stacktrace
> at org.jboss.proxy.generic.ProxyFactoryHA.containerIsAboutToStop(ProxyFactoryHA.java:169)
> at org.jboss.proxy.generic.ProxyFactoryHA$StateChangeListener.handleNotification(ProxyFactoryHA.java:231)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.notification.NotificationListenerProxy.invoke(NotificationListenerProxy.java:153)
> at $Proxy10.handleNotification(Unknown Source)
> at org.jboss.mx.util.JBossNotificationBroadcasterSupport.handleNotification(JBossNotificationBroadcasterSupport.java:127)
> at org.jboss.mx.util.JBossNotificationBroadcasterSupport.sendNotification(JBossNotificationBroadcasterSupport.java:110)
> at org.jboss.ha.jmx.HAServiceMBeanSupport._receiveRemoteNotification(HAServiceMBeanSupport.java:393)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330)
> at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:1017)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:597)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:497)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:320)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:725)
> at org.jgroups.JChannel.up(JChannel.java:1041)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:377)
> at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:393)
> at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:141)
> at org.jgroups.stack.UpHandler.run(Protocol.java:60)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 11 months
[JBoss JIRA] Created: (JBAS-3545) HASessionState state transfer incorrect for replicated sessions
by Brian Stansberry (JIRA)
HASessionState state transfer incorrect for replicated sessions
---------------------------------------------------------------
Key: JBAS-3545
URL: http://jira.jboss.com/jira/browse/JBAS-3545
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: JBossAS-3.2.8.SP1, JBossAS-3.2.8 Final, JBossAS-4.0.3 SP1, JBossAS-4.0.3 Final, JBossAS-4.0.2 Final, JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-3.2.6 Final, JBossAS-3.2.5 Final
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossAS-4.0.5.CR1
When HASessionStateImpl prepares state for a state transfer, it uses a timestamp check to see whether a bean is overaged before including it in the state. If the bean is overaged it removes it from its replicated cache. (Note that this is a separate and distinct process from the standard SFSB passivation and removal process.)
This algorithm is broken for sessions that are not active on the node preparing the state transfer for two reasons:
1) The transient field used to store the modification timestamp (in PackagedSessionImpl) is initialized as part of its declaration:
protected transient long lastModificationTimeInVM = System.currentTimeMillis ();
This means the value will not be properly initialized when PackagedSessionImpl is deserialized, as is explained at http://forum.java.sun.com/thread.jspa?threadID=584981&messageID=3002515.
2) The lastModificationTimeInVM field is also not updated in the update() method, which is the method that gets called when state updates are replicated from another node.
The effect of this is that when a state transfer is prepared, all remote beans will be removed from the replicated cache of the preparing node. At a minimum this means the bean won't be included in the state transfer; it may have other insidious effects on the preparing node as well.
Fix is to initialize the transient field in the constructor and readObject() and to update it in the update() method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 11 months
[JBoss JIRA] Created: (JBRULES-410) Issues when using the queryResults(). Not returning results as expected.
by Corey Ellis (JIRA)
Issues when using the queryResults(). Not returning results as expected.
-------------------------------------------------------------------------
Key: JBRULES-410
URL: http://jira.jboss.com/jira/browse/JBRULES-410
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Reteoo
Affects Versions: 3.0.3
Environment: Seen in production, but also is reproducable using a simple JBossRules project. Will post the code and rules as apart of the JIRA
Reporter: Corey Ellis
Assigned To: Mark Proctor
When using the queryResults() from the LHS of the rules we are getting a null for the first Fact asserted, and then the query size shows the correct value for the rest of the facts. We observed that this is a problem in the following cases:
1. LHS Fact does not have any constraints -- Event() vs. Event(state == "emit")
2. Multiple queries in the LHS fail -- just returns null results. In order to test this please uncomment query "Total ent1 events" and rule "ENT1 emit with multiple queries"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 11 months
[JBoss JIRA] Created: (JBAS-3558) Service(Proxy) should be transient in ServiceContext
by Anil Saldhana (JIRA)
Service(Proxy) should be transient in ServiceContext
----------------------------------------------------
Key: JBAS-3558
URL: http://jira.jboss.com/jira/browse/JBAS-3558
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMX
Affects Versions: JBossAS-4.0.4.GA, JBossAS-3.2.8.SP1
Reporter: Anil Saldhana
Assigned To: Anil Saldhana
Fix For: JBossAS-4.0.5.CR1, JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2
ObjectName serviceOName = // ObjectName of any service in question
MBeanServerConnection server = getServer();
ObjectName so = ServiceControllerMBean.OBJECT_NAME;
server.invoke(so, "create", new Object[]{serviceOName},
new String[]{"javax.management.ObjectName"});
ServiceContext sc = (ServiceContext)server.invoke(so, "getServiceContext", new Object[]{serviceOName},
new String[]{"javax.management.ObjectName"});
There is non-serializable exception in obtaining ServiceContext because Service within SC should be transient.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 11 months