March 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-5993) Need to add ProfileService failed deployment tests

by Scott M Stark (JIRA)

Need to add ProfileService failed deployment tests -------------------------------------------------- Key: JBAS-5993 URL: https://jira.jboss.org/jira/browse/JBAS-5993 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: ProfileService Reporter: Scott M Stark Assignee: Scott M Stark Fix For: JBossAS-5.0.0.GA We need to add ProfileService failed deployment tests to validate that the reason for the failure is being propagated back to the ProfileService.DeploymentManager client -- 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

17 years, 4 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-6650) configurable upload dir of a DeploymentRepository

by Emanuel Muckenhuber (JIRA)

configurable upload dir of a DeploymentRepository ------------------------------------------------- Key: JBAS-6650 URL: https://jira.jboss.org/jira/browse/JBAS-6650 Project: JBoss Application Server Issue Type: Feature Request 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 The path of a DeploymentRepository to upload content should be configurable. -- 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

17 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-6649) enable distribution of deployment contents to the deployers dir.

by Emanuel Muckenhuber (JIRA)

enable distribution of deployment contents to the deployers dir. ---------------------------------------------------------------- Key: JBAS-6649 URL: https://jira.jboss.org/jira/browse/JBAS-6649 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 The only available target profile for DeploymentManager is the applications profile. This should be changed to allow distribution of deployment contents to all registered DeploymentRepositories. -- 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

17 years, 4 months

1
1
0 / 0

[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

17 years, 4 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

17 years, 4 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

17 years, 4 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

17 years, 4 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

17 years, 4 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

17 years, 4 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

17 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2009