[JBoss Seam] - Re: Seam CVS now on JBoss AS 4.2 CR1
by gus888
Hi Peter,
After I deployed Seam mail example to JBosss 4.2 server, I immediately got the following exceptions. Do I need to modify some server setting files? Thank you so much for your guidance.
2007-04-19 20:01:54,593 ERROR [org.jboss.ejb.plugins.LogInterceptor] TransactionRolledbackLocalException in method: public abstract void javax.jms.MessageListener.onMessage(javax.jms.Message), causedBy:
| javax.management.RuntimeMBeanException
| at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:176)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:163)
| 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 javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:201)
| at $Proxy145.processMail(Unknown Source)
| at org.buni.meldware.mail.delivery.DeliveryMDB.onMessage(DeliveryMDB.java:103)
| 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 org.jboss.invocation.Invocation.performCall(Invocation.java:359)
| at org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageDrivenContainer.java:495)
| at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
| at org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDrivenInstanceInterceptor.java:116)
| at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
| at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
| at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
| at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
| at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:109)
| at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
| at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
| at org.jboss.ejb.MessageDrivenContainer.internalInvoke(MessageDrivenContainer.java:402)
| at org.jboss.ejb.Container.invoke(Container.java:960)
| at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:987)
| at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:1287)
| at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:266)
| at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:891)
| at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:170)
| at org.jboss.mq.SpySession.run(SpySession.java:323)
| at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:194)
| at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: javax.management.RuntimeMBeanException
| at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:176)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:163)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:201)
| at $Proxy111.send(Unknown Source)
| at org.buni.meldware.mail.MailListenerChainService.processMail(MailListenerChainService.java:194)
| 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 org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| ... 36 more
| Caused by: java.lang.RuntimeException: Could not resolve DNS lookup
| at org.buni.meldware.mail.smtp.sender.SMTPSender.queryDNS(SMTPSender.java:332)
| at org.buni.meldware.mail.smtp.sender.SMTPSender.performMXLookup(SMTPSender.java:259)
| at org.buni.meldware.mail.smtp.sender.SMTPSender.mxLookup(SMTPSender.java:192)
| at org.buni.meldware.mail.smtp.sender.SMTPSender.sendForDomain(SMTPSender.java:427)
| at org.buni.meldware.mail.smtp.sender.SMTPSender.send(SMTPSender.java:381)
| 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 org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| 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 $Proxy117.send(Unknown Source)
| at org.buni.meldware.mail.mailhandler.remote.RemoteDelivery.deliver(RemoteDelivery.java:141)
| at org.buni.meldware.mail.mailhandler.remote.RemoteDelivery.send(RemoteDelivery.java:85)
| 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 org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| ... 48 more
| Caused by: java.net.SocketTimeoutException: Receive timed out
| at java.net.PlainDatagramSocketImpl.receive0(Native Method)
| at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136)
| at java.net.DatagramSocket.receive(DatagramSocket.java:712)
| at org.xbill.DNS.SimpleResolver.readUDP(SimpleResolver.java:126)
| at org.xbill.DNS.SimpleResolver.send(SimpleResolver.java:261)
| at org.xbill.DNS.ExtendedResolver$Resolution.start(ExtendedResolver.java:83)
| at org.xbill.DNS.ExtendedResolver.send(ExtendedResolver.java:345)
| at org.buni.meldware.mail.smtp.sender.SMTPSender.queryDNS(SMTPSender.java:322)
| ... 70 more
| 2007-04-19 20:01:54,609 ERROR [org.jboss.ejb.plugins.jms.JMSContainerInvoker] Exception in JMSCI message listener
| javax.ejb.TransactionRolledbackLocalException
| at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:262)
| at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
| at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
| at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:109)
| at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
| at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
| at org.jboss.ejb.MessageDrivenContainer.internalInvoke(MessageDrivenContainer.java:402)
| at org.jboss.ejb.Container.invoke(Container.java:960)
| at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:987)
| at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:1287)
| at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:266)
| at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:891)
| at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:170)
| at org.jboss.mq.SpySession.run(SpySession.java:323)
| at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:194)
| at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)
| at java.lang.Thread.run(Thread.java:595)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039108#4039108
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4039108
19 years
[JBossCache] - jbosscache 1.4.0.SP1 treecache.xml and DeployedTreeCacheProv
by rocken7
There are very muddy docs on these things, don't point to the wiki its useless for this.
I am confused about the integration of jboss-cache with hibernate and ejb3.
I want to cache entity beans that are read-only, but if I try to setup the DeployedTreeCacheProvider I get:
Unable to locate TreeCache MBean under object name [jboss.cache:service=HibernateTreeCache]
Which is no suprise as the ejb3-entity-cache-service.xml defines it as EJB3EntityTreeCache, so why does it not find by that jndi name?
Is there a property to set in ./deploy/ejb3.deployer/META-INF/persistence.properties for the jndi name or do I set that property in myApp.jar/META-INF/persistence.xml ?
If I use the OptimisticTreeCacheProvider it fails with treecache.xml FileNotFoundException, so if I used this provider then where do I put treecache.xml under the jboss deploy folder?
If I use TreeCacheProviderHook it sort of works, I get tons of these statements in the log:
[OptimisticNodeInterceptor] Cannot Handle Method _put(GlobalTransaction::391, /com/myapp/model/DataBean#197250, item, CacheEntry(com.myapp.model.DataBean)[44,1136687,F], true, 0)
So it looks like its failing on inserting an entity bean into the cache, right?
The query caching seems to work, its generally faster overall, but I don't believe its actually caching any entity bean data ...
Lets get this nailed down, the wiki and google are all over the place, we need the right steps for jboss-4.0.5.GA and jboss-cache 1.4.0.SP1 ...
HowTo do ejb3 entity bean data caching in jboss ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039102#4039102
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4039102
19 years
[JBoss Seam] - Question regarding performance and multiple JavaBean bijecti
by pnorman4
Hi
We're developing a site based on MyFaces, Facelets and Seam, and now we're a little concerned about the performance - it's a bit slow. While analyzing the code I found out some strange Seam behavior.
Background: All our Seam beans are normal JavaBeans (no EJB beans). We'r running the web application in Tomcat (no EE container).
Case: I have a SESSION scoped bean called mainBean with (among other things) a @DataModel getter, a @DataModelSelection setter and an @In setter like the following fragment.
| @In(create = true)
| public void setWebUser(WebUserBean webUser) {
| log.debug(" === Injecting @In 'webUser' (#0 times).", bullCounter3++);
| this.webUser = webUser;
| }
|
| @DataModel
| public List<MooxObject> getMainListItems() {
| log.debug(" === Reading @DataModel 'getMainListItems' (#0 times).", bullCounter++);
| if (isCurrentList())
| return currentMainObjectAsList().getListItems();
| else
| return null;
| }
|
|
| protected MooxObject selectedListItem;
|
| @DataModelSelection("mainListItems")
| public void setSelectedListItem(MooxObject selectedListItem) {
| log.debug(" === Injecting @DataModelSelection 'setSelectedListItem' (#0 times).", bullCounter2++);
| this.selectedListItem = selectedListItem;
| }
|
The page that uses mainBean can contain either nothing, an object or a list. We use facelets' <ui:include> to alter the page depending on what it contains.
The strange thing is that the annotated getters and setters are called multiple times for each request. I've included three different log outputs to visualize it:
With an empty page (no reference to @DataModel):
| [org.jboss.seam.jsf.SeamPhaseListener - 40] before phase: RESTORE_VIEW(1)
| [org.jboss.seam.jsf.SeamPhaseListener - 84] after phase: RESTORE_VIEW(1)
| [org.jboss.seam.jsf.SeamPhaseListener - 40] before phase: RENDER_RESPONSE(6)
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (54 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 118] === Reading @DataModel 'getMainListItems' (27 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (55 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (56 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 118] === Reading @DataModel 'getMainListItems' (28 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (57 times).
| [org.jboss.seam.jsf.SeamPhaseListener - 84] after phase: RENDER_RESPONSE(6)
|
The strange thing is that @DataModel getter is called twice, although never referenced. And webUser bean is injected 4 times.
With a single object page (no reference to @DataModel):
| [org.jboss.seam.jsf.SeamPhaseListener - 40] before phase: RESTORE_VIEW(1)
| [org.jboss.seam.jsf.SeamPhaseListener - 84] after phase: RESTORE_VIEW(1)
| [org.jboss.seam.jsf.SeamPhaseListener - 40] before phase: RENDER_RESPONSE(6)
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (560 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 130] === Injecting @DataModelSelection 'setSelectedListItem' (228 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 118] === Reading @DataModel 'getMainListItems' (298 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (561 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (562 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 130] === Injecting @DataModelSelection 'setSelectedListItem' (229 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 268] ** MainBean - setCurrentObject
| [com.fastsearch.w2p.moox.beans.MainBean - 118] === Reading @DataModel 'getMainListItems' (299 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (563 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (564 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 118] === Reading @DataModel 'getMainListItems' (300 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (565 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (566 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 118] === Reading @DataModel 'getMainListItems' (301 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (567 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (568 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 118] === Reading @DataModel 'getMainListItems' (302 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (569 times).
| [org.jboss.seam.jsf.SeamPhaseListener - 84] after phase: RENDER_RESPONSE(6)
|
Now we have 5 @DataModel gets and 10 @In injections. The @DataModelSelection is injected twice.
With a list (two reference to @DataModel in one Tomahawk <t:dataTable>):
| [org.jboss.seam.jsf.SeamPhaseListener - 40] before phase: RESTORE_VIEW(1)
| [org.jboss.seam.jsf.SeamPhaseListener - 84] after phase: RESTORE_VIEW(1)
| [org.jboss.seam.jsf.SeamPhaseListener - 40] before phase: RENDER_RESPONSE(6)
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (570 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 118] === Reading @DataModel 'getMainListItems' (303 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (571 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (572 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 268] ** MainBean - setCurrentObject from: [USER/USER:68 (norman)] to: [LIST/LIST:0 (lists.alias.members)]
| [com.fastsearch.w2p.moox.serviceinterfaces.ListServiceDecorator - 496] Populating list with 8 members...
| [com.fastsearch.w2p.moox.beans.MainBean - 118] === Reading @DataModel 'getMainListItems' (304 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 118] === Reading @DataModel 'getMainListItems' (305 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 118] === Reading @DataModel 'getMainListItems' (306 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 118] === Reading @DataModel 'getMainListItems' (307 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 118] === Reading @DataModel 'getMainListItems' (308 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 118] === Reading @DataModel 'getMainListItems' (309 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (573 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (574 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 130] === Injecting @DataModelSelection 'setSelectedListItem' (230 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 118] === Reading @DataModel 'getMainListItems' (310 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (575 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (576 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 130] === Injecting @DataModelSelection 'setSelectedListItem' (231 times).
| (and a fiew more hundred injections...)
| [com.fastsearch.w2p.moox.beans.MainBean - 118] === Reading @DataModel 'getMainListItems' (425 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (797 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (798 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 130] === Injecting @DataModelSelection 'setSelectedListItem' (342 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 118] === Reading @DataModel 'getMainListItems' (426 times).
| [com.fastsearch.w2p.moox.beans.MainBean - 48] === Injecting @In 'webUser' (799 times).
| [org.jboss.seam.jsf.SeamPhaseListener - 84] after phase: RENDER_RESPONSE(6)
|
It seems like every time mainBean is accessed (several times in each row in the table) it's reinitialized.
And now my questions:
| * Are we doing something terribly wrong? Why do we get all these injections?
|
| * For best performance - Should we use several small beans with a lot of dependencies, or a fiew bigger beans?
|
| * For best performance - Should we try to have big scopes (like SESSION) to reduce the number of bean instanses, or should we try to minimize the scope (to EVENT)?
|
|
| Finally I'd like to say that except for this injection mystery, Seam really rocks! (I can't imagine JSF without it...)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039101#4039101
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4039101
19 years
[JBoss Seam] - Alternate property reference style in EL not working
by pgmjsd
It looks like http://jira.jboss.org/jira/browse/JBSEAM-580 has resurfaced.
I'm using Seam 1.2.1.GA and I get a String index out of bounds exception when I use the alternate syntax for referencing an entity property: #{entity[fieldName]}
Here is the stack trace:
18:57:39,147 ERROR [STDERR] java.lang.StringIndexOutOfBoundsException: String index out of range: -1
| 18:57:39,148 ERROR [STDERR] at org.jboss.seam.ui.ModelValidator.validate(ModelValidator.java:32)
| 18:57:39,148 ERROR [STDERR] at javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:157)
| 18:57:39,148 ERROR [STDERR] at javax.faces.component.UIInput.validateValue(UIInput.java:312)
| 18:57:39,148 ERROR [STDERR] at javax.faces.component.UIInput.validate(UIInput.java:353)
| ...
|
Basically, the following method in Expressions.java throws because 'dot' is -1:
| public InvalidValue[] validate(String propertyExpression, Object value)
| {
| int dot = propertyExpression.lastIndexOf('.');
| int bracket = propertyExpression.lastIndexOf('[');
| if (dot<=0 && bracket<=0)
| {
| return new InvalidValue[0];
| }
| String componentName;
| String propertyName;
| if (dot>bracket)
| {
| componentName = propertyExpression.substring(2, dot);
| propertyName = propertyExpression.substring( dot+1, propertyExpression.length()-1 );
| }
| else
| {
| componentName = propertyExpression.substring(2, bracket);
| propertyName = propertyExpression.substring( bracket+1, propertyExpression.length()-2 );
| }
| String modelExpression = propertyExpression.substring(0, dot) + '}';
|
| Object modelInstance = createValueBinding(modelExpression).getValue(); //TODO: cache the ValueBinding object!
| return getValidator(modelInstance, componentName).getPotentialInvalidValues(propertyName, value);
| }
|
Does anyone know of a way to work around this? I'm trying to make a generic Facelets tag for input fields and I can't because it won't let me bind to a property using this syntax.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039091#4039091
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4039091
19 years
[Clustering/JBoss] - Re: Some Issues with clustering on JBoss 4.0.4 and EJB stub
by ablevine1
"bstansberry(a)jboss.com" wrote : Sorry, I saw the 1st post in this thread and replied; didn't see the rest of the thread. I'll assume your beans are marked clustered, either via annotation or in the xml.
|
| RetryInterceptor is not yet available in EJB3. Don't think it would solve your problem though. I'd need to know more details about your exact error (how does it fail on reconnect -- full stack trace please) to say much more.
Has this retry interceptor or some simlar concept become available for use with the jboss ejb3 implementation yet?? Currently, failover works fine in my client if at least one node in the server cluster is still running, however, when all the nodes in the cluster go down and then come up, the client now has a bad session stub reference and will throw exceptions. I then have to surround every call on the stub with error handling code that will clear my server connections and start with fresh ones. It would be nice to have the retry interceptor so that this excess code can be eliminated.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039086#4039086
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4039086
19 years