October 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBESB-181) Provide a more convenient/obvious means of accessing the "current" object on the Message Body???

by Tom Fennelly (JIRA)

Provide a more convenient/obvious means of accessing the "current" object on the Message Body??? ------------------------------------------------------------------------------------------------ Key: JBESB-181 URL: http://jira.jboss.com/jira/browse/JBESB-181 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: ESB Core Affects Versions: 4.0 Reporter: Tom Fennelly Assigned To: Mark Little Priority: Minor Fix For: 4.0 ActionProcessors need to call "Message.getBody().get(CURRENT_OBJECT)" in order to access the "current" body Object. Is this not a little obscure? Would it not be more convenient/intuitive if the "current" object could be accessed via something like "Message.getBody().getCurrent()" - it could wrap "Message.getBody().get(CURRENT_OBJECT)" in the Body impl. Also, should CURRENT_OBJECT be defined on the ActionProcessor or Body type? It's currently defined in ActionProcessor? Of course this would mean that the current "Message.getBody().get(CURRENT_OBJECT)" calls would all need to be modified to "Message.getBody().get(Body.CURRENT_OBJECT)", but I'd think that is clearer anyway. Just some usability thoughts - feel free to delete the issus! -- 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, 2 months

2
11
0 / 0

[JBoss JIRA] Created: (JBAS-3743) Wrong SQL in oracle-jdbc2-service.xml example

by Adrian Brock (JIRA)

Wrong SQL in oracle-jdbc2-service.xml example --------------------------------------------- Key: JBAS-3743 URL: http://jira.jboss.com/jira/browse/JBAS-3743 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS service Affects Versions: JBossAS-4.0.5.CR1 Reporter: Adrian Brock Assigned To: Adrian Brock Priority: Minor Fix For: JBossAS-4.0.5.GA The docs/examples/oracle-jdbc2-service.xml contains a bad sql statement. DELETE_MARKED_MESSAGES_WITH_TX = DELETE FROM JMS_MESSAGES MESS WHERE TXOP=:1 AND EXISTS (SELECT TXID FROM JMS_TRANSACTIONS TX WHERE TX.TXID = MESS.TXID) The :1 should be replaced with ? -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Assigned: (JBMESSAGING-407) XARecovery integration of JBossMessaging with JBossTS

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-407?page=all ] Tim Fox reassigned JBMESSAGING-407: ----------------------------------- Assignee: Tim Fox (was: Ovidiu Feodorov) > XARecovery integration of JBossMessaging with JBossTS > ----------------------------------------------------- > > Key: JBMESSAGING-407 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-407 > Project: JBoss Messaging > Issue Type: Patch > Components: Tests and Performance > Environment: JBoss 4.0.3SP1, JBossTs 4.2GA, JBOSS Messagig 1.0.1CR2 > Reporter: Madhusudhan Konda > Assigned To: Tim Fox > Fix For: 1.2.0.Alpha2 > > Attachments: artifacts.zip, jms-recovery-patch-all.txt, jms.zip, JMSProviderXAResourceRecovery.java, xa.zip, xarecovery-patch.txt, XATestStandaloneRecovery.java > > Original Estimate: 1 week > Remaining Estimate: 1 week > > To make JBossMessaging XAResource as recoverable using JBossTS RecoveryManager -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-436) All versionable nodes to have a "checkin" comment string property

by Michael Neale (JIRA)

All versionable nodes to have a "checkin" comment string property ----------------------------------------------------------------- Key: JBRULES-436 URL: http://jira.jboss.com/jira/browse/JBRULES-436 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-490) All nodes to only have mandatory fields defined

by Michael Neale (JIRA)

All nodes to only have mandatory fields defined ----------------------------------------------- Key: JBRULES-490 URL: http://jira.jboss.com/jira/browse/JBRULES-490 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-3739) On Windows: jbossmq.test.SecurityUnitTestCase fails

by Prabhat Jha (JIRA)

On Windows: jbossmq.test.SecurityUnitTestCase fails --------------------------------------------------- Key: JBAS-3739 URL: http://jira.jboss.com/jira/browse/JBAS-3739 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS service, Security Environment: Windows 2003, Sun JDK 1.4 Reporter: Prabhat Jha Assigned To: Adrian Brock Fix For: JBossAS-4.0.5.GA jbossmq.test.SecurityUnitTestCase#runLoginTest fails. javax.jms.JMSSecurityException: Connection not authorized to do durable subscription on topic: securedTopic at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:150) at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:643) at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:177) at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:185) at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:395) at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:398) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748) at java.lang.Thread.run(Thread.java:534) This results into the assertion fail error which is: junit.framework.AssertionFailedError: Subscriber did not get correct number of messages 0 expected:<5> but was:<0> at org.jboss.test.jbossmq.test.SecurityUnitTestCase.runLoginTest(SecurityUnitTestCase.java:67) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) -- 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, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (JBRULES-511) Have "baseline" method in Package to sweep all contained assets, and then check in the package (for exmaple "deployed").

by Michael Neale (JIRA)

Have "baseline" method in Package to sweep all contained assets, and then check in the package (for exmaple "deployed"). ------------------------------------------------------------------------------------------------------------------------ Key: JBRULES-511 URL: http://jira.jboss.com/jira/browse/JBRULES-511 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Components: drools-brms Reporter: Michael Neale Assigned To: Michael Neale This is seperate to individual rule statuses. -- 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, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-3714) EjbHome.create throws ClassCastException

by warren crossing (JIRA)

EjbHome.create throws ClassCastException ---------------------------------------- Key: JBAS-3714 URL: http://jira.jboss.com/jira/browse/JBAS-3714 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: IIOP service Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA Environment: Java 1.5.0_08 Reporter: warren crossing Assigned To: Francisco Reverbel Hello Please have a look at http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974096#3974096 as this sums up my issue. I have a jboss.log file and am happy to patch the source code and test/debug this issue. It looks as though the IOR stream to object is returning a org.jacorb.orb.Reference which does not implement the beans Remote interface. I have stepped through the iiop EjbObjectServant code and IORFactory, the everything looks fine, no amount of changing jboss.xml ro standardjboss.xml makes any difference. Why possibly could the reference returned by the DynamicIIOPStub.invoke not implement the Bean Remote interface? Any idea, or hist of where to look/debug? -- 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, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1064) Admin module is vulnerable to XSS attacks.

by Roman Arkhangelskiy (JIRA)

Admin module is vulnerable to XSS attacks. ------------------------------------------ Key: JBPORTAL-1064 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1064 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.4 Final Reporter: Roman Arkhangelskiy Assigned To: Julien Viet After having been run on JBoss-Portal 2.4.0 source code, Jtest's BugDetective feature reported a lot of places that make the 'admin' module vulnerable to XSS attacks. There are quite a few such places in the code and it is not difficult to locate them. For example the variable named 'sCurrPath' seems to be widely used in many jsp-pages of the module, and it happens very often that it's value, having been obtained directly from ServletRequest, is displayed (or used for the initialization of forms' hidden fields) without any prior validation. Such approach makes it possible for the malicious user to perform an XSS attack. I realize that this module represents an area with the restricted access, but I can also envision a situation when the UI of the administrative module itself does not allow any harmful action to be performed, but it is possible to use a kind of specific http-client to construct dangerous requests. So from technical point of view any data coming from client should be validated before their further use even in restricted areas. The real-life example in file src/portal-core-war/WEB-INF/jsp/cms/admin/upload.jsp: the value of 'sCurrPath' variable is used at line 18 while having been already 'tainted' at line 10. It is worth to track the use of all variables with this name across the entire module to see all the dangerous situations. Please let me know if you think this represents a real problem or BugDetective is mistaken. Thank you! -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-728) Constructing relative path in PersistenceUnitDeploymen.start bogus for ../../foo.jar

by Heiko W. Rupp (JIRA)

Constructing relative path in PersistenceUnitDeploymen.start bogus for ../../foo.jar ------------------------------------------------------------------------------------ Key: EJBTHREE-728 URL: http://jira.jboss.com/jira/browse/EJBTHREE-728 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC9 - FD Reporter: Heiko W. Rupp The following code in PersistenceUnitDeployment.start() tries to construct an absolute path when given a relative URL String base = di.getUrl().toString(); jar = jar.replaceAll("\\.\\./", "+"); int idx = jar.lastIndexOf('+'); jar = jar.substring(idx + 1); for (int i = 0; i < idx + 1; i++) { int slash = base.lastIndexOf('/'); base = base.substring(0, slash + 1); // (1) } url = new URL(base + jar.substring(idx)); // (2) This fails in 2 places: 1) Only the last component is chopped of. After this the statement is a noop, as the slash found is always the trailing character of the String 2) The already 'corrected' jar is crippled when more than one ../ combination is in the jar path A fix can look like this: { int slash = base.lastIndexOf('/'); base = base.substring(0, slash ); // (1) } url = new URL(base + "/" +jar); // (2) -- 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, 2 months

1
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2006