August 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-5804) Remove the setting of the "types" property in the appserver config

by Adrian Brock (JIRA)

Remove the setting of the "types" property in the appserver config ------------------------------------------------------------------ Key: JBAS-5804 URL: https://jira.jboss.org/jira/browse/JBAS-5804 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Deployers Reporter: Adrian Brock Assignee: Ales Justin Fix For: JBossAS-5.0.0.CR2 Remove the <property name="type"> from the deployers config in JBossAS, e.g. <bean name="AppClientParsingDeployer" class="org.jboss.ejb3.deployers.AppClientParsingDeployer"> <property name="type">car</property> The type should be set through the managed deployment api. Remove any use of Deployment[Context|Unit].get/setType() from the JBossAS code (creating JIRA issues where necessary for replacement). -- 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, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCOMMON-62) StringPropertyReplacer elides missing properties if it finds others

by Brian Stansberry (JIRA)

StringPropertyReplacer elides missing properties if it finds others ------------------------------------------------------------------- Key: JBCOMMON-62 URL: https://jira.jboss.org/jira/browse/JBCOMMON-62 Project: JBoss Common Issue Type: Bug Security Level: Public (Everyone can see) Components: common-core (2.x) Affects Versions: 2.2.7.GA Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 2.2.8.GA Attachments: StringPropertyReplacerUnitTestCase.java Per the StringPropertyReplacer javadoc, an unresolved property should not be replaced: * Go through the input string and replace any occurance of ${p} with * the System.getProperty(p) value. If there is no such property p defined, * then the ${p} reference will remain unchanged. This works properly if the entire string being parsed does not include properties that are successfully matched, but if a property is matched, any missing property is elided. StringPropertyReplacer.replaceProperties("${java.io.tmpdir}${bogus.property}") should return /tmp${bogus.property} . Currently it returns /tmp. Attached StringPropertyReplacerUnitTestCase.testPartialMissing() shows the problem. -- 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, 8 months

1
4
0 / 0

[JBoss JIRA] Created: (BPEL-291) Document JBoss AS deployment order feature which causes exceptions upon restart

by Alejandro Guizar (JIRA)

Document JBoss AS deployment order feature which causes exceptions upon restart ------------------------------------------------------------------------------- Key: BPEL-291 URL: http://jira.jboss.com/jira/browse/BPEL-291 Project: JBoss jBPM BPEL Issue Type: Task Security Level: Public (Everyone can see) Components: Documents Affects Versions: jBPM BPEL 1.1 GA Reporter: Alejandro Guizar Assigned To: Alejandro Guizar Fix For: jBPM BPEL 1.1.1 There is an issue with the deployment order in JBoss AS which results in exceptional behavior upon server restart: WARs are deployed before EARs. The jBPM BPEL classes are deployed in an EAR, whereas the web services provided by each process definition are deployed as WARs. Upon restart, the service WARs get deployed before jbpm-bpel.ear, causing ClassNotFoundExceptions to be thrown around. There is no way to fix this on the jBPM side, as it is a JBoss AS *feature*. Fortunately it is easy to change the deployment order in JBoss AS. See the following wiki page for a full description. http://wiki.jboss.org/wiki/Wiki.jsp?page=MainDeployerEnhancedSuffixOrder The quick and direct solution is: 1. Edit <jboss_server_profile>/conf/xmdesc/org.jboss.deployment.MainDeployer-xmbean.xml 2. Look for attribute EnhancedSuffixOrder 3. Insert suffix jbpm-bpel.ear anywhere you see fit, *before* the .war suffix. For example: 250:.rar,300:-ds.xml,400:.jar,450:jbpm-bpel.ear,500:.war,550:.jse,650:.ear,800:.bsh Et voilà, jbpm-bpel.ear will be deployed before the .war modules, without affecting the deployment order of other modules. This adjustement must be documented in the user guide. -- 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, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-5260) Console deployed before JMS Destinations, needs a BarrierService to guarantee console is deployed last

by Mark Spritzler (JIRA)

Console deployed before JMS Destinations, needs a BarrierService to guarantee console is deployed last ------------------------------------------------------------------------------------------------------ Key: JBAS-5260 URL: http://jira.jboss.com/jira/browse/JBAS-5260 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Mark Spritzler -- 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, 8 months

4
3
0 / 0

[JBoss JIRA] Created: (JBRULES-1706) Refactor security authenticator

by Jervis Liu (JIRA)

Refactor security authenticator ------------------------------- Key: JBRULES-1706 URL: https://jira.jboss.org/jira/browse/JBRULES-1706 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 5.0.0.M2 Reporter: Jervis Liu Assignee: Jervis Liu Refactor security authenticator, seperate out the authorization code, so that users can use whatever authentication mechanism they perfer (e.g., ldap) to do the authentication. We also want to use the Role-based authorization by default. -- 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, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1418) Create Client Assembly for EJB3 Common

by Andrew Lee Rubinger (JIRA)

Create Client Assembly for EJB3 Common -------------------------------------- Key: EJBTHREE-1418 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1418 Project: EJB 3.0 Issue Type: Task Components: common Reporter: Andrew Lee Rubinger Assigned To: Andrew Lee Rubinger Priority: Blocker Fix For: AS 5.0.0.CR1 With the integration of EJB3 Proxy into Core, classes from EJB3 Common are required: For example: java.lang.NoClassDefFoundError: org/jboss/ejb3/common/registrar/spi/NotBoundException -- 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, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBWEB-108) Please update JDT Compiler or provide a JCI compiler

by Mark Proctor (JIRA)

Please update JDT Compiler or provide a JCI compiler ---------------------------------------------------- Key: JBWEB-108 URL: http://jira.jboss.com/jira/browse/JBWEB-108 Project: JBoss Web Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Mark Proctor Assigned To: Mladen Turk Tomcat uses a very old version of the JDT Compiler, not supported by the commons JCI compiler adapter. This means that Drools has to use the Janino compiler, which is not JDK1.5 compliant. If you where to use JCI itself you would benefit from a pluggable compiler interface. I'd also recommend not polluting the user classpath space with tomcat dependencies. -- 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, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-5643) MainDeployer MBean methods don't work in JBoss 5.0 Beta4

by Wolfgang Knauf (JIRA)

MainDeployer MBean methods don't work in JBoss 5.0 Beta4 -------------------------------------------------------- Key: JBAS-5643 URL: http://jira.jboss.com/jira/browse/JBAS-5643 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployers Affects Versions: JBossAS-5.0.0.Beta4 Environment: JDK 1.6.0_05, Windows XP64 Reporter: Wolfgang Knauf Assigned To: Ales Justin I know that the deployment was reworked, but I don't know which impacts this had on the MainDeployer MBean. At least it seems to be quite non-functional This is the state of the MainDeployer: -operation "listDeployed" and others just return nothing -"isDeployed (string)" works for a URL "file:/C:/temp/jboss-5.0.0.Beta4/server/default/deploy/KuchenZutatNM.ear", but not for "vfs:/C:/temp/jboss-5.0.0.Beta4/server/default/deploy/KuchenZutatNM.ear" -"undeploy" and others don't work for any of the above URLs, both result in a console output "21:11:45,890 WARN [MainDeployer] undeploy 'file:/C:/temp/jboss-5.0.0.Beta4/server/default/deploy/KuchenZutatNM.ear' : package not deployed" I created a small plugin for Eclipse WTP which tries to undeploy a module and waits for successful deployment of new modules, and this plugin does not work at all with JBoss 5. Probably I need to change it to use the new deployers, but I didn't find a hint to them. -- 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, 8 months

3
8
0 / 0

[JBoss JIRA] Created: (JBAS-4382) EnterpriseContext lock counting is not synchronized

by Adrian Brock (JIRA)

EnterpriseContext lock counting is not synchronized --------------------------------------------------- Key: JBAS-4382 URL: http://jira.jboss.com/jira/browse/JBAS-4382 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB2 Reporter: Adrian Brock Assigned To: Scott M Stark Fix For: JBossAS-4.2.0.GA The lock counting in org.jboss.ejb.EnterpriseContext is not synchronized. The lock ivar is not even volatile. This variable needs replacing with synchronized method blocks or an oswego concurrent SynchronizedInt. This bug could either cause passivation to be invoked when it shouldn't or vice versa. Additionally, even with this fix, the usage in StatefulSessionInstanceInterceptor needs replacing with something more atomic! if (!ctx.isLocked()) { //take it! ctx.lock(); } -- 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, 8 months

3
5
0 / 0

[JBoss JIRA] Created: (BPEL-290) Update examples to the WS-BPEL 2.0 OASIS Standard

by Alejandro Guizar (JIRA)

Update examples to the WS-BPEL 2.0 OASIS Standard ------------------------------------------------- Key: BPEL-290 URL: http://jira.jboss.com/jira/browse/BPEL-290 Project: JBoss jBPM BPEL Issue Type: Task Security Level: Public (Everyone can see) Components: Engine Affects Versions: jBPM BPEL 1.1 GA Reporter: Alejandro Guizar Assigned To: Alejandro Guizar jBPM BPEL 1.1.GA was upgraded to support the definitive WS-BPEL 2.0 OASIS Standard. However, due to time constraints, the examples were not verified to match this version. They need to be updated and verified to conform to BPEL 2 final. -- 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, 8 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2008