January 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (AS7-1972) Create nice way of registering different JNDI namespaces

by Stuart Douglas (JIRA)

Create nice way of registering different JNDI namespaces --------------------------------------------------------- Key: AS7-1972 URL: https://issues.jboss.org/browse/AS7-1972 Project: Application Server 7 Issue Type: Feature Request Components: Naming Affects Versions: 7.1.0.Alpha1 Reporter: Stuart Douglas Assignee: John Bailey As we can't really use Context.URL_PKG_PREFIXES we need some other way of registering JNDI namespaces -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
2
0 / 0

[JBoss JIRA] (AS7-2939) jar references in tmp/vfs consuming file handles

by Nicklas Karlsson (Created) (JIRA)

jar references in tmp/vfs consuming file handles ------------------------------------------------ Key: AS7-2939 URL: https://issues.jboss.org/browse/AS7-2939 Project: Application Server 7 Issue Type: Bug Components: VFS Affects Versions: 7.1.0.Beta1 Reporter: Nicklas Karlsson Assignee: John Bailey I see deployments in standalone/tmp/vfs/deployment1bdffd9028e55f79 that keep reference to multiple instances of the jars like joda-time-1.6.2.jar-38f02aa25a811ed4 joda-time-1.6.2.jar-74d1519d59ff978d joda-time-1.6.2.jar-b197315704b17d7 joda-time-1.6.2.jar-bc1bb40870af7097 3-4 of each jar and they all consume a file handle on OS level. Are they all needed? all in all, the AS takes up around 1000 file handles on 4 deployed applications, causing out of file handles-errors if more applications are deployed without raising the limits. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
1
0 / 0

[JBoss JIRA] (AS7-2035) Clean the status of testing jars for jboss-vfs

by Marek Goldmann (Created) (JIRA)

Clean the status of testing jars for jboss-vfs ---------------------------------------------- Key: AS7-2035 URL: https://issues.jboss.org/browse/AS7-2035 Project: Application Server 7 Issue Type: Task Components: VFS Reporter: Marek Goldmann Assignee: John Bailey There are some JARs in jboss-vfs test directory. Some of them are dummy jars containing plain text files, but some of them contain class files. As a general rule Fedora doesn't allow to ship binary files. Although we can have exception for jar files containing dummy files because this is required to test jboss-vfs behavior. What's the status of following files? Who wrote them and what is the license of those and where is the upstream code? ./src/test/resources/vfs/test/spring-ear.ear/lib/spring-beans.jar ./src/test/resources/vfs/test/spring-ear.ear/spring-ejb.jar Can they be replaced with something dummy? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
1
0 / 0

[JBoss JIRA] (AS7-2178) Deployment cannot create dependency on unresolved OSGi bundle

by Thomas Diesler (Created) (JIRA)

Deployment cannot create dependency on unresolved OSGi bundle ------------------------------------------------------------- Key: AS7-2178 URL: https://issues.jboss.org/browse/AS7-2178 Project: Application Server 7 Issue Type: Bug Components: OSGi Reporter: Thomas Diesler Assignee: Thomas Diesler The Module related to an OSGi bundle becomes available when the bundle transitions from INSTALLED to RESOLVED. An installed bundle is not visible to the common ModuleLoader. The solution would be to use a common resolver for both OSGi and non-OSGi deployments. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
6
0 / 0

[JBoss JIRA] Created: (AS7-1834) FS deployment scanner uses different order resulting in failing deployments

by Rico Neubauer (JIRA)

FS deployment scanner uses different order resulting in failing deployments --------------------------------------------------------------------------- Key: AS7-1834 URL: https://issues.jboss.org/browse/AS7-1834 Project: Application Server 7 Issue Type: Bug Components: Server Affects Versions: 7.0.1.Final, 7.1.0.Alpha1 Environment: Windows 7 (most probably not specific to this OS) Reporter: Rico Neubauer Assignee: Jason Greene Experiencing a different behavior in deployment depending upon deployment order. I have some OSGi bundles and one EJB-jar, which defines a dependency upon one of the bundles using: Dependencies: deployment.com.companyname.common.CompUtil:0.0.1.SNAPSHOT This works fine and everything works, when the EJB-jar gets deployed after all the OSGi-bundles are already started, see attached log server_startup_working_due_to_deployment_of_EJBs_delayed.txt However, when re-deploying all deployments, or just on a simple restart, all of the deployments fail, since it seems that this dependency leads some undefined state where in consequence also the VFS loses its mount-points, as can be seen here, where the mount point is in the start-up directory, which obviously causes a FNFEx: FileNotFoundException: D:\test\jboss-as-7.1.0.Alpha1-2011-09-12\bin\content\com.seeburger.lib.ext_1.0.0.jar\axiom-dom.jar See full log attached. Everything also works fine, when replacing the EJB-jar with an EJB-jar, which does not have any dependencies on an OSGi-bundle. In domain-mode, this problem does not arise. Bundles are started first, deployment of EJB-jar comes after. Probably in standalone-mode with manually deployed files instead of using the "deployments" folder, the problem might also not arise (untested). Config: standalone-preview jboss-as-7.1.0.Alpha1 as of 2011-09-12 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
6
0 / 0

[JBoss JIRA] Created: (JBNAME-51) Delay in connecting when first of multiple providers is down can cause performance issue

by Dennis Reed (JIRA)

Delay in connecting when first of multiple providers is down can cause performance issue ---------------------------------------------------------------------------------------- Key: JBNAME-51 URL: https://issues.jboss.org/browse/JBNAME-51 Project: JBoss Naming Issue Type: Bug Components: jnpserver Affects Versions: 5.0.3.GA Reporter: Dennis Reed org.jnp.interfaces.NamingContext.checkRef always loops through the provider list in order, trying to connect to the first before checking for a cached connection to a later provider. This affects performance because it can cause a delay on every context created, waiting for a timeout on a node that is down. For instance, the following takes a very long time when node1 is down. ... env.put ( Context.PROVIDER_URL, "node1:1100,node2:1100" ); for ( int i = 0; i < 1000; ++ i ) { InitialContext ctx = new InitialContext ( env ); ... } If checkRef looked for a cached connection to any of the listed providers before trying to connect to an uncached one, there would only be a timeout delay on the very first connection attempt. Note: This would change the behavior of the client when node1 comes back up in the middle, so would not be eligible for an EAP patch release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
7
0 / 0

[JBoss JIRA] Created: (JBAS-9177) Launch script does not work on Windows

by Max Rydahl Andersen (JIRA)

Launch script does not work on Windows --------------------------------------- Key: JBAS-9177 URL: https://issues.jboss.org/browse/JBAS-9177 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Max Rydahl Andersen Priority: Critical Launching AS 7 does not work on windows. Several issues: Quoting java_home causes error: set JAVA_HOME="C:\Program Files\Java\jdk1.6.0_24" Y:\products\jboss 7.0.0.Beta1\bin>standalone.bat Config file not found Y:\products\jboss 7.0.0.Beta1\bin\standalone.conf.bat Files\Java\jdk1.6.0_24"" was unexpected at this time. Non quoting and you get this: Y:\products\jboss 7.0.0.Beta1\bin>set JAVA_HOME=C:\Program Files\Java\jdk1.6.0_2 4 Y:\products\jboss 7.0.0.Beta1\bin>standalone.bat Config file not found Y:\products\jboss 7.0.0.Beta1\bin\standalone.conf.bat =============================================================================== JBoss Bootstrap Environment JBOSS_HOME: Y:\products\jboss 7.0.0.Beta1 JAVA: C:\Program Files\Java\jdk1.6.0_24\bin\java JAVA_OPTS: -Dprogram.name=standalone.bat -server =============================================================================== Exception in thread "main" java.lang.NoClassDefFoundError: 7/0/0/Beta1\standalon e\log\boot/log Caused by: java.lang.ClassNotFoundException: 7.0.0.Beta1\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) Could not find the main class: 7.0.0.Beta1\standalone\log\boot.log. Program wil l exit. Press any key to continue . . . And it seem to be looking for standalone.conf.bat which does not exist. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

6
13
0 / 0

[JBoss JIRA] (AS7-2676) CLI parameter prompting

by Nicklas Karlsson (Created) (JIRA)

CLI parameter prompting ----------------------- Key: AS7-2676 URL: https://issues.jboss.org/browse/AS7-2676 Project: Application Server 7 Issue Type: Feature Request Components: CLI Affects Versions: 7.1.0.Alpha1 Reporter: Nicklas Karlsson Assignee: Alexey Loubyansky Priority: Minor It could be handy if there was some mechanism for prompting for values (with included default value). That way one could have a master script that could be run for a new AS and you would be prompted for changing parameters (e.g. datsource jdbc urls, transaction timeouts etc) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
3
0 / 0

[JBoss JIRA] Created: (JBAS-8390) Allow for configuration of respawn policy in host.xml/domain.xml

by Kabir Khan (JIRA)

Allow for configuration of respawn policy in host.xml/domain.xml ---------------------------------------------------------------- Key: JBAS-8390 URL: https://jira.jboss.org/browse/JBAS-8390 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Fix For: 7.0.0.M1 The server manager currently uses the default respawn policy -- 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

13 years, 10 months

4
6
0 / 0

[JBoss JIRA] Created: (JBAS-5900) jars are not loaded from the lib directory of a sar in JBoss AS 5

by Matt Wringe (JIRA)

jars are not loaded from the lib directory of a sar in JBoss AS 5 ----------------------------------------------------------------- Key: JBAS-5900 URL: https://jira.jboss.org/jira/browse/JBAS-5900 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading Affects Versions: JBossAS-5.0.0.CR2 Reporter: Matt Wringe Assignee: Scott M Stark Attachments: testsar.tar.gz In JBoss AS 5, any jars placed in the lib directory of a sar are not loaded and results in a class not found exception. The classes are loaded if the jar is placed in the root directory of the sar. On previous versions of JBoss AS, the classes would be loaded from either location. This prevents sars that would have worked on JBoss AS 4 to fail on JBoss AS 5. Steps to reproduce: 1) take zip attached to this report. 2) deploy test-in-lib.sar to JBoss AS 5. The sar will not deploy and will fail with a classNotFoundException 3) deploy test-in-lib.sar to JBoss AS 4, the sar will deploy without issue. test-in-root.sar will work on both versions of JBoss. The only difference between these sars is the location of the jar. -- 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

13 years, 10 months

5
9
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 2012