[JBoss JIRA] Created: (JBAOP-492) Duplicate _getAdvisor
by Flavia Rainone (JIRA)
Duplicate _getAdvisor
---------------------
Key: JBAOP-492
URL: http://jira.jboss.com/jira/browse/JBAOP-492
Project: JBoss AOP
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.CR1
Reporter: Flavia Rainone
Users are getting the following error message:
AOP Instrumentor failed to transform com.radware.insite.model.trafficredirection.farm.profile.FarmProfile
_$$_javassist_233
16:09:12,066 ERROR [STDERR] javassist.bytecode.DuplicateMemberException: duplicate method: _getAdvis
or in com.radware.insite.model.trafficre
This bug has been reproduced when using Hibernate with JBoss AOP. Refer to the forum link for more information.
--
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
18 years, 6 months
[JBoss JIRA] Created: (JBAS-4434) Create tests of file locking in the deploy dir
by Brian Stansberry (JIRA)
Create tests of file locking in the deploy dir
----------------------------------------------
Key: JBAS-4434
URL: http://jira.jboss.com/jira/browse/JBAS-4434
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Test Suite
Reporter: Brian Stansberry
Need simple tests where different sorts of deployments are copied to deploy, allowed to deploy, and then deleted. Intent is to prove that the file in the deploy dir can be deleted; i.e. the deployment process doesn't create a file lock.
Most AS tests today do deployments via the RMIAdaptor, an approach that doesn't detect file lock issues.
See JBAS--4415 and EJBTHREE-969 for an example of where this broke down. The FarmService tests have to use a 'copy file to farm dir' approach, so they detected a file lock issue. But this kind of problem should be directly tested so it's easier to know when problems like EJBTHREE-969 creep in. Also the FarmService test only deploys one jar; if by chance it had been a war instead of an ejb jar, the problem would not have been detected, since the JBossWeb deployer would have handled the war before accepts() was called on the Ejb3Deployer.
--
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
18 years, 6 months
[JBoss JIRA] Created: (JBREM-698) Update Remoting Marshaller/UnMarshallers to implement PreferredStreamMarshaller/PreferredStreamUnMarshaller interfaces.
by Ron Sigal (JIRA)
Update Remoting Marshaller/UnMarshallers to implement PreferredStreamMarshaller/PreferredStreamUnMarshaller interfaces.
-----------------------------------------------------------------------------------------------------------------------
Key: JBREM-698
URL: http://jira.jboss.com/jira/browse/JBREM-698
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 2.2.0.Beta2 (Bluto)
Reporter: Ron Sigal
Assigned To: Ron Sigal
Fix For: 2.2.0.Beta2 (Bluto)
In response to JBREM-692 the org.jboss.remoting.marshal.PreferredStreamMarshaller and org.jboss.remoting.marshal.PreferredStreamUnMarshaller interfaces were introduced, and org.jboss.remoting.marshal.serializable.SerializableMarshaller and org.jboss.remoting.marshal.serializable.SerializableUnMarshaller were modified to implement them. In particular, they implement a getMarshallingStream() method which returns an object stream that can be cached and reused by the transport layer.
Now, the other Remoting marshallers (http, compressing, encrypting) should also be made to implement those interfaces.
--
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
18 years, 6 months
[JBoss JIRA] Created: (JBREM-764) Wire version should be configurable per client or server
by Ron Sigal (JIRA)
Wire version should be configurable per client or server
--------------------------------------------------------
Key: JBREM-764
URL: http://jira.jboss.com/jira/browse/JBREM-764
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 2.4.0.Beta1 (Pinto)
Reporter: Ron Sigal
Assigned To: Ron Sigal
Fix For: 2.4.0.Beta1 (Pinto)
Currently org.jboss.remoting.Version looks to the system property "jboss.remoting.version" to determine the value to return for Version.getDefaultVersion(), and the transports refer to Version.getDefaultVersion(). This means that all clients and servers in a JVM use the same version.
It would be preferable to allow the wire version to configurable as a parameter to each client and server.
--
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
18 years, 6 months