[jBPM Development] - Automated upgrade procedure
by alex.guizar＠jboss.com
Related issue: JBPM-2509
Ant target upgrade.jbpm.schema will:
* create the appropriate hibernate.cfg.xml file based on a property called "database"
* invoke the upgrade tool
The tool in turn will:
* run the update script that corresponds to the target database
* initialize the nextid property from the id generator
* add langid property to every deployed process
Future releases may need to add further steps, or end users may want to add extra steps. I'd prefer the steps listed under "tool" were scripted - possibly right there in install/build.xml. In this case each step would be a separate Ant task (upgrade-db, initialize-next-id, add-lang-id). Doing so has the side benefit of preventing the tool from becoming a monolithic, non-cohesive class as new steps are introduced.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258783#4258783
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258783
15 years, 3 months
[jBPM Development] - Re: parser for each jpdl release
by kukeltje
"tom.baeyens(a)jboss.com" wrote : "kukeltje" wrote : Ok, the 'parking' of older parsers makes sense. I do have som questions though
| | - A version is not only the parser but also accompanying activity implementations. These are instantiated once a process is started (from what I understand). Does this have implications?
| |
|
| very true ! that's the tricky thing i ran into yesterday.
|
| so now i think we should aim for the following approach:
|
| * make sure that we can know the version of each process when we parse it. this can be a bit tricky, because 1) we do not enforce people to specify namespace, so when deploying a process, the current library version somehow has to be added in to the db.
|
I disagree. We should just enforce the namespace(declaration) That is what it is for.
"tom.baeyens(a)jboss.com" wrote : and another issue is this: if we use the namespace for knowing the version, then this is also used to activate or not activate the xml validation. so we could end up with the situation that an invalid process deploys because originally the namespace was not present.
|
| if we then add the namespace before we save it in the deployment, then when loading it from the db it contains the namespace and that will activate validation. and hence the process can not be used. given that we use a cache after deployment, this kind of problem might not show up in test environments.
|
Then don't add it, but (unfortunately) assume that every deployed process without a namespace declaration is 4.0 or 4.1.
"tom.baeyens(a)jboss.com" wrote :
|
| * introduce a couple of if-then-else statements in the parser that depend on the version
|
| * the hard part is testing. i'm still trying to find how to we test this? how can we make sure that old deployed processes will still work correctly in newer versions of jBPM.
|
| i've been thinking about making sure that we run the test suite with a version parameter. then all the processes in the testsuite which don't have an explicit namespace, will use the configured parser version.
|
| but i'm not yet sure if this tests what we actually need. and to what extend it protects us from making backwards incompatible changes.
|
| if we get this wrong, the risk is that we break existing installations after they upgrade.
|
|
Yes, this is *the* challenge. But I'd use a namespace declaration for this. If none is there, assume 4.1. For the testing itself, maybe there is an option to use the tagged
svn) testcases for a specific version and run them against the latest jbpm release. This would prevent an explosion of the number of testcases that we need (to duplicate?) in the source.
"tom.baeyens(a)jboss.com" wrote :
|
| "kukeltje" wrote : - Currently the schema is not fully 'any:any' aware. (I still think it should be 'other:any' for the extensibility. Fully supporting this is needed if you automatically want to add a namespace since people can remove the ns now if they want to add custom attributes.
| |
|
| if you declare extensibility with any:any, then users can *still* define all their extensions in their own namespace. they are just not forced to do it if they want to.
|
| Again I strongly disagree. What if they extend some things and we start using the same tags? I *hate* the any:any. It was probably introduced (read forced upon us) in some weird way by a company that already developed something for it's customers. Just like with BPMN2 ;-)
"tom.baeyens(a)jboss.com" wrote :
| why do think users *need* to define their extensions in a separate namespace. i agree that it would be good practice from a user perspective. but i don't see a reason why we should enforce our users to it like that.
|
| to prevent future element/tag clashes, to be explicit (I love explicit things, no.... I hate implicit things. Probably because it is one of the (few) negative aspects of females. Saying one thing but implying another.... "tom.baeyens(a)jboss.com" wrote :
|
| "kukeltje" wrote : - Does this mean that people have to redeploy their old processes if they want to take advantage of certain bugfixes in e.g. activity implementations?
|
| that's the kind of questions that we have to ask ourselves when composing a solution.
|
What about an activities file per jpdl version? If we know we are breaking backwards compatibility (testcases of previous version failing against the latest source) , we create a new activities class which extends the previous one and we e.g. introduce a version number in the packagename and put that in the new activities file? (I was dreaming when I wrote this, forgive me if it goes astray
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258764#4258764
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258764
15 years, 3 months
[JCA Development] - Re: Design of ConnectionManager API
by jesper.pedersen
The package
| org.jboss.jca.core.api
|
represents the public API for our JCA implementation. Hence it is important that we only expose what we will support over time.
The package will mostly consist of interfaces - as the implementation details should be hidden from the caller.
I think for now that only the
| org.jboss.jca.core.api.ConnectionManager
|
should remain in the package - without any methods defined. Just to define our top-level interface.
E.g. RealConnectionManager should be moved to the implementation package - it currently also creates a dependency on the implementation JAR, which an API JAR can't have. Its all or nothing ;)
Its better to start with the data structures in the implementation and move them out to the API if there are use-cases for it.
A good rule of thumb is to ask:
* Do I want users to call this method ?
* Do I want to expose this attribute as a bean property ?
HTH
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258748#4258748
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258748
15 years, 3 months
[JBoss AS Development] - Property scanWars causes DeploymentException on admin-consol
by s3filho
Hello Everyone,
In order to deploy EJB classes inside my WAR application (folder WEB-INF/classes) I changed the property "scanWars" inside
the file "deployers/ejb3.deployer/META-INF/ejb3-deployers-jboss-beans.xml"
| <!-- Should war deployments be scanned for annotated ejbs -->
| <property name="scanWars">true</property>
|
After doing that, my JBoss Administration Console (and other web applications) do not start anymore.
Error:
| 15:27:41,292 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/D:/jboss-5.1.0.GA/server/default/deploy/admin-console.war/ state=PreReal mode=Manual requiredState=Real
| org.jboss.deployers.spi.DeploymentException: Error deploying admin-console.war: failed to initialize bean container
| at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
| at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
| at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
| at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
| at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
| at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
| at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
| at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
| at org.jboss.Main.boot(Main.java:221)
| at org.jboss.Main$1.run(Main.java:556)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.lang.RuntimeException: failed to initialize bean container
| at org.jboss.ejb3.EJBContainer.<init>(EJBContainer.java:253)
| at org.jboss.ejb3.session.SessionContainer.<init>(SessionContainer.java:119)
| at org.jboss.ejb3.session.SessionSpecContainer.<init>(SessionSpecContainer.java:69)
| at org.jboss.ejb3.stateless.StatelessContainer.<init>(StatelessContainer.java:112)
| at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
| at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:203)
| at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:718)
| at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:669)
| at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:651)
| at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:614)
| at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
| at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
| ... 33 more
| Caused by: java.lang.IllegalStateException: Null beannMetaData
| at org.jboss.ejb3.interceptors.metadata.BeanInterceptorMetaDataBridge.setupMetaDataLists(BeanInterceptorMetaDataBridge.java:315)
| at org.jboss.ejb3.interceptors.metadata.BeanInterceptorMetaDataBridge.initialise(BeanInterceptorMetaDataBridge.java:235)
| at org.jboss.ejb3.interceptors.metadata.BeanInterceptorMetaDataBridge.<init>(BeanInterceptorMetaDataBridge.java:138)
| at org.jboss.ejb3.interceptors.metadata.AdditiveBeanInterceptorMetaDataBridge.<init>(AdditiveBeanInterceptorMetaDataBridge.java:48)
| at org.jboss.ejb3.aop.BeanContainer.initialize(BeanContainer.java:194)
| at org.jboss.ejb3.EJBContainer.<init>(EJBContainer.java:249)
| ... 44 more
| Caused by: java.lang.NullPointerException
| at org.jboss.ejb3.interceptors.metadata.BeanInterceptorMetaDataBridge.setupMetaDataLists(BeanInterceptorMetaDataBridge.java:268)
| ... 49 more
|
Does anyone know if this is a JBoss Error or I was not supposed to change that file it all?
I've only change that property because by default JBoss doesn't search my annotated EJB classes inside WEB-INF/classes.
Thank you very much
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258720#4258720
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258720
15 years, 3 months
[JBoss AS Development] - Property
by s3filho
Hello Everyone,
In order to deploy EJB classes inside my WAR application (folder WEB-INF/classes) I changed the property "scanWars" inside
the file "deployers/ejb3.deployer/META-INF/ejb3-deployers-jboss-beans.xml"
| <!-- Should war deployments be scanned for annotated ejbs -->
| <property name="scanWars">true</property>
|
After doing that, my JBoss Administration Console (and other web applications) do not start anymore.
Error:
| 15:27:41,292 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/D:/jboss-5.1.0.GA/server/default/deploy/admin-console.war/ state=PreReal mode=Manual requiredState=Real
| org.jboss.deployers.spi.DeploymentException: Error deploying admin-console.war: failed to initialize bean container
| at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
| at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
| at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
| at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
| at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
| at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
| at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
| at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
| at org.jboss.Main.boot(Main.java:221)
| at org.jboss.Main$1.run(Main.java:556)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.lang.RuntimeException: failed to initialize bean container
| at org.jboss.ejb3.EJBContainer.<init>(EJBContainer.java:253)
| at org.jboss.ejb3.session.SessionContainer.<init>(SessionContainer.java:119)
| at org.jboss.ejb3.session.SessionSpecContainer.<init>(SessionSpecContainer.java:69)
| at org.jboss.ejb3.stateless.StatelessContainer.<init>(StatelessContainer.java:112)
| at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
| at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:203)
| at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:718)
| at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:669)
| at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:651)
| at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:614)
| at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
| at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
| ... 33 more
| Caused by: java.lang.IllegalStateException: Null beannMetaData
| at org.jboss.ejb3.interceptors.metadata.BeanInterceptorMetaDataBridge.setupMetaDataLists(BeanInterceptorMetaDataBridge.java:315)
| at org.jboss.ejb3.interceptors.metadata.BeanInterceptorMetaDataBridge.initialise(BeanInterceptorMetaDataBridge.java:235)
| at org.jboss.ejb3.interceptors.metadata.BeanInterceptorMetaDataBridge.<init>(BeanInterceptorMetaDataBridge.java:138)
| at org.jboss.ejb3.interceptors.metadata.AdditiveBeanInterceptorMetaDataBridge.<init>(AdditiveBeanInterceptorMetaDataBridge.java:48)
| at org.jboss.ejb3.aop.BeanContainer.initialize(BeanContainer.java:194)
| at org.jboss.ejb3.EJBContainer.<init>(EJBContainer.java:249)
| ... 44 more
| Caused by: java.lang.NullPointerException
| at org.jboss.ejb3.interceptors.metadata.BeanInterceptorMetaDataBridge.setupMetaDataLists(BeanInterceptorMetaDataBridge.java:268)
| ... 49 more
|
Does anyone know if this is a JBoss Error or I was not supposed to change that file it all?
I've only change that property because by default JBoss doesn't search my annotated EJB classes inside WEB-INF/classes.
Thank you very much
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258717#4258717
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258717
15 years, 3 months