[JBoss JIRA] Created: (JBPORTAL-1599) Typo in build/build.xml
by Tobias Roth (JIRA)
Typo in build/build.xml
-----------------------
Key: JBPORTAL-1599
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1599
Project: JBoss Portal
Issue Type: Patch
Security Level: Public (Everyone can see)
Affects Versions: 2.6 Final
Reporter: Tobias Roth
Index: build.xml
===================================================================
--- build.xml (Revision 7819)
+++ build.xml (Arbeitskopie)
@@ -304,7 +304,7 @@
</target>
<target name="undeploy-all"
- description="Deploy all archives."
+ description="Undeploy all archives."
depends="init">
<require file="${jboss.home}/server/${portal.deploy.dir}"/>
<delete file="${jboss.home}/server/${portal.deploy.dir}/jboss-portal.sar"
/>
--
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
[JBoss JIRA] Created: (JBCACHE-1060) Tutorial - removing a child node from the root still leaves the node in memory
by Galder Zamarreno (JIRA)
Tutorial - removing a child node from the root still leaves the node in memory
------------------------------------------------------------------------------
Key: JBCACHE-1060
URL: http://jira.jboss.com/jira/browse/JBCACHE-1060
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.CR1
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
Fix For: 2.0.0.CR2
I have reproduced an issue via the tutorial but I'm not sure whether it's a tutorial or cache issue yet.
Making a note of the steps so that I can come back to it later.
1st GUI:
bsh % childFqn2 = Fqn.fromString("/child2");
</child2>
bsh % childFqn3 = Fqn.fromString("/child2/child3");
</child2/child3>
bsh % child2 = root.addChild(childFqn2);
<UnversionedNode[ /child2 data=[]]>
bsh % child3 = root.addChild(childFqn3);
<UnversionedNode[ /child2/child3 data=[]]>
2nd GUI:
bsh % childFqn2 = Fqn.fromString("/child2");
</child2>
bsh % child2 = root.getChild(childFqn2);
<UnversionedNode[ /child2 data=[] child=[UnversionedNode[ /child2/child3 data=[]]]]>
bsh % child2.put("key3", "value3");
<null>
- Click on child2 in the 2nd GUI
bsh % child2.clearData();
1st GUI:
bsh % child2.put("key3", "value3");
<null>
bsh % root.removeChild(childFqn2);
<true>
child2 node is still in memory which shouldn't.
--
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
[JBoss JIRA] Created: (JBCACHE-927) Repeated remove and put under optimistic locking produces exception
by Ben Wang (JIRA)
Repeated remove and put under optimistic locking produces exception
-------------------------------------------------------------------
Key: JBCACHE-927
URL: http://jira.jboss.com/jira/browse/JBCACHE-927
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.ALPHA1
Reporter: Ben Wang
Assigned To: Manik Surtani
Manik, I am not assigning this Jira to any release. It is your call to fix it either in ALPHA2 or BETA1. Basically, my o.jo.c.pojo.optimistic.CachedListTest failure can be attributed to this test case:
public void testFailure1() throws Exception
{
log.info("testFailure1() ....");
UserTransaction tx = getTransaction();
org.jboss.cache.Fqn f = new org.jboss.cache.Fqn("/person/test2");
tx.begin();
cache.getCache().put(f, "test", "test");
tx.commit();
tx.begin();
cache.getCache().removeNode(f);
cache.getCache().put(f, "test", "test");
tx.commit();
}
For optimistic locking and it produces the following error:
org.jboss.cache.CacheException: Unable to set node version for //person/test2, node is null.
at org.jboss.cache.interceptors.OptimisticNodeInterceptor.invoke(OptimisticNodeInterceptor.java:129)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:75)
at org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.invoke(OptimisticCreateIfNotExistsInterceptor.java:64)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:75)
at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:74)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:75)
at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:124)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:75)
at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:22)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:75)
at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:288)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:126)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:75)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:141)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:75)
at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:66)
at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3758)
at org.jboss.cache.CacheImpl.put(CacheImpl.java:1558)
at org.jboss.cache.pojo.optimistic.LocalTxTest.testFailure1(LocalTxTest.java:151)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
If you don't fix it in Alpha2, we will need to exclude my test case temporarily in CC then.
--
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
[JBoss JIRA] Created: (JBCACHE-1000) Pojocache tutorial not working
by Rajesh Rajasekaran (JIRA)
Pojocache tutorial not working
------------------------------
Key: JBCACHE-1000
URL: http://jira.jboss.com/jira/browse/JBCACHE-1000
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: PojoCache
Reporter: Rajesh Rajasekaran
Assigned To: Jason T. Greene
Fix For: 2.0.0.BETA2
sourceRelative("pojocache.bsh"); loads the cache GUI with the default contents from the script.
Trying the set/get methods does not update the GUI.
bsh % joe.getAddress().setCity("Taipei");
bsh % ArrayList lang = new ArrayList();
bsh % lang.add("Ensligh");
bsh % lang.add("Mandarin");
bsh % joe.setLanguages(lang);
Similar case with pojocacheWithTx.bsh. The cache GUI does not get updated.
tx.begin();
addr.setZip(95131);
tx.commit();
I tried the tutorials from JBossCache-pojo-2.0.0.BETA1.zip
--
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
[JBoss JIRA] Created: (JBCACHE-1041) Tutorial - GUI/beanshell block if node modified within transaction and
by Galder Zamarreno (JIRA)
Tutorial - GUI/beanshell block if
node modified within transaction and node status queried via GUI
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Tutorial - GUI/beanshell block if node modified within transaction and
Tutorial - GUI/beanshell block if node modified within transaction and node status queried via GUI
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBCACHE-1041
URL: http://jira.jboss.com/jira/browse/JBCACHE-1041
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.CR1
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
Fix For: 2.0.0.CR2
Instructions:
- add a node to the cache
- start a transaction
- do a put on that node
- clicking on the node via the GUI to check that the node has not been
updated blocks both the GUI and the beanshell. This is due to not being able to
acquire the read lock on the node to show it.
- Also, once the exception is thrown, the GUI/beanshell stops which shouldn't.
Solution:
- Updates on the GUI should be handled in a different thread so that it does
not block the shell? While the shell is blocked, the current transaction cannot be
committed, leaving the user no option.
--
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
[JBoss JIRA] Created: (BPEL-258) Problem using flow with links
by Cristian Benjamin Sostaric (JIRA)
Problem using flow with links
-----------------------------
Key: BPEL-258
URL: http://jira.jboss.com/jira/browse/BPEL-258
Project: JBoss jBPM BPEL
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Engine
Affects Versions: jBPM BPEL 1.1 beta 3
Environment: JBoss-4.0.4.GA
Reporter: Cristian Benjamin Sostaric
Assigned To: Alejandro Guizar
When executing this process:
<flow>
<links>
<link name="LinkA"/>
<link name="LinkB"/>
</links>
<receive name="Receive"
createInstance="yes"
operation="someOperation"
partnerLink="PartnerLink"
portType="tns:SomeInterface"
variable="request">
<source linkName="LinkA" />
</receive>
<assign name="Assign">
<target linkName="LinkA" />
<source linkName="LinkB" />
<copy>
<from part="input" variable="request" />
<to part="result" variable="response"/>
</copy>
</assign>
<reply name="Reply"
operation="someOperation"
partnerLink="PartnerLink"
portType="tns:SomeInterface"
variable="response">
<target linkName="LinkB" />
</reply>
</flow>
The process doesn't finish at all and It gets stuck with this message:
WARN [ProxyWarnLog] Narrowing proxy to class org.jbpm.bpel.graph.def.CompositeActivity - this operation breaks ==
The server.log throws this:
2007-06-05 11:42:53,781 WARN [org.hibernate.engine.StatefulPersistenceContext.ProxyWarnLog] Narrowing proxy to class org.jbpm.bpel.graph.def.CompositeActivity - this operation breaks ==
2007-06-05 11:42:53,782 DEBUG [org.jbpm.bpel.integration.jms.IntegrationControl] added outstanding request: receiver=org.jbpm.bpel.integration.def.Receiver@62e21b[partnerLink=PartnerLink,operation=someOperation,messageExchange=<null>,activity=Receive(Receive),id=231], token=Token(/), request=org.jbpm.bpel.integration.jms.OutstandingRequest@f75278[replyQueue=JMS_TQ13,correlationID=ID:9-11810545737682]
2007-06-05 11:42:53,786 DEBUG [org.jbpm.context.exe.VariableContainer] create variable 'LinkA' in 'TokenVariableMap[primary]' with value 'LinkInstance(name=LinkA, status=null)'
2007-06-05 11:42:53,786 DEBUG [org.jbpm.context.exe.VariableContainer] create variable 'LinkB' in 'TokenVariableMap[primary]' with value 'LinkInstance(name=LinkB, status=null)'
2007-06-05 11:42:53,790 DEBUG [org.jbpm.graph.def.GraphElement] event 'node-leave' on 'Receive(Receive)' for 'Token(/primary/Receive)'
2007-06-05 11:42:53,790 DEBUG [org.jbpm.graph.def.GraphElement] event 'transition' on 'Transition(Receive-StructuredActivity.End)' for 'Token(/primary/Receive)'
2007-06-05 11:42:53,791 DEBUG [org.jbpm.graph.def.GraphElement] event 'node-enter' on 'StructuredActivity$End(119a664)' for 'Token(/primary/Receive)'
2007-06-05 11:42:53,791 DEBUG [org.jbpm.bpel.graph.struct.Flow] flow will not reactivate token, found concurrent token: Token(/primary/Assign)
2007-06-05 11:42:53,792 DEBUG [org.jbpm.svc.Services] executing default save operations
2007-06-05 11:42:53,792 DEBUG [org.jbpm.svc.save.HibernateSaveOperation] saving process instance
2007-06-05 11:42:53,792 DEBUG [org.jbpm.svc.save.SaveLogsOperation] flushing logs to logging service.
2007-06-05 11:42:53,825 DEBUG [org.jbpm.svc.save.CascadeSaveOperation] cascading save of 'org.jbpm.graph.exe.ProcessInstance@13223ad'
2007-06-05 11:42:53,826 DEBUG [org.jbpm.JbpmContext] closing JbpmContext
2007-06-05 11:42:53,826 DEBUG [org.jbpm.svc.Services] closing service 'persistence': org.jbpm.bpel.persistence.db.DbPersistenceService@d38dbc
2007-06-05 11:42:53,826 DEBUG [org.jbpm.persistence.db.DbPersistenceService] committing hibernate transaction
2007-06-05 11:42:53,835 DEBUG [org.jbpm.persistence.db.DbPersistenceService] closing hibernate session
2007-06-05 11:42:53,836 DEBUG [org.jbpm.svc.Services] closing service 'tx': org.jbpm.tx.TxService@5655d3
2007-06-05 11:42:53,836 DEBUG [org.jbpm.svc.Services] closing service 'logging': org.jbpm.logging.db.DbLoggingService@1cab83
--
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
[JBoss JIRA] Created: (JBRULES-1015) Scrolling multiple rule viewer
by Michael Neale (JIRA)
Scrolling multiple rule viewer
------------------------------
Key: JBRULES-1015
URL: http://jira.jboss.com/jira/browse/JBRULES-1015
Project: JBoss Rules
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-brms
Affects Versions: 4.0.0.MR3
Reporter: Michael Neale
Assigned To: Fernando Meyer
Priority: Optional
Fix For: FUTURE
At the moment, to view a rule you have to look at a list, and then open a rule, one at a time.
If people thing its a sensible idea, I propose a view to load up a list of rules - and show them one on top of the other. This can be done with scrollable panel, so when scrolling up or down we lazily load previous or later rules (so at any one time, only a handful of rules are visible).
This is just a low priority idea (God forbid we run out of things to do) - I would only recommend doing this if people start asking for something like this. I know in the IDE it has been talked about.
--
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