[JBoss JIRA] Created: (JBMESSAGING-1453) ClientAOPStackLoader needs privileged block to get TCL
by Anil Saldhana (JIRA)
ClientAOPStackLoader needs privileged block to get TCL
------------------------------------------------------
Key: JBMESSAGING-1453
URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1453
Project: JBoss Messaging
Issue Type: Sub-task
Reporter: Anil Saldhana
Assignee: Clebert Suconic
================================
java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
at java.security.AccessController.checkPermission(AccessController.java:427)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.Thread.getContextClassLoader(Thread.java:1276)
at org.jboss.jms.client.ClientAOPStackLoader.load(ClientAOPStackLoader.java:67)
at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:192)
at org.jboss.jms.client.JBossConnectionFactory.createQueueConnection(JBossConnectionFactory.java:101)
at org.jboss.jms.client.JBossConnectionFactory.createQueueConnection(JBossConnectionFactory.java:95)
at org.jboss.test.cts.jms.MsgSender.init(MsgSender.java:62)
at org.jboss.test.cts.jms.MsgSender.sendMsg(MsgSender.java:94)
at org.jboss.test.cts.ejb.CtsBmpBean.sendMsg(CtsBmpBean.java:664)
at org.jboss.test.cts.ejb.CtsBmpBean.setEntityContext(CtsBmpBean.java:512)
=====================================================
You need a priv block in ClientAOPStackLoader where you get TCL
--
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, 8 months
[JBoss JIRA] Created: (JBREM-1026) Add service metadata
by David Lloyd (JIRA)
Add service metadata
--------------------
Key: JBREM-1026
URL: https://jira.jboss.org/jira/browse/JBREM-1026
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Components: r3 api
Reporter: David Lloyd
Fix For: 3.0.0-M3
A RequestHandlerSource (aka a forwarded service) needs methods to query static metadata, such as:
1) The presence or absence of ordering guarantees across the total path
2) Security information about the total path (encryption strength for example)
3) Path information (like a traceroute, for cost as well as diagnostic information; could include link cost, transport type & version, etc)
4) Possibly authentication information about the total path
It should be possible to add new metadata types later on without interfering with backwards compatibility. So lack of a given metadata type must be considered to be possibly indicative of an older version along the path.
--
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, 8 months
[JBoss JIRA] Created: (JBAS-5908) ClientUserTransactionObjectFactory is inefficient
by Adrian Brock (JIRA)
ClientUserTransactionObjectFactory is inefficient
-------------------------------------------------
Key: JBAS-5908
URL: https://jira.jboss.org/jira/browse/JBAS-5908
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Transaction Manager (JBossTM)
Affects Versions: JBossAS-4.2.3.GA, JBossAS-5.0.0.CR1
Reporter: Adrian Brock
Assignee: Galder Zamarreno
Fix For: JBossAS-5.0.0.CR2, JBossAS-4.2.4.GA
The ClientUserTransactionObjectFactory is inefficient.
1) It is doing initialisation based on a static cached instance
Since nothing holds a hard reference to this class, it can be garbage collected meaning the
initialisation can be done multiple times.
2) The determination and resolving of the ServerVMClientUserTransaction does the lookup
for the transaction twice. Once when initialising the singleton and again to see whether it should
use the singleton.
Both issues could be resolved by simplifying ClientUserTransactionObjectFactory.getUserTransaction()
to be something (which removes the need for the cached object)
static private UserTransaction getUserTransaction()
{
ServerVMClientUserTransaction serverUserTransaction = ServerVMClientUserTransaction.getSingleton();
if (serverUserTranasction.isServer())
return serverUserTransaction;
else
return ClientUserTransaction.getSingleton();
}
This would require a new method on ServerVMClientUserTransaction to detect whether it can be used,
i.e. it can locate a local transaction manager.
public boolean isServer()
{
return tm != 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, 8 months