June 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBossCache] - Re: ClusteredCacheLoader should be configured as shared?

by manik.surtani＠jboss.com

basically the CCL returning anything for a remove() call is the fault. This does (somewhat) break the CacheLoader contract in that the remove() method should always return the old value, but the CCL does have somewhat different behaviour. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051777#4051777 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051777

18 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: ClusteredCacheLoader should be configured as shared?

by manik.surtani＠jboss.com

Ah right - even worse then. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051776#4051776 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051776

18 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: ClusteredCacheLoader should be configured as shared?

by bstansberry＠jboss.com

I wasn't clear on the "Major" issue. CCL isn't propagating the remove; the issue there happens when the normal and perfectly correct replication of a remove call occurs. But then on the remote machine, as it tries to handle the remove, the CCL ends up doing a clustered get. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051754#4051754 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051754

18 years, 10 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Two message store actions

by kurt.stam＠jboss.com

Derek, I updated the "Message-Store" section, maybe you can take a look at the JSR-170 section. I think we would want to set the JCR settings through the action rather then then the jbossesb-properties.xml? --Kurt View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051750#4051750 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051750

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: seamability of the current jbpm jsf components

by david.lloyd＠jboss.com

Well, the components within jbpm4jsf are (nearly) all action listeners. So they should work just fine with Seam - in fact I would expect them to really enhance a Seam application. However I've not yet had the opportunity to do any direct testing to see whether it is compatible out of the box, and if not, what needs to be changed. But when I designed the component library, I deliberately set out to create something that could potentially be used by Seam applications as well as standalone JSF applications. The important part of compatibility is whether the logical component design is compatible with the Seam model, and I think it is. There may be technical hurdles to eliminate yet though, before it is a practical reality. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051730#4051730 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051730

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: gpd deployer jar

by david.lloyd＠jboss.com

Well, the problem with that logic is that the gdp deployer has no relationship whatsoever with the console; it is part of the gdp that just has to reside within the app server. In fact, it might be better to put the code for this servlet inside of jbpm-jpdl.jar itself, much like the timer servlet. The test is, if there was no console, how would it be done? The answer is that it would be in jbpm-jpdl.jar and there would be a stub .war file to run the jBPM servlet components. So, what do you think about moving the servlet code into the jPDL jar? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051721#4051721 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051721

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: possible bug with JTA transactions

by camunda

Okay, I changed it now to not use transactions. But still I get this exceptions and some logs are missing afterwords: | 2007-06-06 14:51:28,443 WARN [org.hibernate.util.JDBCExceptionReporter] SQL Error: 0, SQLState: null | 2007-06-06 14:51:28,456 ERROR [org.hibernate.util.JDBCExceptionReporter] Transaction is not active: tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=titan.computation.de/12 | 931, BranchQual=, localId=12931]; - nested throwable: (javax.resource.ResourceException: Transaction is not active: tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=titan.c | omputation.de/12931, BranchQual=, localId=12931]) | 2007-06-06 14:51:28,734 ERROR [com.camunda.toolkit.jbpm.service.CommandServiceBean] could not close jbpm context after command org.jbpm.command.SignalCommand | org.hibernate.exception.GenericJDBCException: Cannot open connection | at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103) | at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91) | at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) | at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29) | at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:426) | at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144) | at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:94) | at org.hibernate.id.IdentityGenerator$GetGeneratedKeysDelegate.prepare(IdentityGenerator.java:69) | at org.hibernate.id.insert.AbstractReturningDelegate.performInsert(AbstractReturningDelegate.java:30) | at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2158) | at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2638) | at org.hibernate.action.EntityIdentityInsertAction.execute(EntityIdentityInsertAction.java:48) | at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248) | at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:298) | at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:181) | at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:107) | at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:187) | at org.hibernate.event.def.DefaultSaveEventListener.saveWithGeneratedOrRequestedId(DefaultSaveEventListener.java:33) | at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:172) | at org.hibernate.event.def.DefaultSaveEventListener.performSaveOrUpdate(DefaultSaveEventListener.java:27) | at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70) | at org.hibernate.impl.SessionImpl.fireSave(SessionImpl.java:535) | at org.hibernate.impl.SessionImpl.save(SessionImpl.java:523) | at org.hibernate.impl.SessionImpl.save(SessionImpl.java:519) | at org.jbpm.logging.db.DbLoggingService.log(DbLoggingService.java:57) | at org.jbpm.svc.save.SaveLogsOperation.save(SaveLogsOperation.java:47) | at org.jbpm.svc.Services.save(Services.java:161) | at org.jbpm.JbpmContext.save(JbpmContext.java:427) | at org.jbpm.JbpmContext.autoSave(JbpmContext.java:620) | at org.jbpm.JbpmContext.close(JbpmContext.java:137) | at com.camunda.toolkit.jbpm.service.CommandServiceBean.execute(CommandServiceBean.java:93) | at sun.reflect.GeneratedMethodAccessor667.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:597) | at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112) | at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166) | at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63) | at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) | at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54) | at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) | at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47) | at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) | at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79) | at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:197) | at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) | at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76) | at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) | at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62) | at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) | at org.jboss.aspects.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:167) | at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:100) | at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) | at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78) | at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) | at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47) | at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) | at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106) | at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) | at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:225) | at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106) | at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) | at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828) | at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681) | at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358) | at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:412) | at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239) | Caused by: org.jboss.util.NestedSQLException: Transaction is not active: tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=titan.computation.de/12931, BranchQual=, localId=1 | 2931]; - nested throwable: (javax.resource.ResourceException: Transaction is not active: tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=titan.computation.de/12931, Branch | Qual=, localId=12931]) | at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:94) | at org.hibernate.connection.DatasourceConnectionProvider.getConnection(DatasourceConnectionProvider.java:69) | at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:423) | ... 61 more | Caused by: javax.resource.ResourceException: Transaction is not active: tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=titan.computation.de/12931, BranchQual=, localId=12 | 931] | at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:290) | at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:379) | at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:812) | at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88) | ... 63 more | This at least seems to be a bug in JTA transaction management, or? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051706#4051706 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051706

18 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Java 5 and JBM

by markuskobler

Because of JBM dependencies on JBoss AS 4.2 client libraries there does not seem to be a way for JBM to support 1.4 on the client side. http://jira.jboss.com/jira/browse/JBPAPP-212?page=comments In my honest opinion using solutions like JBossRetro, Retroweaver or Retrotranslator will simply add to the already large client-side dependencies, in addition to requiring an infeasible amount of testing to guaranty they don't have side effects. As a side issue this should be made explicitly clear in the documentation so that users like that are constrained by 1.4 code are clear they are unable to use JBM. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051677#4051677 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051677

18 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBAS-4465 - rename hsqldb-jdbc-state-service.xml

by dimitris＠jboss.org

I think this renaming/refactoring should be done in a later release (jboss HEAD for now). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051671#4051671 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051671

18 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: ClusteredCacheLoader should be configured as shared?

by manik.surtani＠jboss.com

http://jira.jboss.com/jira/browse/JBCACHE-1093 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051664#4051664 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051664

18 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2007