[JBoss JIRA] Updated: (JBPM-504) improve sub process variable handling and make variable method names consistent
by Tom Baeyens (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-504?page=all ]
Tom Baeyens updated JBPM-504:
-----------------------------
Fix Version/s: jBPM jPDL 3.2.1
(was: jBPM jPDL 3.2)
i think methods should be added, but no methods should be removed. to not force people to update their code.
max, we could make the old methods deprecated.
since i don't want the fix for this to remove any methods, (and i want to release 3.2 asap), i moved this item to 3.2.1
> improve sub process variable handling and make variable method names consistent
> -------------------------------------------------------------------------------
>
> Key: JBPM-504
> URL: http://jira.jboss.com/jira/browse/JBPM-504
> Project: JBoss jBPM
> Issue Type: Feature Request
> Components: Core Engine
> Reporter: Tom Baeyens
> Assigned To: Tom Baeyens
> Fix For: jBPM jPDL 3.2.1
>
>
> 1) improve sub process variables:
> maybe a sub process could specify in it's definition what variables are delegated to the super process. e.g.
> <process-definition...>
> <super-process-variables>
> <variable name="..." access="..." mapped-name="..." />
> <variable name="..." access="..." mapped-name="..." />
> <variable name="..." access="..." mapped-name="..." />
> ...
> </super-process-variables>
> ...
> that would make it easier to write reusable subprocesses. by default, the variable-lookups could propagate from sub-process to super-process.
> but for variable creation and variable setting, things are a bit more complicated : you cannot just propagate variable creation to a super process.
> 2) make variable method names more consistent:
> getVariable
> getVariables
> getVariableLocally
> hasVariable
> setVariable
> setVariables
> setVariableLocally
> createVariable should be replaced with setVariableLocally
> addVariables should be replaced with setVariables
> setVariables should be interpreted as a Collections.addAll(): no functionality should be provided for the replacement of the variables map as in a bean-style setter.
--
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, 2 months
[JBoss JIRA] Updated: (JBCACHE-315) Break locks for state transfer
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-315?page=all ]
Manik Surtani updated JBCACHE-315:
----------------------------------
Fix Version/s: 2.1.0.GA
(was: 2.0.0.GA)
needs further thought
> Break locks for state transfer
> ------------------------------
>
> Key: JBCACHE-315
> URL: http://jira.jboss.com/jira/browse/JBCACHE-315
> Project: JBoss Cache
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assigned To: Vladimir Blagojevic
> Priority: Critical
> Fix For: 2.1.0.GA
>
>
> State transfer needs to acquire a lock on the root to make sure all existing TXs have been completed. However, when a TX takes more time than the lock acquisition timeout, state transfer will fail.
> Therefore, we need to forcefully acquire the locks for the state transfer by force-releasing the existing locks, and rolling back all TXs that held those locks.
> This will ensure that state transfer always succeeds, at the expense of some rolled back TXs.
> We need to investigate how this works with optimistic locking
--
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, 2 months
[JBoss JIRA] Created: (JBAS-4173) Deployment descriptor does not allow namespace prefixes
by Oskar Carlstedt (JIRA)
Deployment descriptor does not allow namespace prefixes
-------------------------------------------------------
Key: JBAS-4173
URL: http://jira.jboss.com/jira/browse/JBAS-4173
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment services
Affects Versions: JBossAS-4.0.5.GA
Environment: Probably all, discovered on JBoss 4.0.5GA on Windows Vista Enterprise Edition
Reporter: Oskar Carlstedt
Assigned To: Dimitris Andreadis
I tried to deploy an auto generated deployment descriptor (ejb-jar.xml). Due to autogenerating with xmlbeans all elements were prefixed with "j2ee:". I attach the file in this message. When removing all prefixes, the deploy works fine.
<?xml version="1.0" encoding="UTF-8"?>
<j2ee:ejb-jar version="2.1" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee">
<j2ee:display-name>SomeEjb</j2ee:display-name>
<j2ee:enterprise-beans>
<j2ee:session>
<j2ee:ejb-name>SomeEjb</j2ee:ejb-name>
<j2ee:service-endpoint>some.service.Endpoint</j2ee:service-endpoint>
<j2ee:ejb-class>some.service.impl.EnpointImpl</j2ee:ejb-class>
<j2ee:session-type>Stateless</j2ee:session-type>
<j2ee:transaction-type>Container</j2ee:transaction-type>
</j2ee:session>
</j2ee:enterprise-beans>
<j2ee:assembly-descriptor>
<j2ee:method-permission>
<j2ee:unchecked/>
<j2ee:method>
<j2ee:ejb-name>SomeEjb</j2ee:ejb-name>
<j2ee:method-name>*</j2ee:method-name>
</j2ee:method>
</j2ee:method-permission>
<j2ee:container-transaction>
<j2ee:method>
<j2ee:ejb-name>SomeEjb</j2ee:ejb-name>
<j2ee:method-name>*</j2ee:method-name>
</j2ee:method>
<j2ee:trans-attribute>Required</j2ee:trans-attribute>
</j2ee:container-transaction>
</j2ee:assembly-descriptor>
</j2ee:ejb-jar>
Deploying this file will case the deployer to throw an exception.
00:59:30,333 ERROR [MainDeployer] Could not create deployment: file:/C:/Java/jboss-4.0.5.GA/server/default/deploy/.......jar
org.jboss.deployment.DeploymentException: expected one enterprise-beans tag
at org.jboss.metadata.MetaData.getUniqueChild(MetaData.java:113)
at org.jboss.metadata.ApplicationMetaData.importEjbJarXml(ApplicationMetaData.java:371)
at org.jboss.metadata.XmlFileLoader.load(XmlFileLoader.java:166)
at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:541)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.inteceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
at org.jboss.ws.integration.jboss.DeployerInterceptor.create(DeployerInterceptor.java:74)
at org.jboss.ws.integration.jboss.DeployerInterceptorEJB.create(DeployerInterceptorEJB.java:44)
at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180)
at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy28.create(Unknown Source)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy8.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:610)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
...
--
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, 2 months