February 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8608) Launch from path with space does not work

by Max Andersen (JIRA)

Launch from path with space does not work ----------------------------------------- Key: JBAS-8608 URL: https://jira.jboss.org/browse/JBAS-8608 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 7.0.0.Alpha1 Reporter: Max Andersen Priority: Critical Having a space in your download/install dir causes problem on AS 7(common on Mac for those forgetting to set simple username or on windows where "Documents and Settings" is the default - hence why I marked it critical ;): mkdir "space launch" cd "space launch" unzip jboss-7.0.0.Alpha1 cd jboss-7.0.0.Alpha1 ./bin/standalone.sh ========================================================================= JBoss Bootstrap Environment JBOSS_HOME: /Users/max/space launch/jboss-7.0.0.Alpha1 JAVA: java JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 ========================================================================= Exception in thread "main" java.lang.NoClassDefFoundError: launch/jboss-7/0/0/Alpha1/standalone/log/boot/log Caused by: java.lang.ClassNotFoundException: launch.jboss-7.0.0.Alpha1.standalone.log.boot.log at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

5
5
0 / 0

[JBoss JIRA] Created: (JBAS-6519) JCA / XAResourceRecovery

by Jesper Pedersen (JIRA)

JCA / XAResourceRecovery ------------------------ Key: JBAS-6519 URL: https://jira.jboss.org/jira/browse/JBAS-6519 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: JCA service Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: JBossAS-5.1.0.Beta1 Add support for org.jboss.tm.XAResourceRecovery in the JCA layer -- 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, 1 month

2
8
0 / 0

[JBoss JIRA] Created: (JBRULES-2672) Error while parsing xml with <and-constraint-connective> within <pattern>

by Veit Guna (JIRA)

Error while parsing xml with <and-constraint-connective> within <pattern> ------------------------------------------------------------------------- Key: JBRULES-2672 URL: https://jira.jboss.org/browse/JBRULES-2672 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.1.0.FINAL Environment: Jboss 5.1.0, Drools 5.1.0, Jdk 1.6.0_14 Reporter: Veit Guna Assignee: Mark Proctor Hi. I'm using drools 5.1.0 together with .xdrl files. I encountered a possible bug in the AndHandler class when parsing the following .xdrl file: --cut here-- <dro:pattern object-type="EMail"> <dro:and-constraint-connective> <dro:field-constraint field-name="foo"> <dro:literal-restriction evaluator="!=" value="null"/> </dro:field-constraint> <dro:field-constraint field-name="foo.toLowerCase"> <dro:literal-restriction evaluator="==" value="test"/> </dro:field-constraint> </dro:and-constraint-connective> </dro:pattern> --cut here-- Parsing this seems to fail when adding the package from xml: Caused by: org.drools.compiler.DroolsParserException: org.xml.sax.SAXParseException: <and-constraint-connective> has an invalid parent element [[Pattern: id=null; objectType=EMail]] at org.drools.compiler.PackageBuilder.addPackageFromXml(PackageBuilder.java:304) at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:468) ... 142 more According to the .xsd (4.0) this should be no problem. Looking at the OrHandler it seems that simply the PatternDescr is missing from the validParents. Also tried to disable xml validation with: System.setProperty("drools.schema.validating","false"); but with no luck. So find attached the _very_ complex patch that adds PackageDescr to the AndHandler :). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
6
0 / 0

[JBoss JIRA] Created: (JBAS-8709) Create a service for each resource adapter

by Jesper Pedersen (JIRA)

Create a service for each resource adapter ------------------------------------------ Key: JBAS-8709 URL: https://jira.jboss.org/browse/JBAS-8709 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: JCA service Reporter: Jesper Pedersen Assignee: Stefano Maestri Fix For: 7.0.0.Beta1 We need to expose a Service<ResourceAdapter> for each resource adapter deployment that contains a ResourceAdapter instance. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

4
3
0 / 0

[JBoss JIRA] Created: (JBAS-5474) @PostLoad -> LazyInitializationException: illegal access to loading collection ond a @OneToMany with FetchType.EAGER

by Stefan Lindner (JIRA)

@PostLoad -> LazyInitializationException: illegal access to loading collection ond a @OneToMany with FetchType.EAGER -------------------------------------------------------------------------------------------------------------------- Key: JBAS-5474 URL: http://jira.jboss.com/jira/browse/JBAS-5474 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-4.2.2.GA Environment: Win XP SP2, Java 1.5.0_15-b04 Reporter: Stefan Lindner Assigned To: Carlo de Wolf Fix For: JBossAS-4.2.3.GA I have a bean with a @OneToMany relation mapping like private List<TherapieeinheitBean> therapieeinheiten; @OneToMany( cascade = {CascadeType.REFRESH}, fetch = FetchType.EAGER, mappedBy="therapiekatalog" ) with FetchType.EAGER and a simnple @PostLoad like @PostLoad public void postLoad() { System.out.println("!!!!!!!!!! postLoad !!!!!!!!!!"); System.out.print("size: " + therapieeinheiten.size()); } When an entity of this bean is loaded JBoss trows org.hibernate.LazyInitializationException: illegal access to loading collection at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:341) at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86) at org.hibernate.collection.PersistentBag.iterator(PersistentBag.java:249) at de.visiodesk.therapiekatalog.TherapiekatalogBean.postLoad(TherapiekatalogBean.java:170) . . . and prints the messages WARN [LoadContexts] fail-safe cleanup (collections) : org.hibernate.engine.loading.CollectionLoadContext@2c8ce9<rs=Ingres-ResultSet[18523]> WARN [CollectionLoadContext] On CollectionLoadContext#cleanup, localLoadingCollectionKeys contained [206] entries afterwards. The PostLoad method should be called after the data was completely loaded. Is there a workaround for this Problem? I found some other ressources on the net where peole had the same problem, but I saw no resolution, no hint, no workaround. -- 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, 1 month

9
15
0 / 0

[JBoss JIRA] Created: (JBREM-1182) Update testsuite to run under Hudson

by Richard Achmatowicz (JIRA)

Update testsuite to run under Hudson -------------------------------------- Key: JBREM-1182 URL: https://jira.jboss.org/jira/browse/JBREM-1182 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: general Affects Versions: 2.2.3.SP1 Reporter: Richard Achmatowicz Fix For: 2.2.3.SP2 Update the JBoss Remoting testsuite to run under Hudson. Some current problems include: (i) on Linux, JRunit based tests are failing due to members not finding each other (ii) on Linux, under JDK6, JRunit based tests are not able to create a JGroups stack (iii) JRunit system properties specified by the user on the command line are not being passed the the JUnit targets correctly, and so have no effect on the tests -- 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, 1 month

2
25
0 / 0

[JBoss JIRA] Created: (JBAS-8771) Async log handler doesn't work

by David Lloyd (JIRA)

Async log handler doesn't work ------------------------------ Key: JBAS-8771 URL: https://issues.jboss.org/browse/JBAS-8771 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Logging Reporter: David Lloyd Assignee: David Lloyd Fix For: 6.0.0.Final Async log handler doesn't work. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-8389) Issue in using ThreadLocal

by Arunsakthi Kalyanasundharam (JIRA)

Issue in using ThreadLocal -------------------------- Key: JBAS-8389 URL: https://jira.jboss.org/browse/JBAS-8389 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Java EE APIs Affects Versions: JBossAS-4.2.2.GA Environment: Application Server - Garbage collection Reporter: Arunsakthi Kalyanasundharam Assignee: Shelly McGowan Fix For: JBossAS-4.2.3.GA I'm using Threadlocal in a web component. By definition, threadlocal variables should be cleared by end of execution of the thread. In case Application server, since its using a thread pool, the threadlocal variables are not cleared / garbage collected. This is leading to memory leakage (out of memory errors) and inconsistent behavior of the application since the variables are not getting cleared off. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-5559) Example MC configuration for JBossCache instance with JDBCCacheLoader

by Galder Zamarreno (JIRA)

Example MC configuration for JBossCache instance with JDBCCacheLoader --------------------------------------------------------------------- Key: JBAS-5559 URL: http://jira.jboss.com/jira/browse/JBAS-5559 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation, JBoss Cache Reporter: Galder Zamarreno Assigned To: Galder Zamarreno Priority: Minor Include an example on how to configure a JBossCache instance's JDBCCacheLoader via MC. -- 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, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-1290) Windows 7 might throw SocketException instead of BindException

by Manuel Dominguez Sarmiento (JIRA)

Windows 7 might throw SocketException instead of BindException -------------------------------------------------------------- Key: JGRP-1290 URL: https://issues.jboss.org/browse/JGRP-1290 Project: JGroups Issue Type: Enhancement Affects Versions: 2.12 Environment: Windows 7 Reporter: Manuel Dominguez Sarmiento Assignee: Bela Ban Priority: Minor This is not actually a JGroups bug, it's more of a Sun JVM bug. See the following: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6939037 In short, when a port is in use in Windows 7, SocketException is thrown instead of the more specific BindException. JGroups has code in several places that probes for available ports. Perhaps Windows 7 should be detected, and SocketException be caught instead of BindException in these circumstances. Before anyone cries out "get a real OS", we use RHEL on our production servers, but some of our developers use Windows 7 on their development boxes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

2
11
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 February 2011