January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1208) Single quote in Page Name causes problem in Portal Admin Page.

by Ian White (JIRA)

Single quote in Page Name causes problem in Portal Admin Page. -------------------------------------------------------------- Key: JBPORTAL-1208 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1208 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.DR1 Environment: XP, AS 4.0.5.GA, Portal 2.6DR Reporter: Ian White Assigned To: Julien Viet Priority: Minor Create a new portal page with the name containing a single quote; e.g. Bianca's Page Try to select that page in the Admin Portlet; e.g. to try to add Windows to it. You cannot select it, because the jvascript in the admin page is screwed up by the single quote. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3398) Non exploded sar containing war cannot undeploy the war file properly

by Julien Viet (JIRA)

Non exploded sar containing war cannot undeploy the war file properly --------------------------------------------------------------------- Key: JBAS-3398 URL: http://jira.jboss.com/jira/browse/JBAS-3398 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment services Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.0.3 SP1, JBossAS-4.0.3 Final Environment: JBoss-4.0.4.GA MacOSX Tiger Java 1.4.2 Reporter: Julien Viet Assigned To: Dimitris Andreadis Fix For: JBossAS-4.0.5.CR1, JBossAS-5.0.0.GA A sar file containing a war file non exploded is dropped in AS before startup. Start JBoss Shutdown JBoss The MainDeployer wants to stop() / destroy() the war file. The Web deployer is already gone and it produces an javax.management.InstanceNotFoundException when it tries to stop() / destroy() the war deployer Because the war is nested in a sar file, the web deployer is undeployed before the sar containing the war is undeployed. Note : this does not happen with exploded sar (like http invoker sar that contains the invoker.war) because the war is added to the MainDeployer.deploymentList list. This does not happen with non exploded because the war file is not in the local directory but rather in tmp and thus does not get added to the deployment list. Here are some field values : the string used to discriminate wether it's in local or tmp - file:/Users/julien/java/jboss-4.0.4.GA/server/default/tmp/deploy/ a war in non exploded sar - file:/Users/julien/java/jboss-4.0.4.GA/server/default/tmp/deploy/tmp51485jboss-portal.sar-contents/portal-core.war invoker.war in exploded sar - file:/Users/julien/java/jboss-4.0.4.GA/server/default/deploy/http-invoker.sar/invoker.war/ -- 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, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBTM-192) XA_RETRY treated incorrectly during commit

by Mark Little (JIRA)

XA_RETRY treated incorrectly during commit ------------------------------------------ Key: JBTM-192 URL: http://jira.jboss.com/jira/browse/JBTM-192 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.2 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.2.3 XA_RETRY is treated as an unrecoverable failure during commit when it should cause the recovery system to retry periodically. -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBPM-311) Propertys from inherited Actions not directly accessiblly

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-311?page=all ] Tom Baeyens closed JBPM-311. ---------------------------- Fix Version/s: jBPM 3.1.4 jBPM 3.2 beta 2 Resolution: Done > Propertys from inherited Actions not directly accessiblly > --------------------------------------------------------- > > Key: JBPM-311 > URL: http://jira.jboss.com/jira/browse/JBPM-311 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM 3.0 > Environment: jbpm-starters-kit-with-eclipse-3.0.zip > Reporter: Michael M > Assigned To: Tom Baeyens > Priority: Minor > Fix For: jBPM 3.1.4, jBPM 3.2 beta 2 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > If i generate an Action B from Action A with a Property A.name then I can't fill the name in (with) the processdefinition.xml... > Example : > class A extends ActionHandler { > private String name ; > get And Set'er () ... > } > class B extends A { > } > <node...> > <action class="B"> > <name>test</name> <--- will fill the property but it doesnt work > </action> > </node> > > ( The Problem is with all content-type's ) .. > A cause : > For one case I have look up in the org.jbpm.instantiation.BeanInstantiator SourceCode and I see > Method[] methods = clazz.getDeclaredMethods(); > but > It should be Method[] methods = clazz.getMethods(); > ( I mean the "clazz.getDeclaredMethods()" for content-type="bean". For Fields-Code it's the same Problem with used > getDeclaredFields() instead getFields() ... and so on in other classes. ) -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3860) XAManagedConnection should implement LocalTransaction to clean up hanging LocalTransaction

by Weston Price (JIRA)

XAManagedConnection should implement LocalTransaction to clean up hanging LocalTransaction ------------------------------------------------------------------------------------------ Key: JBAS-3860 URL: http://jira.jboss.com/jira/browse/JBAS-3860 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Reporter: Weston Price Assigned To: Weston Price Fix For: JBossAS-4.2.0.CR1 Currently, XAManagedConnection does not implement the LocalTransaction interface. As a result the following conditions produces an error: @TransactionDemarcation(NotSupported) public void doSomething() { DataSource ds = ... (XADataSource) Connection c = ds.getConnection(); c.setAutoCommit(false); // NOT Managed transaction // do stuff throw EJBException("Container/JCA should rollback uncommitted transaction!"); } Because of the c.setAutoCommit(false), a LocalTransaction is started. When the EJBException is thrown, the transaction is left hanging. Typically this is handled in the TxConnectionEventListener for LocalManagedConnection. However, in the case of XAManagedConnection the get mc.getLocalTransaction() throws a ResourceException and the transaction is never rolled back. -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-190) lifecycle methods for XA recovery

by Mark Little (JIRA)

lifecycle methods for XA recovery --------------------------------- Key: JBTM-190 URL: http://jira.jboss.com/jira/browse/JBTM-190 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.2 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.6 -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-666) Broken or malicious clients can lock up the remoting server

by Ovidiu Feodorov (JIRA)

Broken or malicious clients can lock up the remoting server ----------------------------------------------------------- Key: JBREM-666 URL: http://jira.jboss.com/jira/browse/JBREM-666 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Alpha4 Reporter: Ovidiu Feodorov Assigned To: Tom Elrod Priority: Critical Fix For: 2.2.0.Alpha5 Due to the way the main socket accept loop is coded, there is an interval during which the main acceptor thread ("SocketServerInvoker#0-4457" in the log below) interacts with the new connection's input and output streams, before handing the connection over to a worker thread from the pool. During this period, the main acceptor thread is vulnerable to lock-ups, caused by either a broken or malicious client. Log from a production environment: 2007-01-08 16:13:31,473 624292 TRACE [org.jboss.remoting.transport.socket.SocketServerInvoker] @SocketServerInvoker#0-4457 Socket is going to be accepted 2007-01-08 16:13:31,473 624292 TRACE [org.jboss.remoting.transport.socket.SocketServerInvoker] @SocketServerInvoker#0-4457 Accepted: Socket[addr=/10.1.13.73,port=16999,localport=4457] 2007-01-08 16:13:31,473 624292 TRACE [org.jboss.remoting.transport.socket.SocketServerInvoker] @SocketServerInvoker#0-4457 try to get a thread for processing 2007-01-08 16:13:31,473 624292 TRACE [org.jboss.remoting.transport.socket.SocketServerInvoker] @SocketServerInvoker#0-4457 Got thread for processing - Thread[SocketServerInvokerThread-10.1.122.40-0,5,jboss] 2007-01-08 16:13:31,473 624292 TRACE [org.jboss.remoting.transport.socket.SocketServerInvoker] @SocketServerInvoker#0-4457 Reusing thread t=Thread[SocketServerInvokerThread-10.1.122.40-0,5,jboss] 2007-01-08 16:13:31,473 624292 TRACE [org.jboss.remoting.serialization.impl.jboss.JBossSerializationManager] @SocketServerInvoker#0-4457 Creating JBossObjectOutputStream 2007-01-08 16:13:31,473 624292 TRACE [org.jboss.remoting.serialization.impl.jboss.JBossSerializationManager] @SocketServerInvoker#0-4457 Creating JBossObjectInputStream 16:13:31,473 is the last time main acceptor thread is heard from (the logged interval ends at 16:22:34 with the server shutdown). -- 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, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-706) Failover mop-up

by Ovidiu Feodorov (JIRA)

Failover mop-up --------------- Key: JBMESSAGING-706 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-706 Project: JBoss Messaging Issue Type: Task Components: JMS Clustering Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.0.Beta2 A container for all failover mop up tasks that still have to be completed -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-731) Get a new tagged remoting release from the remoting team

by Ovidiu Feodorov (JIRA)

Get a new tagged remoting release from the remoting team -------------------------------------------------------- Key: JBMESSAGING-731 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-731 Project: JBoss Messaging Issue Type: Task Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.0.Beta2 -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-888) Remove TreeCache.UNITIALIZED, add NodeSPI.get/setDataLoaded()

by Elias Ross (JIRA)

Remove TreeCache.UNITIALIZED, add NodeSPI.get/setDataLoaded() ------------------------------------------------------------- Key: JBCACHE-888 URL: http://jira.jboss.com/jira/browse/JBCACHE-888 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.ALPHA2 Reporter: Elias Ross Assigned To: Manik Surtani For 2.0, I believe the intent is to stop having code explicitly reference TreeCache. One thing that strikes me as extremely clumsy is the TreeCache.UNITIALIZED flag that is set in the data map itself. I believe that adding the flag to the node can accomplish the same thing. It might make sense to look at this http://java.sun.com/j2se/1.5.0/docs/api/java/util/EnumSet.html for setting flags, etc. -- 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, 3 months

1
2
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 January 2007