[JBoss JIRA] Commented: (JBPM-569) improve EL expression examples in the user guide
by Arjan van Bentem (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-569?page=comments#action_12353712 ]
Arjan van Bentem commented on JBPM-569:
---------------------------------------
This might include changing 'deprecated' into 'no longer supported' in lines 1690 and 1691 of jpdl.xml:
http://fisheye.jboss.com/browse/JBPM/jbpm.3/jpdl/userguide/en/modules/jpd...
1690 <entry>{content} For backwards compatibility, the condition can also be entered with the 'expression'
1691 attribute, but that attribute is deprecated since 3.2</entry>
[ In 2.3.Beta2 'deprecated' seems to imply it is ignored without any warning. When using "Deploy Process Archive" in the Eclipse GPD 3.0.13.1 (as included in the 2.3.Beta2 Suite) then the condition is simply not persisted in JBPM_TRANSITION. This could be a problem of the GPD, but as I assume the GPD simply deploys processdefinition.xml without interpreting it, the attribute is probably ignored somewhere in the jPDL sources. ]
It might also include noting that context variables may be accessed using either, for example,
#{ quantity > 2 }
or
#{ contextInstance.variables['quantity'] > 2 }
or
#{ contextInstance.variables.quantity > 2 }
That is: if I understand correctly...!
Arjan.
> improve EL expression examples in the user guide
> ------------------------------------------------
>
> Key: JBPM-569
> URL: http://jira.jboss.com/jira/browse/JBPM-569
> Project: JBoss jBPM
> Issue Type: Task
> Components: Core Engine
> Reporter: Tom Baeyens
> Assigned To: Tom Baeyens
> Fix For: jBPM jPDL 3.2
>
>
--
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] Commented: (JBAS-1824) JACC: <role-name>*</role-name> in web.xml should allow configurable authorization bypass
by Anil Saldhana (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1824?page=comments#action_12353708 ]
Anil Saldhana commented on JBAS-1824:
-------------------------------------
This is ready for 4.2.0.CR1. I have to get the test case working.
> JACC: <role-name>*</role-name> in web.xml should allow configurable authorization bypass
> ----------------------------------------------------------------------------------------
>
> Key: JBAS-1824
> URL: http://jira.jboss.com/jira/browse/JBAS-1824
> Project: JBoss Application Server
> Issue Type: Feature Request
> Components: Security
> Affects Versions: JBossAS-4.0.2 Final
> Environment: -
> Reporter: Roland R?z
> Assigned To: Anil Saldhana
> Fix For: JBossAS-4.2.1.CR1
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> In some cases I wish to do authentication without authorisation. For example everybody has access to my web-resource, but I want to know who she/he is.
> Therefore the accessing user must login.
> So my web.xml contains the following snippet:
> ...
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Protected Helloworld example</web-resource-name>
> <description/>
> <url-pattern>/servlet/HelloWorldExample</url-pattern>
> <http-method>POST</http-method>
> <http-method>GET</http-method>
> </web-resource-collection>
> <auth-constraint>
> <role-name>*</role-name>
> </auth-constraint>
> </security-constraint>
> <login-config>
> <auth-method>BASIC</auth-method>
> <realm-name>public</realm-name>
> </login-config>
> ...
> The web app runs with this configuration in Tomcat 5.5.8 standalone but not in Jboss.
> To run it in Jboss I have to add the following element:
> <security-role>
> <role-name>aRole</role-name>
> </security-role>
> The JACC spec (section 3.1.3.1, paragraph 3)states :
> " ?. When an auth-constraint names the reserved role-name, "*", all of the patterns in the containing security-constraint must be combined with all of the roles defined in the web application."
> JBoss implemented this by combining all of the patterns with all roles defined in the web.xml and assumes that each role has to be defined in the web.xml.
> But the web applications roles are probably defined in other files than the web.xml. In our case we use JACC with an external authentication provider. And each time, the roles changes, I also would have to modify the web.xml.
> It is desirable if the auth-contraint with the role-name "*" acceppts "all" roles and not only those that are defined in the web.xml.
> Or is this a JACC spec issue?
> Regards,
> Andrea
--
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: (JBMICROCONT-139) StackOverflowError when traversing certain directories
by Scott M Stark (JIRA)
StackOverflowError when traversing certain directories
------------------------------------------------------
Key: JBMICROCONT-139
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-139
Project: JBoss MicroContainer
Issue Type: Bug
Components: VFS
Reporter: Scott M Stark
Fix For: JBossMC_2_0_0_CR1
The current 2.0.0.snapshot version of the vfs fails under win32 for jrockit 1.5.0_06 with a StackOverflowError when the quartz-ra.rar is deployed:
16:05:27,344 ERROR [AbstractKernelController] Error installing to Start: name=jb
oss.jca:name='quartz-ra.rar',service=RARDeployment state=Create mode=Manual requ
iredState=Installed
java.lang.StackOverflowError
at java.lang.String.substring(II)Ljava.lang.String;(Unknown Source)
at java.net.URLStreamHandler.parseURL(URLStreamHandler.java:220)
at org.jboss.net.protocol.file.Handler.parseURL(Handler.java:47)
at java.net.URL.<init>(URL.java:596)
at java.net.URL.<init>(URL.java:465)
at java.net.URL.<init>(URL.java:413)
at sun.net.www.protocol.jar.Handler.parseAbsoluteSpec(Handler.java:89)
at sun.net.www.protocol.jar.Handler.parseURL(Handler.java:64)
at java.net.URL.<init>(URL.java:596)
at java.net.URL.<init>(URL.java:465)
at java.net.URL.<init>(URL.java:413)
at org.jboss.virtual.plugins.context.jar.AbstractJarHandler.getURL(Abstr
actJarHandler.java:308)
at org.jboss.virtual.plugins.context.jar.AbstractJarHandler.createVirtua
lFileHandler(AbstractJarHandler.java:370)
at org.jboss.virtual.plugins.context.jar.AbstractJarHandler.initJarFile(
AbstractJarHandler.java:186)
at org.jboss.virtual.plugins.context.jar.JarHandler.<init>(JarHandler.ja
va:81)
at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua
lFileHandler(FileSystemContext.java:179)
at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHa
ndler.java:171)
at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua
lFileHandler(FileSystemContext.java:239)
at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua
lFileHandler(FileSystemContext.java:186)
at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHa
ndler.java:171)
at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua
lFileHandler(FileSystemContext.java:239)
at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua
lFileHandler(FileSystemContext.java:186)
at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHa
ndler.java:171)
at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua
lFileHandler(FileSystemContext.java:239)
at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua
lFileHandler(FileSystemContext.java:186)
at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHa
ndler.java:171)
at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua
lFileHandler(FileSystemContext.java:239)
at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua
lFileHandler(FileSystemContext.java:186)
at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHa
ndler.java:171)
at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua
lFileHandler(FileSystemContext.java:239)
at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua
lFileHandler(FileSystemContext.java:186)
at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHa
ndler.java:171)
16:05:27,344 INFO [RARDeployment] Required license terms exist, view vfsfile:/C
:/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.Beta2/server/default/deploy/
quartz-ra.rar/META-INF/ra.xml
16:05:31,719 ERROR [AbstractKernelController] Error installing to Start: name=jb
oss.jca:name='quartz-ra.rar#quartz-ra.rar',service=RARDeployment state=Create mo
de=Manual requiredState=Installed
java.lang.StackOverflowError
16:05:31,734 INFO [TomcatDeployment] deploy, ctxPath=/, warUrl=vfsfile:/C:/svn/
JBossHead/jboss-head/build/output/jboss-5.0.0.Beta2/server/default/deploy/ROOT.w
ar/
This is due to the following bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6192331
The problem is that a file returned via File.listFiles() is such that the File.exists() check fails, and there is recursion to try to resolve the file as a link against the parent. The link checking could be improved, or the resulting listFiles() validated before used.
--
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: (EJBTHREE-716) Add a flag to disable replication event notification
by Ben Wang (JIRA)
Add a flag to disable replication event notification
----------------------------------------------------
Key: EJBTHREE-716
URL: http://jira.jboss.com/jira/browse/EJBTHREE-716
Project: EJB 3.0
Issue Type: Sub-task
Components: Clustering
Reporter: Ben Wang
This came up from an email thread:
(1) By default, passivation events get called during replication cycle
(2) There is a config setting to disable this
(3) We should introduce JBoss-specific replication-only and passivation-only events that actually let you directly write/read the bytestream
(4) I will work to get two sets of events into the next EJB spec, ie. introduce @PreReplicate / @PostReplicate or something like that
We should now tie the replication to passivation events (there is no concrete spec but everyone else is doing it). But we should also have a flag to disable it if needs to.
--
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] Commented: (EJBTHREE-420) redeploy of TreeCached entities fails
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/EJBTHREE-420?page=comments#action_12353698 ]
Brian Stansberry commented on EJBTHREE-420:
-------------------------------------------
I believe the work on EJBTHREE-795 should have fixed this. There's tests that include redeployment. I'll double check and if it looks OK I'll resolve this.
Erica -- does the problem go away with EJB3 RC9 Patch 1? That includes the EJBTHREE-795 fixes.
> redeploy of TreeCached entities fails
> -------------------------------------
>
> Key: EJBTHREE-420
> URL: http://jira.jboss.com/jira/browse/EJBTHREE-420
> Project: EJB 3.0
> Issue Type: Bug
> Affects Versions: EJB 3.0 RC3
> Reporter: Bill Burke
> Assigned To: Brian Stansberry
> Fix For: EJB 3.0 RC10 - FD
>
>
> 2006-01-20 15:14:19,843 INFO [STDOUT] org.hibernate.PropertyAccessException: exception getting property value with CGLIB (set hibernate.cglib.use_reflection_optimizer=false for more info) getter of com.airit.fidsdb.entity.ArrPrevPortPK.?
> at org.hibernate.tuple.PojoComponentTuplizer.getPropertyValues(PojoComponentTuplizer.java:79)
> at org.hibernate.type.ComponentType.getPropertyValues(ComponentType.java:307)
> at org.hibernate.type.ComponentType.isEqual(ComponentType.java:111)
> at org.hibernate.cache.CacheKey.equals(CacheKey.java:51)
> at org.jboss.cache.Fqn.equals(Fqn.java:134)
> at java.util.HashMap.eq(HashMap.java:277)
> at java.util.HashMap.containsKey(HashMap.java:346)
> at org.jboss.cache.eviction.LRUAlgorithm.add(LRUAlgorithm.java:126)
> at org.jboss.cache.eviction.LRUAlgorithm.processAddedNodes(LRUAlgorithm.java:99)
> at org.jboss.cache.eviction.LRUAlgorithm.processQueues(LRUAlgorithm.java:77)
> at org.jboss.cache.eviction.LRUAlgorithm.process(LRUAlgorithm.java:52)
> at org.jboss.cache.eviction.EvictionTimerTask.run(EvictionTimerTask.java:37)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> Caused by: java.lang.ClassCastException: com.airit.fidsdb.entity.ArrPrevPortPK
> at com.airit.fidsdb.entity.ArrPrevPortPK$$BulkBeanByCGLIB$$8b6b36b9.getPropertyValues(<generated>)
> at net.sf.cglib.beans.BulkBean.getPropertyValues(BulkBean.java:48)
> at org.hibernate.tuple.PojoComponentTuplizer.getPropertyValues(PojoComponentTuplizer.java:76)
> ... 13 more
--
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] Assigned: (EJBTHREE-420) redeploy of TreeCached entities fails
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/EJBTHREE-420?page=all ]
Brian Stansberry reassigned EJBTHREE-420:
-----------------------------------------
Assignee: Brian Stansberry (was: Bill Burke)
> redeploy of TreeCached entities fails
> -------------------------------------
>
> Key: EJBTHREE-420
> URL: http://jira.jboss.com/jira/browse/EJBTHREE-420
> Project: EJB 3.0
> Issue Type: Bug
> Affects Versions: EJB 3.0 RC3
> Reporter: Bill Burke
> Assigned To: Brian Stansberry
> Fix For: EJB 3.0 RC10 - FD
>
>
> 2006-01-20 15:14:19,843 INFO [STDOUT] org.hibernate.PropertyAccessException: exception getting property value with CGLIB (set hibernate.cglib.use_reflection_optimizer=false for more info) getter of com.airit.fidsdb.entity.ArrPrevPortPK.?
> at org.hibernate.tuple.PojoComponentTuplizer.getPropertyValues(PojoComponentTuplizer.java:79)
> at org.hibernate.type.ComponentType.getPropertyValues(ComponentType.java:307)
> at org.hibernate.type.ComponentType.isEqual(ComponentType.java:111)
> at org.hibernate.cache.CacheKey.equals(CacheKey.java:51)
> at org.jboss.cache.Fqn.equals(Fqn.java:134)
> at java.util.HashMap.eq(HashMap.java:277)
> at java.util.HashMap.containsKey(HashMap.java:346)
> at org.jboss.cache.eviction.LRUAlgorithm.add(LRUAlgorithm.java:126)
> at org.jboss.cache.eviction.LRUAlgorithm.processAddedNodes(LRUAlgorithm.java:99)
> at org.jboss.cache.eviction.LRUAlgorithm.processQueues(LRUAlgorithm.java:77)
> at org.jboss.cache.eviction.LRUAlgorithm.process(LRUAlgorithm.java:52)
> at org.jboss.cache.eviction.EvictionTimerTask.run(EvictionTimerTask.java:37)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> Caused by: java.lang.ClassCastException: com.airit.fidsdb.entity.ArrPrevPortPK
> at com.airit.fidsdb.entity.ArrPrevPortPK$$BulkBeanByCGLIB$$8b6b36b9.getPropertyValues(<generated>)
> at net.sf.cglib.beans.BulkBean.getPropertyValues(BulkBean.java:48)
> at org.hibernate.tuple.PojoComponentTuplizer.getPropertyValues(PojoComponentTuplizer.java:76)
> ... 13 more
--
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