March 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-6471) Open console support features

by Scott M Stark (JIRA)

Open console support features ----------------------------- Key: JBAS-6471 URL: https://jira.jboss.org/jira/browse/JBAS-6471 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Scott M Stark Assignee: Scott M Stark A task for the features we would like to have resolved for 5.1 embedded console -- 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, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-228) External load balancer for non-HTTP invocations

by Brian Stansberry (JIRA)

External load balancer for non-HTTP invocations ----------------------------------------------- Key: JBCLUSTER-228 URL: https://jira.jboss.org/jira/browse/JBCLUSTER-228 Project: JBoss Clustering Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry Fix For: Backlog A server that functions like an HTTP load balancer, but intended for use with non-HTTP invocations, e.g. EJB invocations. Back end JBoss AS instances make this load balancer aware of deployments of clustered services; it load balances requests between them. Client proxies know how to talk to the load balancer(s). Main benefit is no need to open firewall to allow traffic to a fluctuating set of back end JBoss instances. Could also be useful in proxying requests from IIOP clients. -- 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, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-6089) Can not disable autodiscovery if System.setProperty() is used

by Wolf-Dieter Fink (JIRA)

Can not disable autodiscovery if System.setProperty() is used ------------------------------------------------------------- Key: JBAS-6089 URL: https://jira.jboss.org/jira/browse/JBAS-6089 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Naming Affects Versions: JBossAS-4.2.3.GA, JBossAS-5.0.0.CR1, JBossAS-4.2.2.GA Reporter: Wolf-Dieter Fink Assignee: Scott M Stark If a InitialContext is created via new InitialContext() and the properties are set via System.setProperty(...) the autodiscovery can not be disabled. Here the JUnitTest method: public void checkSystemPropertiesConnection() throws NamingException { System.setProperty("java.naming.factory.initial", "org.jboss.naming.NamingContextFactory"); System.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces"); // System.setProperty("java.naming.provider.url", "jnp://localhost:1099"); System.setProperty("jnp.disableDiscovery", "true"); InitialContext ctx = new InitialContext(); LOGGER.debug("JNDI properties: "+ctx.getEnvironment()); } ------------------------------ The Log output 16:01:28,497 DEBUG [de.wfink.ejb21.ConnectionTest] JNDI properties: {jnp.parsedName=, java.naming.provider.url=padwfink1:1099, java.naming.factory.initial=org.jboss.naming.NamingContextFactory, jnp.disableDiscovery=false, java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces:org.jboss.naming:org.jnp.interfaces} 16:01:29,481 DEBUG [org.jnp.interfaces.NamingContext] Failed to connect to padwfink1:1099 ---------------------------- If a lookup is started with this InitialContext autodiscovery is started. If all is set in a HashTable and InitialContext(hashTable) is call it works -- 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, 4 months

5
10
0 / 0

[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

17 years, 4 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

17 years, 4 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

17 years, 4 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

17 years, 4 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

17 years, 4 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

17 years, 4 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

17 years, 4 months

1
0
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 March 2009