June 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (GPD-211) Followup questions on removal of jpdl namespace ref in SOA-P quickstarts - SOA-344,JBESB-1503

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/GPD-211?page=comments#action_12416281 ] Tom Baeyens commented on GPD-211: --------------------------------- koen, can you see if this is only a gpd issue ? afaict, it is. if not, clone it and reassign the non-gpd part to jbpm > Followup questions on removal of jpdl namespace ref in SOA-P quickstarts - SOA-344,JBESB-1503 > ---------------------------------------------------------------------------------------------- > > Key: GPD-211 > URL: http://jira.jboss.com/jira/browse/GPD-211 > Project: JBoss jBPM GPD > Issue Type: Bug > Environment: jpdl 3.2.2 - SOA Platform build beta2 > Reporter: Len DiMaggio > Assigned To: Tom Baeyens > > Followup questions on this removal of the XML namespace reference - see SOA-344,JBESB-1503 - in processdefinition.xml files in SOA-P jBPM quickstarts: > http://viewvc.jboss.org/cgi-bin/viewvc.cgi/labs/labs/jbossesb/branches/JB... > Was this change made between SOA-P beta1 and beta2 - and if so in response to which JIRA? > Or, was the change in beta1 and we missed it in our testing? > Also - what's the reason for this change? > Another side-effect of this change is that JBDS 1.0 - in creating a new jBPM project - creates a processdefinition file with this (the old) syntax: > <?xml version="1.0" encoding="UTF-8"?> > <process-definition > xmlns="urn:jbpm.org:jpdl-3.2" > name="simple"> > Should we recommend that users manually remove the namespace reference? -- 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

18 years, 1 month

1
0
0 / 0

[JBoss JIRA] Moved: (GPD-211) Followup questions on removal of jpdl namespace ref in SOA-P quickstarts - SOA-344,JBESB-1503

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/GPD-211?page=all ] Tom Baeyens moved JBPM-1111 to GPD-211: --------------------------------------- Project: JBoss jBPM GPD (was: JBoss jBPM) Key: GPD-211 (was: JBPM-1111) Component/s: (was: BPEL) Affects Version/s: (was: jBPM jPDL 3.2.2) > Followup questions on removal of jpdl namespace ref in SOA-P quickstarts - SOA-344,JBESB-1503 > ---------------------------------------------------------------------------------------------- > > Key: GPD-211 > URL: http://jira.jboss.com/jira/browse/GPD-211 > Project: JBoss jBPM GPD > Issue Type: Bug > Environment: jpdl 3.2.2 - SOA Platform build beta2 > Reporter: Len DiMaggio > Assigned To: Tom Baeyens > > Followup questions on this removal of the XML namespace reference - see SOA-344,JBESB-1503 - in processdefinition.xml files in SOA-P jBPM quickstarts: > http://viewvc.jboss.org/cgi-bin/viewvc.cgi/labs/labs/jbossesb/branches/JB... > Was this change made between SOA-P beta1 and beta2 - and if so in response to which JIRA? > Or, was the change in beta1 and we missed it in our testing? > Also - what's the reason for this change? > Another side-effect of this change is that JBDS 1.0 - in creating a new jBPM project - creates a processdefinition file with this (the old) syntax: > <?xml version="1.0" encoding="UTF-8"?> > <process-definition > xmlns="urn:jbpm.org:jpdl-3.2" > name="simple"> > Should we recommend that users manually remove the namespace reference? -- 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

18 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-1638) Allow image export functionality at the code level for processes

by Kris Verlaenen (JIRA)

Allow image export functionality at the code level for processes ---------------------------------------------------------------- Key: JBRULES-1638 URL: http://jira.jboss.com/jira/browse/JBRULES-1638 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Eclipse IDE Reporter: Kris Verlaenen Assigned To: Kris Verlaenen Fix For: 5.0.0-M1 Provide a method in the process editor for creating an image of the selected process. -- 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

18 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1361) NPE in DataContainerImpl.getNodesForEviction()

by Brian Stansberry (JIRA)

NPE in DataContainerImpl.getNodesForEviction() ---------------------------------------------- Key: JBCACHE-1361 URL: http://jira.jboss.com/jira/browse/JBCACHE-1361 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction Affects Versions: 2.2.0.GA Reporter: Brian Stansberry Assigned To: Manik Surtani Actually effects 2.2.0.CR2, but that wasn't a choice. Call to recursively evict a subtree fails with an NPE: 2008-06-03 21:05:13,419 ERROR [org.jboss.web.tomcat.service.session.JBossCacheManager] processExpires(): failed expiring 2 with exception: java.lang.NullPointerException java.lang.NullPointerException at org.jboss.cache.DataContainerImpl.recursiveAddEvictionNodes(DataContainerImpl.java:267) at org.jboss.cache.DataContainerImpl.getNodesForEviction(DataContainerImpl.java:241) at org.jboss.cache.interceptors.PassivationInterceptor.visitEvictFqnCommand(PassivationInterceptor.java:54) at org.jboss.cache.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:88) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:142) at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:157) at org.jboss.cache.commands.AbstractVisitor.visitEvictFqnCommand(AbstractVisitor.java:55) at org.jboss.cache.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:88) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:142) at org.jboss.cache.interceptors.PessimisticLockInterceptor.handleEvictFqnCommand(PessimisticLockInterceptor.java:303) at org.jboss.cache.interceptors.base.PostProcessingCommandInterceptor.visitEvictFqnCommand(PostProcessingCommandInterceptor.java:138) at org.jboss.cache.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:88) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:142) at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:157) at org.jboss.cache.commands.AbstractVisitor.visitEvictFqnCommand(AbstractVisitor.java:55) at org.jboss.cache.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:88) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:142) at org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:266) at org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:253) at org.jboss.cache.commands.AbstractVisitor.visitEvictFqnCommand(AbstractVisitor.java:55) at org.jboss.cache.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:88) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:142) at org.jboss.cache.interceptors.CacheMgmtInterceptor.visitEvictFqnCommand(CacheMgmtInterceptor.java:66) at org.jboss.cache.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:88) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:142) at org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:158) at org.jboss.cache.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:108) at org.jboss.cache.commands.AbstractVisitor.visitEvictFqnCommand(AbstractVisitor.java:55) at org.jboss.cache.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:88) at org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:215) at org.jboss.cache.invocation.CacheInvocationDelegate.evict(CacheInvocationDelegate.java:347) at org.jboss.web.tomcat.service.session.JBossCacheWrapper.evictSubtree(JBossCacheWrapper.java:289) at org.jboss.web.tomcat.service.session.JBossCacheService.evictSession(JBossCacheService.java:371) at org.jboss.web.tomcat.service.session.JBossCacheService.evictSession(JBossCacheService.java:361) at org.jboss.web.tomcat.service.session.JBossCacheManager.processSessionPassivation(JBossCacheManager.java:1777) at org.jboss.web.tomcat.service.session.JBossCacheManager.processExpires(JBossCacheManager.java:1542) at org.jboss.web.tomcat.service.session.JBossCacheManager.createSession(JBossCacheManager.java:804) at org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionCountUnitTestCase.createAndUseSession(SessionCountUnitTestCase.java:902) at org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionCountUnitTestCase.testStandaloneMaxSessionsWithMinIdle(SessionCountUnitTestCase.java:269) 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:585) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:672) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:567) Looks like DataContainerImpl.getNodesForEviction() is doing a peek() and passing the result to recursiveAddEvictionNodes() even if the peek() returns null. JBAS web session replication manages eviction itself, which is why the evict() call is coming from the session management layer. -- 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

18 years, 1 month

2
5
0 / 0

[JBoss JIRA] Created: (JBAOP-593) Proxy Factory should only create a proxy if per instance container has metadata bringing in more aspects than exist at class level

by Kabir Khan (JIRA)

Proxy Factory should only create a proxy if per instance container has metadata bringing in more aspects than exist at class level ---------------------------------------------------------------------------------------------------------------------------------- Key: JBAOP-593 URL: http://jira.jboss.com/jira/browse/JBAOP-593 Project: JBoss AOP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0.0.GA Previously metadata at instance-level or below would always force a proxy Only force a proxy now if this metadata brings in more aspects than would happen without the instance-level metadata -- 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

18 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBAOP-592) Error shutting down AspectManagerService in AS 5

by Kabir Khan (JIRA)

Error shutting down AspectManagerService in AS 5 ------------------------------------------------ Key: JBAOP-592 URL: http://jira.jboss.com/jira/browse/JBAOP-592 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR11 Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0.0.GA -- 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

18 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-783) STABLE: last message dropped issue ?

by Bela Ban (JIRA)

STABLE: last message dropped issue ? ------------------------------------ Key: JGRP-783 URL: http://jira.jboss.com/jira/browse/JGRP-783 Project: JGroups Issue Type: Task Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.6.3, 2.7 Check whether this issue crept back in (regression). Test is LastMessageDroppedTest -- 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

18 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4988) EJB3: cannot auto-generate tables according to persistence.xml?

by cai jc (JIRA)

EJB3: cannot auto-generate tables according to persistence.xml? --------------------------------------------------------------- Key: JBAS-4988 URL: http://jira.jboss.com/jira/browse/JBAS-4988 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-4.2.2.GA Environment: jboss4.2.2(default mode), JDK1.6, postgresql 8.2 Reporter: cai jc Assigned To: Carlo de Wolf An J2EE application.containing a EJB module and a Web module.In EJB module,a persistence.xml exists: <?xml version="1.0" encoding="UTF-8"?> <persistence> <persistence-unit name="caijc"> <jta-data-source>java:/PostgresDS</jta-data-source> <property name="hibernate.show_sql">true</property> <property name="hibernate.hbm2ddl.auto" value="create"/> </persistence-unit> </persistence> There is no any error on deploy-time: [JmxKernelAbstraction] installing MBean: persistence.units:ear=cjc.ear,jar=cjc-ejb.jar,unitName=caijc with dependencies: 06:13:38,703 INFO [JmxKernelAbstraction] jboss.jca:name=PostgresDS,service=DataSourceBinding 06:13:39,000 INFO [PersistenceUnitDeployment] Starting persistence unit persistence.units:ear=cjc.ear,jar=cjc-ejb.jar,unitName=caijc 06:13:39,031 INFO [Ejb3Configuration] found EJB3 Entity bean: net.cjc.entity.Author 06:13:39,031 INFO [Ejb3Configuration] found EJB3 Entity bean: net.cjc.entity.Book 06:13:39,046 INFO [Configuration] Reading mappings from resource : META-INF/orm.xml 06:13:39,046 INFO [Ejb3Configuration] [PersistenceUnit: caijc] no META-INF/orm.xml found 06:13:39,046 INFO [AnnotationBinder] Binding entity from annotated class: net.cjc.entity.Author 06:13:39,046 INFO [EntityBinder] Bind entity net.cjc.entity.Author on table tbl_Authors 06:13:39,078 INFO [AnnotationBinder] Binding entity from annotated class: net.cjc.entity.Book 06:13:39,078 INFO [EntityBinder] Bind entity net.cjc.entity.Book on table tbl_Books 06:13:39,109 INFO [ConnectionProviderFactory] Initializing connection provider: .... But when I access the related EJB service(an INSERT execution),an exception is thrown: 421 ERROR [JDBCExceptionReporter] batch operation 0insert into tbl_Authors (birthday, levels, name) values (2007-11-19 +00:00:00, 5, me)failed， 07:53:39,421 WARN [JDBCExceptionReporter] SQL Error: 0, SQLState: 42P01 07:53:39,421 ERROR [JDBCExceptionReporter] ERROR: relation "tbl_authors" does not exist 07:53:39,421 ERROR [AbstractFlushingEventListener] Could not synchronize database state with session org.hibernate.exception.SQLGrammarException: Could not execute JDBC batch update at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:67) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:237) Yes,No tables are created automatically,even if I've specified "hibernate.hbm2ddl.auto" to "create" in persistence.xml. If I created these tables manurally,everything is ok. So is this a bug? or my fault? -- 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

18 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-896) Specifying an interceptor-order in ejb-jar.xml also creates a new instance of the interceptor

by Carlo de Wolf (JIRA)

Specifying an interceptor-order in ejb-jar.xml also creates a new instance of the interceptor --------------------------------------------------------------------------------------------- Key: EJBTHREE-896 URL: http://jira.jboss.com/jira/browse/EJBTHREE-896 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC9 - Patch 1 Environment: interceptor2 Reporter: Carlo de Wolf Assigned To: Carlo de Wolf Priority: Critical -- 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

18 years, 1 month

2
8
0 / 0

[JBoss JIRA] Created: (JBCACHE-1359) Nodes are not removed during commit if new children have been added to their parents

by Kai Blankenhorn (JIRA)

Nodes are not removed during commit if new children have been added to their parents ------------------------------------------------------------------------------------ Key: JBCACHE-1359 URL: http://jira.jboss.com/jira/browse/JBCACHE-1359 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.1.SP9 Reporter: Kai Blankenhorn Assigned To: Manik Surtani Say we have a cache instance called "cache" that is configured to use a custom CacheLoader that always returns "value from CacheLoader". Now we call: cache.put("/a/b/c", "key", "cachedValue"); cache.remove(Fqn.ROOT); cache.put("/a/B/c", "key", "cachedValue"); commitTx(); String val = (String) cache.get("/a/b/c", "key"); assertEquals("value from CacheLoader", val); The result will be null instead of "value from CacheLoader". The problem is that the parent nodes (for instance, "/a/b") are marked for removal. In the same transaction after removing "/a/b", "/a" is readded and thus unmarked. When the transaction is committed, "/a" is about to be realRemove()d. But this method skips the node and its children, as it is no longer marked for removal. This way "/a/b" is never removed and stays marked for removal. When reading "/a/b/c", the iteration over the fqn elements in TreeCache.findInternal() skips all nodes marked for removal, never reaching the requested node. -- 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

18 years, 1 month

2
5
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 June 2008