November 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBMICROCONT-9) Bean Deployer

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-9?page=all ] Scott M Stark closed JBMICROCONT-9. ----------------------------------- Resolution: Done > Bean Deployer > ------------- > > Key: JBMICROCONT-9 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-9 > Project: JBoss MicroContainer > Issue Type: Task > Components: Deployment > Affects Versions: JBossMC_1_0_0 final > Reporter: Adrian Brock > Fix For: JBossMC_2_0_0 Beta > > > Bean Deployer > ------------- > Structural components > accepts all deployments that have either > extension .bean with a META-INF/jboss-bean.xml > or files with extension -bean.xml > uses default subcontext processing > Deployment component > Adds the deployment url as a classpath url > Parses the -bean.xml creating the > microcontainer deployment metadata > and installs it -- 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

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMICROCONT-8) JAR Deployer

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-8?page=all ] Scott M Stark closed JBMICROCONT-8. ----------------------------------- Resolution: Done > JAR Deployer > ------------ > > Key: JBMICROCONT-8 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-8 > Project: JBoss MicroContainer > Issue Type: Task > Components: Deployment > Reporter: Adrian Brock > Fix For: JBossMC_2_0_0 Beta > > > JAR Deployer > ------------ > Structural components > accepts all deployments that have > extension jar, zip (a directory is abstracted > as a jar by the VDF if it is a top level deployment) > uses default subcontext processing > Deployment component > Adds the deployment url as a classpath url -- 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

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMICROCONT-31) ClassLoading abstraction

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-31?page=all ] Scott M Stark updated JBMICROCONT-31: ------------------------------------- Fix Version/s: JBossMC_2_0_0_CR1 (was: JBossMC_2_0_0 Beta) Need to work with additional prototypes to flesh this out further. > ClassLoading abstraction > ------------------------ > > Key: JBMICROCONT-31 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-31 > Project: JBoss MicroContainer > Issue Type: Sub-task > Components: General > Reporter: Adrian Brock > Fix For: JBossMC_2_0_0_CR1 > > > Need to come up with a classloading abstraction that isn't going to change in future. > e.g. Look at jboss-aop problem with > 3.2.x UnifiedClassLoader > 4.0.x RepositoryClassLoader > 5.0.x ??? (not even JMX based) > I think the easiest way to do this to define some simple interfaces/factories > for where this needs to be referenced from code. -- 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

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMICROCONT-7) Classloading deployer

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-7?page=all ] Scott M Stark closed JBMICROCONT-7. ----------------------------------- Resolution: Done > Classloading deployer > --------------------- > > Key: JBMICROCONT-7 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-7 > Project: JBoss MicroContainer > Issue Type: Task > Components: Deployment > Reporter: Adrian Brock > Assigned To: Scott M Stark > Fix For: JBossMC_2_0_0 Beta > > > Classloading Deployer > --------------------- > Structural component > None > Deployment component > Only acts on the top level deployment > Creates/removes a classloader for the classpath urls > identified in the top level context and its subcontexts > Additional config can come from jboss-classloading.xml > in the metadata location -- 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

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMICROCONT-6) Virtual Deployment Framework

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-6?page=all ] Scott M Stark closed JBMICROCONT-6. ----------------------------------- Resolution: Done The beta of this is complete. http://wiki.jboss.org/wiki/Wiki.jsp?page=JBoss5DeploymentFramework > Virtual Deployment Framework > ---------------------------- > > Key: JBMICROCONT-6 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-6 > Project: JBoss MicroContainer > Issue Type: Task > Components: Deployment > Reporter: Adrian Brock > Assigned To: Scott M Stark > Fix For: JBossMC_2_0_0 Beta > > > VDF - Virtual Deployment Framework > ---------------------------------- > VDF registry > The VDF registry acts as a helper/registry of the VDF contexts. > Each deployment is made up a top level VDF context > which might contain sub VDF contexts. > It does: > 1) Unpack subdeployments > 2) Download remote deployments > 3) Abstract packed/unpacked > 4) Allow config/registration of url handlers for things like webdav > 5) Supplying "directory" lists, cf (3) and (4) > VDF Context > The VDF context is a replacement for the DeploymentInfo > of current JBoss it holds the following information: > name - a name probably a shorted version of the url > deployer - the identified structural deployer > logicalURL - the url presented to the user > physicalURL - the url where it is really located > parentVDFContext - any parent VDF context (null when top level) > subVDFContexts - any subdeployments > classpath - the urls where classes are located > metainf - the location of any meta data > manifest - any manifest information > classloader - constructed by the classloading deployer > stats/state - e.g. when deployed, the state of the deployment, any errors, etc > There will be a set of utility methods that provide > other access, e.g. get me the metadata url for "ejb-jar.xml" > VDF Context - extensions > Each structural component can extend the VDF context > to add more information > There will also be a "slot" available for each > deployment component to associate some data with the deployment. > Context identification > ---------------------- > A top level deployment must have a structure deployer > subdeployments that are not explcitly identifed > (cf Default SubContext processing) that don't have > deployers are ignored. > Explicity identified subdeployments must have a > structure deployer > Default SubContext processing > ----------------------------- > All files in the root of the deployment > are treated as possible subcontexts -- 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

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3821) Uncatch JMSException in receive() methods in SpyMessageConsumer.java

by K N (JIRA)

Uncatch JMSException in receive() methods in SpyMessageConsumer.java -------------------------------------------------------------------- Key: JBAS-3821 URL: http://jira.jboss.com/jira/browse/JBAS-3821 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS service Affects Versions: JBossAS-4.0.5.GA Environment: Windows OS Reporter: K N Assigned To: Adrian Brock Priority: Critical The receive(), receive(long timeout), and receiveNoWait() methods in SpyMessageConsumer.java does not have try/catch JMSException around the "SpyMessage msg = session.connection.receive(subscription, xx)" method call. If JMSException is thrown from this method call, the boolean "receiving" will not get reset. Since the variable "receiving" will not get reset to false, if the client tries to get message off the queue in the next iteration, the receive() methods in SpyMessageConsumer will be force to perform "throw new JMSException("Another thread is already in receive.")". The only solution to the client is to close the queue connection and open a new queue connection. -- 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

19 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-770) Option to Not Signal a Sub-Process in the Process-State Node

by Jed Danner (JIRA)

Option to Not Signal a Sub-Process in the Process-State Node ------------------------------------------------------------ Key: JBPM-770 URL: http://jira.jboss.com/jira/browse/JBPM-770 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Affects Versions: jBPM 3.1.2 Environment: Feature request. Reporter: Jed Danner Assigned To: Tom Baeyens Priority: Minor I've found a case where I'd like to start a sub-process from a process but I don't want to signal it immediately. There is an external source which will handle that signalling. I've made some modifications to the ProcessState.java file, as such: Added a new class member: protected boolean signalProcess = true; Added a check in the read method: String signalText = subProcessElement.attributeValue("signal"); if (signalText!=null) { if (("no".equalsIgnoreCase(signalText)) || ("false".equalsIgnoreCase(signalText)) ) { signalProcess = false; } } Added a check in the execute method (right before the signal): if (!signalProcess) return; Added a new method: public boolean getSignalProcess() { return signalProcess; } And updated the jpdl-3.1.xsd and jpdl-3.0.xsd files (wasn't sure if I needed to do both). What I see is when the process is deployed, the read method see my new attribute and sets it to 'false' as I want. But when the process comes along and I get into the execute method the value of signalProcess is 'true'. I'm thinking there is another step I need to take but don't know what it is. If someone can take a look or provide a pointer (And finds this feature request useful) - it'd be great to have it integrated. Thanks! -- 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

19 years, 8 months

2
2
0 / 0

[JBoss JIRA] Closed: (JBPM-510) Problems redeploing jbpm.sar multiple times with JBOSS4.0.3

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-510?page=all ] Tom Baeyens closed JBPM-510. ---------------------------- Resolution: Rejected in 3.2, we're moving to .war and .ear deployments of jBPM. we'll see afterwards if a .rar (JCA resources archive) or .sar (JBoss service archive) is appropriate to add as an alternative deployment mechanism > Problems redeploing jbpm.sar multiple times with JBOSS4.0.3 > ----------------------------------------------------------- > > Key: JBPM-510 > URL: http://jira.jboss.com/jira/browse/JBPM-510 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM 3.1 beta 2 > Environment: JDK 1.5 on Solaris > Reporter: Evgueni Smoliar > Assigned To: Tom Baeyens > > there is a problem with persitance of the object org.jbpm.context.def.VariableAccess occure sometimes > If I redeploy JBPM.sar file in jboss > org.hibernate.PropertyAccessException: could not set a field value by reflection setter of org.jbpm.context.def.VariableAccess.access > at org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:82) > at org.hibernate.tuple.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:330) > at org.hibernate.tuple.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:188) -- 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

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-771) Auto-increment long primary keys for process definition and instance are not acceptable for the systems with decentralized database

by Andriy Gryn (JIRA)

Auto-increment long primary keys for process definition and instance are not acceptable for the systems with decentralized database ----------------------------------------------------------------------------------------------------------------------------------- Key: JBPM-771 URL: http://jira.jboss.com/jira/browse/JBPM-771 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Affects Versions: jBPM 3.1.3 Reporter: Andriy Gryn Assigned To: Tom Baeyens Due to different reasons (e.g. absense of the reliable communication channels) it may be necessary to support decentralized mode when there is several database servers containing partial data (e.g. one database server per region) that are replicated from time to time to the central database to build consolidated system. ProcessDefinition and ProcessInstance have now long primary key with native generator. In the scenario with decentralized database this approach will not work. Instead GUIDs could to be used as primary keys for objects that are to be consolidated to central database. It seems that currently modification required to support decentralized mode. -- 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

19 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (JBPM-772) jbpm.war does not deploy in JBoss 4.0.5.GA

by David Owens (JIRA)

jbpm.war does not deploy in JBoss 4.0.5.GA ------------------------------------------ Key: JBPM-772 URL: http://jira.jboss.com/jira/browse/JBPM-772 Project: JBoss jBPM Issue Type: Bug Components: Web Interface Affects Versions: jBPM 3.1.3 Environment: JBoss 4.0.5.GA from jems-installer-1.2.0.BETA3.jar with EJB profile. Reporter: David Owens Assigned To: Tom Baeyens If you copy the jbpm.sar folder and the jbpm.war folder from the jbpm-3.1.3 starter kit into a JBoss 4.0.5.GA deploy directory, it will not deploy. You get this error message: 18:51:20,421 INFO [SchedulerThread] runtime exception while executing timers org.hibernate.HibernateException: Could not parse configuration: hibernate.cfg.xml at org.hibernate.cfg.Configuration.doConfigure(Configuration.java:1418) at org.hibernate.cfg.Configuration.configure(Configuration.java:1352) at org.jbpm.db.hibernate.HibernateHelper.createConfiguration(HibernateHelper.java:90) at org.jbpm.persistence.db.DbPersistenceServiceFactory.getConfiguration(DbPersistenceServiceFactory.java:68) at org.jbpm.persistence.db.DbPersistenceServiceFactory.getSessionFactory(DbPersistenceServiceFactory.java:90) at org.jbpm.persistence.db.DbPersistenceService.getSessionFactory(DbPersistenceService.java:74) at org.jbpm.persistence.db.DbPersistenceService.getSession(DbPersistenceService.java:78) at org.jbpm.persistence.db.DbPersistenceService.getSchedulerSession(DbPersistenceService.java:254) at org.jbpm.JbpmContext.getSchedulerSession(JbpmContext.java:529) at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:104) at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:71) Caused by: org.dom4j.DocumentException: org.dom4j.DocumentFactory Nested exception: org.dom4j.DocumentFactory at org.dom4j.io.SAXReader.read(SAXReader.java:484) at org.hibernate.cfg.Configuration.doConfigure(Configuration.java:1408) ... 10 more Which is caused by a ClassCastException from the SAXReader. After removing the dom4j-1.6.1.jar from jbpm.war\META-INF\lib the war will deploy. -- 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

19 years, 8 months

2
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 November 2006