March 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2025) Guided editor and contains operator

by Hestin Gilles (JIRA)

Guided editor and contains operator ----------------------------------- Key: JBRULES-2025 URL: https://jira.jboss.org/jira/browse/JBRULES-2025 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-guvnor Affects Versions: 5.0.0.CR1 Environment: OS : Windows XP pro Guvnor started on jboss 4.2.3 Reporter: Hestin Gilles Assignee: Mark Proctor The guided editor allows to use the contains operator with a bound variable. But the output DRL source in this case is wrong : the variable hasn't got the $ prefix. Example : rule "testGHE" dialect "mvel" when cli : Client( type == "01" , category == "001" ) req : Request( clientList contains cli ) then cli.setNature( "3" ); req.setId( "id req" ); end We should have "req : Request( clientList contains $cli )" instead of "req : Request( clientList contains cli )" -- 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

15 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JBBUILD-483) jta.jar from the repo does not have a manifest.mf file

by Jay Balunas (JIRA)

jta.jar from the repo does not have a manifest.mf file ------------------------------------------------------ Key: JBBUILD-483 URL: https://jira.jboss.org/jira/browse/JBBUILD-483 Project: JBoss Build System Issue Type: Bug Components: JBossBuild, Maven Reporter: Jay Balunas Assignee: Pete Muir Priority: Critical jta.jar from the repository does not have a manifest.mf file -- 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

15 years, 9 months

4
8
0 / 0

[JBoss JIRA] Created: (JBAS-6663) UserTransaction.rollback() must not throw IllegalStateException if getStatus()==STATUS_ROLLEDBACK

by JÃ¶rg von Frantzius (JIRA)

UserTransaction.rollback() must not throw IllegalStateException if getStatus()==STATUS_ROLLEDBACK ------------------------------------------------------------------------------------------------- Key: JBAS-6663 URL: https://jira.jboss.org/jira/browse/JBAS-6663 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Manager (Arjuna) Affects Versions: JBossAS-4.2.3.GA Reporter: JÃ¶rg von Frantzius Assignee: Jonathan Halliday When a timeout has occurred, UserTransaction.getStatus() returns STATUS_ROLLEDBACK. Calling UserTransaction.rollback() at this point will throw the following IllegalStateException: java.lang.IllegalStateException: [com.arjuna.ats.internal.jta.transaction.arjunacore.inactive] [com.arjuna.ats.internal.jta.transaction.arjunacore.inactive] The transaction is not active! at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1473) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:163) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.rollback(BaseTransactionManagerDelegate.java:126) at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.rollback(ServerVMClientUserTransaction.java:148) The JTA specification says about when UserTransaction.rollback() may throw IllegalStateException: "IllegalStateException Thrown if the current thread is not associated with a transaction." Since getStatus() does return STATUS_ROLLEDBACK (and *not* STATUS_NO_TRANSACTION), the thread obviously still is associated with a transaction. Apart from breaking the JTA contract, this effectively renders the UserTransaction useless since begin() will also throw exception. -- 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

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-6547) In persistence.xml if the </jta-data-source> tag is in a new line, the persistence it's not corrected loaded.

by Israel Lacerra (JIRA)

In persistence.xml if the </jta-data-source> tag is in a new line, the persistence it's not corrected loaded. ------------------------------------------------------------------------------------------------------------- Key: JBAS-6547 URL: https://jira.jboss.org/jira/browse/JBAS-6547 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.1.GA Reporter: Israel Lacerra If I run JBoss with this persistence.xml: .. <persistence-unit name="rosys"> <jta-data-source>java:/jdbc/rosys-core </jta-data-source> ... the entities are not loaded. But if I change the persistence: <persistence-unit name="rosys"> <jta-data-source>java:/jdbc/rosys-core</jta-data-source> everything goes fine. -- 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

15 years, 9 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-5581) Setting jgroups.bind_address or bind.address in run.conf will be ignored if -b used

by Galder Zamarreno (JIRA)

Setting jgroups.bind_address or bind.address in run.conf will be ignored if -b used ----------------------------------------------------------------------------------- Key: JBAS-5581 URL: http://jira.jboss.com/jira/browse/JBAS-5581 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA Reporter: Galder Zamarreno Assigned To: Galder Zamarreno * Why it it useless specifying -Dbind.address=192.168.0.1 inside run.conf? Why does it work only specifying it on command line? For example: If you set -Dbind.address=127.0.0.1 in run.conf and starting AS with: ./bin/run.sh -b 10.33.144.245 The value assigned to -Dbind.address will be ignored. When you pass -Dbind.address in the command line, JBoss sets both this system property and -Djgroups.bind_address to that value, which means that if you pass -b after that, it won't override the given -Dbind.address. Bottom line, if -Dbind.address set in command line before -b, it's the winner. Example: ./bin/run.sh -Dbind.address=127.0.0.1 -b 1.2.3.4 -> JGroups will bind to 127.0.0.1 If you pass -b in the command line before -Dbind.address, -b will first set -Dbind.address and -Djgroups.bind_address, but then, when -Dbind.address is process, it will override the values of them two with what was passed in -Dbind.address ./bin/run.sh -b 1.2.3.4 -Dbind.address=127.0.0.1 -> JGroups will bind to 127.0.0.1 Now, This does not happen when the -Dbind.address is set in run.conf instead of command line. There's a bug here. When AS processes -b, it checks whether -Dbind.address has been set, which it has, so leaves it as it is. Now, when it checks -Djgroups.bind_address, it sees that it hasn't been set, but *does not do a double check in case -Dbind.address has been set*, so it ends up setting -Djgroups.bind_address to the value of -b, that way ignoring the value you passed to -Dbind.address. Example: run.conf with -Dbind.address=127.0.0.1 ./bin/run.sh -b 1.2.3.4 -> JGroups will bind to 1.2.3.4 What's the fix? Add the double check in -b processing so that if -Dbind.address was set by the user, AS does not take the value of -b and assign to -Djgroups.bind_addr -- 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

15 years, 9 months

2
2
0 / 0

[JBoss JIRA] Updated: (JBAS-1796) Review project dependencies and create proper abstractions

by Jesper Pedersen (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-1796?page=com.atlassian.jira.plug... ] Jesper Pedersen updated JBAS-1796: ---------------------------------- Attachment: tattletale-report-rev86230.zip > Review project dependencies and create proper abstractions > ---------------------------------------------------------- > > Key: JBAS-1796 > URL: https://jira.jboss.org/jira/browse/JBAS-1796 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Other > Reporter: Adrian Brock > Priority: Critical > Fix For: Backlog > > Attachments: tattletale-report-rev86230.zip > > > I am getting singlularly fed up with people doing their own integrations > in such a way that every project needs to depend directly on everything > in thirdparty and every other project. > Some people need to go on a course to learn the meaning of abstraction. > e.g. > The server module is an integration project. It should not be directly dependent > on implementation details of Xerces: > package org.jboss.webservice.metadata.wsdl; > import org.apache.xerces.xs.XSComplexTypeDefinition; > import org.apache.xerces.xs.XSTypeDefinition; > import org.jboss.webservice.metadata.wsdl.WSDLConstants; > import org.jboss.webservice.metadata.wsdl.xsd.XSDComplexType; > import org.jboss.webservice.metadata.wsdl.xsd.XSDElement; > import org.jboss.webservice.metadata.wsdl.xsd.XSDSchema; > import org.jboss.webservice.metadata.wsdl.xsd.XSDSimpleType; > import org.jboss.webservice.metadata.wsdl.xsd.XSDType; > import javax.xml.namespace.QName; > import java.io.File; > import java.io.FileWriter; > import java.io.IOException; > import java.lang.reflect.Field; > import java.lang.reflect.Method; > import java.lang.reflect.Modifier; > import java.net.URL; > import java.util.ArrayList; > import java.util.HashMap; > import java.util.Iterator; > import java.util.List; > import java.util.Map; > public class WSDLUtils > { > private String newline = System.getProperty("line.separator"); -- 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

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1796) Review project dependencies and create proper abstractions

by Jesper Pedersen (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-1796?page=com.atlassian.jira.plug... ] Jesper Pedersen updated JBAS-1796: ---------------------------------- Attachment: (was: tattletale-report-rev85182.zip) > Review project dependencies and create proper abstractions > ---------------------------------------------------------- > > Key: JBAS-1796 > URL: https://jira.jboss.org/jira/browse/JBAS-1796 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Other > Reporter: Adrian Brock > Priority: Critical > Fix For: Backlog > > Attachments: tattletale-report-rev86230.zip > > > I am getting singlularly fed up with people doing their own integrations > in such a way that every project needs to depend directly on everything > in thirdparty and every other project. > Some people need to go on a course to learn the meaning of abstraction. > e.g. > The server module is an integration project. It should not be directly dependent > on implementation details of Xerces: > package org.jboss.webservice.metadata.wsdl; > import org.apache.xerces.xs.XSComplexTypeDefinition; > import org.apache.xerces.xs.XSTypeDefinition; > import org.jboss.webservice.metadata.wsdl.WSDLConstants; > import org.jboss.webservice.metadata.wsdl.xsd.XSDComplexType; > import org.jboss.webservice.metadata.wsdl.xsd.XSDElement; > import org.jboss.webservice.metadata.wsdl.xsd.XSDSchema; > import org.jboss.webservice.metadata.wsdl.xsd.XSDSimpleType; > import org.jboss.webservice.metadata.wsdl.xsd.XSDType; > import javax.xml.namespace.QName; > import java.io.File; > import java.io.FileWriter; > import java.io.IOException; > import java.lang.reflect.Field; > import java.lang.reflect.Method; > import java.lang.reflect.Modifier; > import java.net.URL; > import java.util.ArrayList; > import java.util.HashMap; > import java.util.Iterator; > import java.util.List; > import java.util.Map; > public class WSDLUtils > { > private String newline = System.getProperty("line.separator"); -- 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

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-6003) jboss.entity.manager.jndi.name in persistence.xml doesn't work

by Xavier Jodoin (JIRA)

jboss.entity.manager.jndi.name in persistence.xml doesn't work -------------------------------------------------------------- Key: JBAS-6003 URL: https://jira.jboss.org/jira/browse/JBAS-6003 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.CR2 Environment: Ubuntu 8.04 java 1.6 Reporter: Xavier Jodoin Works under jboss 5 CR1 and not under CR2 the jndi name is not bound: <property name="jboss.entity.manager.jndi.name" value="securityEntityManager"/> new InitialContext().lookup("securityEntityManager"); <?xml version="1.0" encoding="UTF-8"?> <persistence xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation = "http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd" version="1.0"> <persistence-unit name="NAIDsecurity" transaction-type="JTA"> <provider>org.hibernate.ejb.HibernatePersistence</provider> <jta-data-source>java:/SECURITYDS</jta-data-source> <properties> <property name="hibernate.dialect" value="org.hibernate.dialect.SQLServerDialect"/> <property name="hibernate.show_sql" value="false"/> <property name="jboss.entity.manager.jndi.name" value="securityEntityManager"/> <property name="hibernate.hbm2ddl.auto" value="update"/> </properties> </persistence-unit> </persistence> -- 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

15 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1759) move uncommited code to old repository to new repository

by Radoslav Husar (JIRA)

move uncommited code to old repository to new repository -------------------------------------------------------- Key: EJBTHREE-1759 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1759 Project: EJB 3.0 Issue Type: Sub-task Reporter: Radoslav Husar Assignee: Radoslav Husar -- 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

15 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-6388) Wrong order of start of j2ee modules

by Roberto (JIRA)

Wrong order of start of j2ee modules ------------------------------------ Key: JBAS-6388 URL: https://jira.jboss.org/jira/browse/JBAS-6388 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.GA Reporter: Roberto Priority: Minor When yoi have an EAR containg EJB Jars and Web Archive (war), today often the was is started before ejb jars. This means that if you have in the war a autostart servlet using ejb, this throws an exception (becuase they are not binded) The right order should be EJB JAR WAR -- 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

15 years, 9 months

2
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2009