March 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBAS-1429) Reauthentication Support

by Gerbrand van Dieijen (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-1429?page=com.atlassian.jira.plug... ] Gerbrand van Dieijen commented on JBAS-1429: -------------------------------------------- Oracle Enterprise edition also has similar functionality. After a connection has been opened, the user can change (see http://www.it-eye.nl/weblog/2005/09/12/oracle-proxy-users-by-example/). Being able to re-authenticate would be very powerful - it would be very nice is this functionality would be added. I tried abuse the validate-connection class to get the same functionality (side effect in the ping database method), however that method does not seem to be called always when a connection is returned. > Reauthentication Support > ------------------------ > > Key: JBAS-1429 > URL: https://jira.jboss.org/jira/browse/JBAS-1429 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JCA service > Affects Versions: JBossAS-4.0.1 Final > Reporter: Andrew Oliver > Assignee: Vicky Kak > > Add support for the reauthentication support (in particular MySQLChangeUser) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-6648) provide different profile implementations

by Emanuel Muckenhuber (JIRA)

provide different profile implementations ----------------------------------------- Key: JBAS-6648 URL: https://jira.jboss.org/jira/browse/JBAS-6648 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: ProfileService Affects Versions: JBossAS-5.1.0.Beta1 Reporter: Emanuel Muckenhuber Assignee: Emanuel Muckenhuber Fix For: JBossAS-5.1.0.CR1 Currently there is only one Profile implementation used, which delegates all actions to a DeploymentRepository. As each profile could have different behavior (e.g. deployment actions over the DeploymentManager, hot-deployment) this should be changed to different implementations for each profile. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBSER-114) Object replacement and resolution doesn't conform to Java serialization

by Ron Sigal (JIRA)

Object replacement and resolution doesn't conform to Java serialization ----------------------------------------------------------------------- Key: JBSER-114 URL: https://jira.jboss.org/jira/browse/JBSER-114 Project: JBoss Serialization Issue Type: Bug Affects Versions: 1.0.3 GA Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 1.1.0 Beta There are two ways in which object replacement and resolution in JBossSerialization doesn't conform to Java serialization. This discussion applies to JBossSerialization as it currently exists on trunk. =============================================================================== First divergence. According to Section 3 "Object Input Classes" (http://java.sun.com/javase/6/docs/platform/serialization/spec/input.html) of the Java Object Serialization Specification, the sequence of replacements while writing an object is: 1. if the class has a writeReplace() method, that method is called, and then 2. if replacement has been enabled by calling ObjectOutputStream.enableReplaceObject(), then ObjectOutputStream.replaceObject() is called. [NOTE that the implementation in java.io.ObjectOutputStream.writeObject0() doesn't seem to conform to the above algorithm: for (;;) { // REMIND: skip this check for strings/arrays? Class repCl; desc = ObjectStreamClass.lookup(cl, true); if (!desc.hasWriteReplaceMethod() || (obj = desc.invokeWriteReplace(obj)) == null || (repCl = obj.getClass()) == cl) { break; } cl = repCl; } if (enableReplace) { Object rep = replaceObject(obj); if (rep != obj && rep != null) { cl = rep.getClass(); desc = ObjectStreamClass.lookup(cl, true); } obj = rep; } In particular, the for loop seems to be divergent from the semantics.] On the other hand, JBossSerialization does the following: 1. if replacement has been enabled, call ObjectOutputStream.replaceObject() [In DataContainer.DataContainerDirectOutput.writeObject()] 2. if the class has a writeReplace() method then keep applying writeReplace() until it returns either (1) null, (2) the object to which it was applied, (3) an object of the same class as the object to which it was applied, or (4) an immutable value. If (1) or (4), write new value and return. 3. if replacement has been enabled, call ObjectOutputStream.replaceObject(). 4. *GOTO* 2. While reading an object in Java serialization, the sequence of replacements is 1. if the class has a readResolve() method, that method is called, and then 2. if replacement has been enabled by calling ObjectInputStream.enableResolveObject(), then ObjectInputStream.resolveObject () is called. On the other hand, JBossSerialization does the following: 1. if replacement has been enabled by calling ObjectInputStream.enableResolveObject(), then ObjectInputStream.resolveObject () is called. 2. if the class has a readResolve() method, that method is called, and then 3. if replacement has been enabled by calling ObjectInputStream.enableResolveObject(), then ObjectInputStream.resolveObject () is called. =============================================================================== Second divergence. The Java serialization spec gives the following steps in serialization: 4. If the object has been previously replaced, as described in Step 8, write the handle of the replacement to the stream and |writeObject| returns. ... 8. a. .... b. ... If the original object was replaced by either one or both steps above, the mapping from the original object to the replacement is recorded for later use in Step 4. Then, Steps 3 through 7 are repeated on the new object. But JBossSerialization does this: * Apply all the replacements * If the replacement object has already been written, write its "handle". The following test will fail in JBossSerialization: ArrayList<Object> testList = new ArrayList<Object>(); testList = Collections.unmodifiableList(testList); marshaller.writeObject(testList); marshaller.writeObject(testList); assertSame(unmarshaller.readObject(), unmarshaller.readObject()); The assertion will fail because Collections.unmodifiableList() returns an instance of static class UnmodifiableRandomAccessList<E> extends UnmodifiableList<E> implements RandomAccess { private Object writeReplace() { return new UnmodifiableList<E>(list); } } JBossSerialization applies UnmodifiableRandomAccessList.writeReplace() during each call to marshaller.writeObject(), so two different copies of testList get written. But in Java serialization, the second call would see that the object has already been written and a handle would get written. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1110) InvokerLocator.getParameters() should not return null

by Ron Sigal (JIRA)

InvokerLocator.getParameters() should not return null ----------------------------------------------------- Key: JBREM-1110 URL: https://jira.jboss.org/jira/browse/JBREM-1110 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP11, 2.5.0.SP2 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.5.0.SP3 (Flounder), 2.2.2.SP12 Currently, org.jboss.remoting.InvokerLocator.getParameters() will return null if the URL has no parameters. It's safer to return an empty Map than null. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1081) Fix NPE in ServerInvokerCallbackHandler

by Ron Sigal (JIRA)

Fix NPE in ServerInvokerCallbackHandler ---------------------------------------- Key: JBREM-1081 URL: https://jira.jboss.org/jira/browse/JBREM-1081 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) When org.jboss.remoting.callback.ServerInvokerCallback is shut down by a call to ServerInvokerCallbackHandler.destroy(), the variables callBackClient and callbackStore are set to null. If ServerInvokerCallbackHandler.handleCallback() is called subsequently (which can happen if destroy() is called by ServerInvokerCallbackHandler.handleConnectionException() and the application has not yet been informed about a connection failure), then, since callbackClient == null, it looks like pull callbacks are configured, but, since callbackStore == null, a NullPointerException is thrown in ServerInvokerCallbackHandler.persistCallback(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1552) Duplicated messages on Failover when using NullPersistence

by Clebert Suconic (JIRA)

Duplicated messages on Failover when using NullPersistence ---------------------------------------------------------- Key: JBMESSAGING-1552 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1552 Project: JBoss Messaging Issue Type: Bug Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.0.0 Beta To replicate this failure, change AutomaticFailoverWithDiscoveryTest to use NullPersistence, and run testFailover in loop Leave AutomaticFailoverWithDiscoveryTest using NullPersistence after this is done. @Override protected void setUp() throws Exception { super.setUp(); + setupGroupServers(false, "bc1", 5432, groupAddress, groupPort); - setupGroupServers(true, "bc1", 5432, groupAddress, groupPort); } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1784) Implement tx propagation for ejb3-endpoint

by Andrew Lee Rubinger (JIRA)

Implement tx propagation for ejb3-endpoint ------------------------------------------ Key: EJBTHREE-1784 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1784 Project: EJB 3.0 Issue Type: Sub-task Components: endpoint Reporter: Andrew Lee Rubinger -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1783) Implement security propagation for ejb3-endpoint

by Andrew Lee Rubinger (JIRA)

Implement security propagation for ejb3-endpoint ------------------------------------------------ Key: EJBTHREE-1783 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1783 Project: EJB 3.0 Issue Type: Sub-task Components: endpoint Reporter: Andrew Lee Rubinger -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-3019) Add support for CRL validation to the certificate based login modules

by Jeff Medina (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-3019?page=com.atlassian.jira.plug... ] Jeff Medina commented on JBAS-3019: ----------------------------------- Ditto for this support. JBoss has a new foot in the door at a major government organization, but this and future projects may need to move to another platform if this is not supportable. > Add support for CRL validation to the certificate based login modules > --------------------------------------------------------------------- > > Key: JBAS-3019 > URL: https://jira.jboss.org/jira/browse/JBAS-3019 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Security > Reporter: Scott M Stark > Assignee: Anil Saldhana > > We need to add support for validating certificates against certificate revocation lists (CRLs). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Moved: (JBAS-6645) BeanMetaDataICF - ClassCastException and NPE when deploying WAR

by Shelly McGowan (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-6645?page=com.atlassian.jira.plug... ] Shelly McGowan moved JBQA-2177 to JBAS-6645: -------------------------------------------- Project: JBoss Application Server (was: JBoss QA) Key: JBAS-6645 (was: JBQA-2177) Component/s: ProfileService (was: JBoss AS General) Affects Version/s: (was: JBoss EAP 5.0) Security: Public Assignee: Shelly McGowan (was: Michael Harvey) > BeanMetaDataICF - ClassCastException and NPE when deploying WAR > --------------------------------------------------------------- > > Key: JBAS-6645 > URL: https://jira.jboss.org/jira/browse/JBAS-6645 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: ProfileService > Environment: JBoss AS 5.1.0 CR1 > Reporter: Ondrej Žižka > Assignee: Shelly McGowan > Attachments: ClassCastException.txt > > > During WAR deployment in EmbJopr tests, server's log is full of CCE's and NPE's: > 2009-03-20 01:17:16,534 DEBUG [org.jboss.deployers.plugins.managed.BeanMetaDataICF] (ResourceContainer.invoker.daemon-2) Failed to get property value for bean: org.jboss.security.plugins.SecurityConfig, property: mbeanServer > java.lang.ClassCastException: org.jboss.metatype.api.values.ArrayValueSupport > at org.jboss.metatype.api.types.ArrayMetaType.isValue(ArrayMetaType.java:360) > at org.jboss.metatype.api.values.CompositeValueSupport.set(CompositeValueSupport.java:164) > at org.jboss.metatype.plugins.values.DefaultMetaValueFactory.createCompositeValue(DefaultMetaValueFactory.java:497) > at org.jboss.metatype.plugins.values.DefaultMetaValueFactory.internalCreate(DefaultMetaValueFactory.java:1099) > at org.jboss.metatype.plugins.values.DefaultMetaValueFactory.create(DefaultMetaValueFactory.java:552) > at org.jboss.managed.plugins.factory.AbstractInstanceClassFactory.getNonManagedObjectValue(AbstractInstanceClassFactory.java:339) > at org.jboss.managed.plugins.factory.AbstractInstanceClassFactory.getValue(AbstractInstanceClassFactory.java:260) > at org.jboss.deployers.plugins.managed.BeanMetaDataICF.getValue(BeanMetaDataICF.java:179) > at org.jboss.deployers.plugins.managed.BeanMetaDataICF.getValue(BeanMetaDataICF.java:49) > ... > 2009-03-20 01:17:16,535 DEBUG [org.jboss.deployers.plugins.managed.BeanMetaDataICF] (ResourceContainer.invoker.daemon-2) Failed to get property value for bean: org.jboss.security.plugins.SecurityConfig, property: defaultLoginConfig > java.lang.NullPointerException > at org.jboss.system.ServiceMBeanSupport.getDeploymentInfo(ServiceMBeanSupport.java:176) > at sun.reflect.GeneratedMethodAccessor768.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59) > at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150) > at org.jboss.beans.info.plugins.DefaultPropertyInfo.get(DefaultPropertyInfo.java:133) > at org.jboss.beans.info.plugins.BeanInfoUtil.getNestedTarget(BeanInfoUtil.java:78) > ... > At least, they make log messy when looking for causes of other problems. > Detailed log contents in the attachment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2009