March 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-9001) Improper/possible duplicate module naming for commons-collections

by David Lloyd (JIRA)

Improper/possible duplicate module naming for commons-collections ----------------------------------------------------------------- Key: JBAS-9001 URL: https://issues.jboss.org/browse/JBAS-9001 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 7.0.0.Beta2 We have: {noformat} <module-def name="commons-collections.commons-collections"> <maven-resource group="commons-collections" artifact="commons-collections" /> </module-def> {noformat} This module should be called "org.apache.commons.collections", with all references updated accordingly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-8982) Rename module "javax.servlet.jstl" to "javax.servlet.jstl.api" for consistency with other javax APIs

by David Lloyd (JIRA)

Rename module "javax.servlet.jstl" to "javax.servlet.jstl.api" for consistency with other javax APIs ---------------------------------------------------------------------------------------------------- Key: JBAS-8982 URL: https://issues.jboss.org/browse/JBAS-8982 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 7.0.0.Beta2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-9017) Support for application.xml

by David Lloyd (JIRA)

Support for application.xml --------------------------- Key: JBAS-9017 URL: https://issues.jboss.org/browse/JBAS-9017 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 7.0.0.Beta2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-8920) Deployment fails with empty classpath manifest

by Max Rydahl Andersen (JIRA)

Deployment fails with empty classpath manifest ---------------------------------------------- Key: JBAS-8920 URL: https://issues.jboss.org/browse/JBAS-8920 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 7.0.0.Alpha2 Reporter: Max Rydahl Andersen Assignee: David Lloyd If you war has a MANIFEST.MF with empty classpath you get an error even though empty Class-Path: is present (and afaik valid). This is btw. how Eclipse defaults to create a war with no jar dependencies thus it would fail for a lot of folks ;) 11:53:53,682 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Starting deployment of "jbossas7-deploy-example.war" 11:53:53,706 WARN [org.jboss.vfs] (MSC service thread 1-1) VFS was unable to set the URLStreamHandlerFactory. This will have unpredictable results 11:53:53,731 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001:Failed to start service jboss.deployment.unit."jbossas7-deploy-example.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."jbossas7-deploy-example.war".PARSE: Failed to process phase PARSE of deployment "jbossas7-deploy-example.war" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:109) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1367) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_22] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_22] at java.lang.Thread.run(Thread.java:680) [:1.6.0_22] Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Class Path entry in "/content/jbossas7-deploy-example.war" not found. at org.jboss.as.server.deployment.module.ManifestClassPathProcessor.deploy(ManifestClassPathProcessor.java:123) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:103) ... 4 more I'm attaching a simple war showing this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-9002) Module rename "org.hibernate.hibernate" -> "org.hibernate"

by David Lloyd (JIRA)

Module rename "org.hibernate.hibernate" -> "org.hibernate" ---------------------------------------------------------- Key: JBAS-9002 URL: https://issues.jboss.org/browse/JBAS-9002 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 7.0.0.Beta2 Update module and all references accordingly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-9007) Rename module "junit.junit" to "org.junit"

by David Lloyd (JIRA)

Rename module "junit.junit" to "org.junit" ------------------------------------------ Key: JBAS-9007 URL: https://issues.jboss.org/browse/JBAS-9007 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Priority: Minor -- 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-9031) @EJB injection on a field/method in a Servlet/Filter class' superclass doesn't work

by jaikiran pai (JIRA)

@EJB injection on a field/method in a Servlet/Filter class' superclass doesn't work ----------------------------------------------------------------------------------- Key: JBAS-9031 URL: https://issues.jboss.org/browse/JBAS-9031 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 7.0.0.Beta1 Environment: JBoss AS7 master and JBoss AS 7.0Beta1 Reporter: jaikiran pai Assignee: jaikiran pai Consider the following servlet {code} public class SampleServlet extends BaseServlet{ .... } public class BaseServlet extends HttpServlet { @EJB private SomeEJB bean; ... } {code} The @EJB injection on the super class doesn't take place and the field stays null. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2928) Open file leak in Drools Compiler

by Chris Selwyn (JIRA)

Open file leak in Drools Compiler --------------------------------- Key: JBRULES-2928 URL: https://issues.jboss.org/browse/JBRULES-2928 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.1.0.FINAL Environment: Glassfish 2.1 Reporter: Chris Selwyn Assignee: Mark Proctor I am running Drools (actually JBoss Rules 5.1.0 ) in Glassfish. My deployable is an EJB that uses a StatelessKnowledgeSession to run some rules that I get from a KnowledgeAgent that has a Changeset with a .drl in it. Therefore, I have placed the drools compiler into the deployable and it all appears to work. Glassfish has a clever little mechanism that, when you unload a deployable that had some open streams, it tells you all about it (and kindly closes them). Glassfish is reporting that InputStreams are being left open that were opened in the isPackage() method of org.drools.commons.jci.compilers.EclipseJavaCompiler. That method has the following code in it:- final InputStream is = pClassLoader.getResourceAsStream(ClassUtils.convertClassToResourcePath(pClazzName)); if (is != null) { return false; } So, when "is" is not null (i.e. open), it is forgotten about and not closed. Isn't this a potential file handle leak? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-9030) throw TransactionRequiredException for remove/merge/persist/refresh without a transaction on transactional scope entity manager (JPA 7.9.1)

by Scott Marlow (JIRA)

throw TransactionRequiredException for remove/merge/persist/refresh without a transaction on transactional scope entity manager (JPA 7.9.1) ------------------------------------------------------------------------------------------------------------------------------------------- Key: JBAS-9030 URL: https://issues.jboss.org/browse/JBAS-9030 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Scott Marlow Assignee: Scott Marlow fix is on my branch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-1305) Configurator: sanity check dosn't take order of protocols into account

by Bela Ban (JIRA)

Configurator: sanity check dosn't take order of protocols into account ---------------------------------------------------------------------- Key: JGRP-1305 URL: https://issues.jboss.org/browse/JGRP-1305 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 2.12.1 When we run a sanity check on all protocols when creating the stack, we don't take order into account: for example, if NAKACK is *above* STABLE, we don't throw an exception ! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
1
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 2011