February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBESB-366) Smooks examples.

by Mark Little (JIRA)

Smooks examples. ---------------- Key: JBESB-366 URL: http://jira.jboss.com/jira/browse/JBESB-366 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Examples, Transformation Service Affects Versions: 4.0 CR2 Reporter: Mark Little Assigned To: Tom Fennelly Fix For: 4.0 EDI, CSV, XML, XSLT, Java serializable, binary, use of a C-based transformer. -- 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

17 years, 11 months

2
4
0 / 0

[JBoss JIRA] Updated: (JBAS-2215) Datasource deployments should only depend on a jrmp invoker when use-java-context is true

by Weston Price (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2215?page=all ] Weston Price updated JBAS-2215: ------------------------------- Fix Version/s: (was: JBossAS-5.0.0.Beta1) (was: JBossAS-4.0.3 Final) > Datasource deployments should only depend on a jrmp invoker when use-java-context is true > ----------------------------------------------------------------------------------------- > > Key: JBAS-2215 > URL: http://jira.jboss.com/jira/browse/JBAS-2215 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA service > Affects Versions: JBossAS-4.0.2 Final > Reporter: Scott M Stark > Assigned To: Weston Price > > Currently every *-ds.xml deployment has a dependency on a JMXInvoker even if the DataSource is not bound into the global JNDI for use outside of the server. The only time a remote proxy should be created and a dependency on a JMXInvoker created is when the *-ds.xml use-java-context element is false. -- 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

17 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4040) org.jboss.mq.SpyJMSException: Could not store message ... java.sql.SQLException: Out of memory

by Mia Christina Taroy (JIRA)

org.jboss.mq.SpyJMSException: Could not store message ... java.sql.SQLException: Out of memory ---------------------------------------------------------------------------------------------- Key: JBAS-4040 URL: http://jira.jboss.com/jira/browse/JBAS-4040 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.4.CR2 Environment: Linux System. 4GB memory Reporter: Mia Christina Taroy Could you please help me regarding this errors: org.jboss.mq.SpyJMSException: Could not store message: 47178 msg=7708 hard NOT_STORED PERSISTENT queue=QUEUE.OutgoingQueue priority=1 lateClone=false hashCode=409536481; - nested throwable: (java.sql.SQLException: Out of memory (Needed 14440 bytes)) org.jboss.mq.SpyJMSException: Could not store message: 47163 msg=7705 hard NOT_STORED PERSISTENT queue=QUEUE.OutgoingQueue priority=1 lateClone=false hashCode=276505789; - nested throwable: (java.sql.SQLException: Out of memory; check if mysqld or some other process uses all available memory; if not, you may have to use 'ulimit' to allow mysqld to use more memory or you can add more swap space) org.jboss.mq.SpyJMSException: Could not store message: 377353 msg=139224 hard NOT_STORED PERSISTENT queue=QUEUE.OutgoingQueue priority=1 lateClone=false hashCode=1794787315; - nested throwable: (java.sql.SQLException: Out of memory (Needed 55240 bytes)) it always happen whenever i ran the app. Thanks. Hope to hear from 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

17 years, 11 months

2
1
0 / 0

[JBoss JIRA] Commented: (JBAS-2215) Datasource deployments should only depend on a jrmp invoker when use-java-context is true

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2215?page=comments#action_12352068 ] Dimitris Andreadis commented on JBAS-2215: ------------------------------------------ Weston, you need to correct the fix versions :) > Datasource deployments should only depend on a jrmp invoker when use-java-context is true > ----------------------------------------------------------------------------------------- > > Key: JBAS-2215 > URL: http://jira.jboss.com/jira/browse/JBAS-2215 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA service > Affects Versions: JBossAS-4.0.2 Final > Reporter: Scott M Stark > Assigned To: Weston Price > Fix For: JBossAS-5.0.0.Beta1, JBossAS-4.0.3 Final > > > Currently every *-ds.xml deployment has a dependency on a JMXInvoker even if the DataSource is not bound into the global JNDI for use outside of the server. The only time a remote proxy should be created and a dependency on a JMXInvoker created is when the *-ds.xml use-java-context element is false. -- 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

17 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBESB-395) More SAR classloader woes :-)

by Tom Fennelly (JIRA)

More SAR classloader woes :-) ----------------------------- Key: JBESB-395 URL: http://jira.jboss.com/jira/browse/JBESB-395 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0 CR2 Reporter: Tom Fennelly Assigned To: Kevin Conner Fix For: 4.0 I think I've another classloader puzzle for ye to tease out :-) So, we have the 2 sars now. The service gets deployed into jbossesb.sar and the dependencies into the other etc etc. One of the quickstarts (transform_XML2POJO) defines an action that follows a SmooksTransformer action. This 2nd action expected some POJO instances to be attached to the message (attached and populated by Smooks). The The classloading gets screwed because Smooks uses the jbossesb-dependencies.sar classloader (because it's in that .sar) to load the POJO bean class instances that are attached to the message. The action instance extracts the beans from the message and tries to cast them but because that action class is in the jbossesb.sar it uses the jbosses.sar classloader to load the POJO class instances, we get a ClassCastException. -- 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

17 years, 11 months

2
9
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-410) java:/JmsXA in no-tx context does not work the same way as JBossMQ

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-410?page=all ] Ovidiu Feodorov updated JBMESSAGING-410: ---------------------------------------- Fix Version/s: 1.2.1 Affects Version/s: 1.2.0.Beta2 1.0.1.SP4 > java:/JmsXA in no-tx context does not work the same way as JBossMQ > ------------------------------------------------------------------ > > Key: JBMESSAGING-410 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-410 > Project: JBoss Messaging > Issue Type: Bug > Components: Configuration and Management > Affects Versions: 1.0.1.CR2, 1.2.0.Beta2, 1.0.1.SP4 > Reporter: Elias Ross > Assigned To: Ovidiu Feodorov > Priority: Critical > Fix For: 1.2.1, 1.0.1.CR5 > > > The same code I wrote that uses java:/JmsXA in a non-transacted environment with JBossMQ does not work with JBoss Messaging. And actually the same code does work correctly with SonicMQ as well, using the JCA adaptor with the Sonic XA connection factory. > Why allow the use java:/JmsXA without transactions? It makes sense to use a cached connection manager anyway, like you would with a database. And anyway, should be addressed for compatibility. > The following code *should* successfully send a message to a queue running without a transaction. Currently, it doesn't seem to do anything and no usage warnings are produced. > QueueConnectionFactory queueCF = (QueueConnectionFactory)new InitialContext.lookup("java:/JmsXA"); > ... > QueueConnection queueConnection = queueCF.createQueueConnection(); > QueueSession queueSession = > queueConnection.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE); > QueueSender queueSender = queueSession.createSender(queue); > ObjectMessage om = queueSession.createObjectMessage(); > queueSender.send(om); > queueSender.close(); > queueSession.close(); > queueConnection.close(); -- 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

17 years, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBMESSAGING-410) java:/JmsXA in no-tx context does not work the same way as JBossMQ

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-410?page=comments#action_12... ] Ovidiu Feodorov commented on JBMESSAGING-410: --------------------------------------------- Reopening the issue, as Messaging-layer level changes required to fix http://jira.jboss.org/jira/browse/JBMESSAGING-721 will modify again the behavior described here. The changes will be made public in 1.0.1.SP4 and 1.2.0.CR1. The way an XASession behaves in absence of a JTA transaction is incompletely specified, so it is inevitable that different implemenation would work differently. Ultimately, it's up to the JCA layer, not the JMS layer, to enforce a certain behavior. For more discussions on the subject, please also read http://www.jboss.com/index.html?module=bb&op=viewtopic&t=98577. The issue will stay open until after the 1.2.0.GA release, when we will have more time to experiment with controversial subjects like this. > java:/JmsXA in no-tx context does not work the same way as JBossMQ > ------------------------------------------------------------------ > > Key: JBMESSAGING-410 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-410 > Project: JBoss Messaging > Issue Type: Bug > Components: Configuration and Management > Affects Versions: 1.0.1.CR2 > Reporter: Elias Ross > Assigned To: Ovidiu Feodorov > Priority: Critical > Fix For: 1.0.1.CR5 > > > The same code I wrote that uses java:/JmsXA in a non-transacted environment with JBossMQ does not work with JBoss Messaging. And actually the same code does work correctly with SonicMQ as well, using the JCA adaptor with the Sonic XA connection factory. > Why allow the use java:/JmsXA without transactions? It makes sense to use a cached connection manager anyway, like you would with a database. And anyway, should be addressed for compatibility. > The following code *should* successfully send a message to a queue running without a transaction. Currently, it doesn't seem to do anything and no usage warnings are produced. > QueueConnectionFactory queueCF = (QueueConnectionFactory)new InitialContext.lookup("java:/JmsXA"); > ... > QueueConnection queueConnection = queueCF.createQueueConnection(); > QueueSession queueSession = > queueConnection.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE); > QueueSender queueSender = queueSession.createSender(queue); > ObjectMessage om = queueSession.createObjectMessage(); > queueSender.send(om); > queueSender.close(); > queueSession.close(); > queueConnection.close(); -- 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

17 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-410) java:/JmsXA in no-tx context does not work the same way as JBossMQ

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-410?page=all ] Ovidiu Feodorov updated JBMESSAGING-410: ---------------------------------------- Comment: was deleted > java:/JmsXA in no-tx context does not work the same way as JBossMQ > ------------------------------------------------------------------ > > Key: JBMESSAGING-410 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-410 > Project: JBoss Messaging > Issue Type: Bug > Components: Configuration and Management > Affects Versions: 1.0.1.CR2 > Reporter: Elias Ross > Assigned To: Ovidiu Feodorov > Priority: Critical > Fix For: 1.0.1.CR5 > > > The same code I wrote that uses java:/JmsXA in a non-transacted environment with JBossMQ does not work with JBoss Messaging. And actually the same code does work correctly with SonicMQ as well, using the JCA adaptor with the Sonic XA connection factory. > Why allow the use java:/JmsXA without transactions? It makes sense to use a cached connection manager anyway, like you would with a database. And anyway, should be addressed for compatibility. > The following code *should* successfully send a message to a queue running without a transaction. Currently, it doesn't seem to do anything and no usage warnings are produced. > QueueConnectionFactory queueCF = (QueueConnectionFactory)new InitialContext.lookup("java:/JmsXA"); > ... > QueueConnection queueConnection = queueCF.createQueueConnection(); > QueueSession queueSession = > queueConnection.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE); > QueueSender queueSender = queueSession.createSender(queue); > ObjectMessage om = queueSession.createObjectMessage(); > queueSender.send(om); > queueSender.close(); > queueSession.close(); > queueConnection.close(); -- 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

17 years, 11 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBMESSAGING-410) java:/JmsXA in no-tx context does not work the same way as JBossMQ

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-410?page=all ] Ovidiu Feodorov reopened JBMESSAGING-410: ----------------------------------------- Reopening the issue, as Messaging-layer level changes required to fix [url]http://jira.jboss.org/jira/browse/JBMESSAGING-721[/url] will modify again the behavior described here. The changes will be made public in 1.0.1.SP4 and 1.2.0.CR1. The way an XASession behaves in absence of a JTA transaction is incompletely specified, so it is inevitable that different implemenation would work differently. Ultimately, it's up to the JCA layer, not the JMS layer, to enforce a certain behavior. For more discussions on the subject, please also read [url]http://www.jboss.com/index.html?module=bb&op=viewtopic&t=98577[/url]. The issue will stay open until after the 1.2.0.GA release, when we will have more time to experiment with controversial subjects like this. > java:/JmsXA in no-tx context does not work the same way as JBossMQ > ------------------------------------------------------------------ > > Key: JBMESSAGING-410 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-410 > Project: JBoss Messaging > Issue Type: Bug > Components: Configuration and Management > Affects Versions: 1.0.1.CR2 > Reporter: Elias Ross > Assigned To: Ovidiu Feodorov > Priority: Critical > Fix For: 1.0.1.CR5 > > > The same code I wrote that uses java:/JmsXA in a non-transacted environment with JBossMQ does not work with JBoss Messaging. And actually the same code does work correctly with SonicMQ as well, using the JCA adaptor with the Sonic XA connection factory. > Why allow the use java:/JmsXA without transactions? It makes sense to use a cached connection manager anyway, like you would with a database. And anyway, should be addressed for compatibility. > The following code *should* successfully send a message to a queue running without a transaction. Currently, it doesn't seem to do anything and no usage warnings are produced. > QueueConnectionFactory queueCF = (QueueConnectionFactory)new InitialContext.lookup("java:/JmsXA"); > ... > QueueConnection queueConnection = queueCF.createQueueConnection(); > QueueSession queueSession = > queueConnection.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE); > QueueSender queueSender = queueSession.createSender(queue); > ObjectMessage om = queueSession.createObjectMessage(); > queueSender.send(om); > queueSender.close(); > queueSession.close(); > queueConnection.close(); -- 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

17 years, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBRULES-214) goddamn keyword collisions damn it damn damn

by Michael Neale (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-214?page=comments#action_12352051 ] Michael Neale commented on JBRULES-214: --------------------------------------- Kudos for solving this Edson ! > goddamn keyword collisions damn it damn damn > -------------------------------------------- > > Key: JBRULES-214 > URL: http://jira.jboss.com/jira/browse/JBRULES-214 > Project: JBoss Rules > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Drl Parser/Builder > Affects Versions: 3.0-rc1 > Reporter: Michael Neale > Assigned To: Edson Tirelli > Priority: Critical > Fix For: 3.1-m3 > > > Getting more complaints about collisions with keywords. Things like "end" are obvious, but even "duration" etc... > Parser possibly needs to be a bit cleverer (not sure why duration is barfing.. but anyway). > I guess the only clear way forward is to enforce newline characters. > Most often the problem happens in the LHS. On the RHS its just "end" that is a problem. -- 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

17 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2007