[JBoss Seam] - EntityHome and EntityQuery difference/problem
by dnikolov
Note that this topic isn't about the difference between EntityHome and EntityQuery in general, but about the different behavior I get when I put a certain bit of functionality in classes extending these two.
So, my setup:
I followed ch 1 of the seam tutorial and put in a @DataModel and a @DataModelSelection on a data table so I can detect which row is selected.
I set up the table so that if the current row is selected inputText elements are shown so a user can edit the information in the row. Otherwise outputText elements are rendered.
On each row I also have an edit commandLink that is wired to a method that does something like this:
| public String edit() {
| this.deselectAll();
| if(!this.selectionItem.getSelected()) {
| this.selectionItem.setSelected(true);
| }
| return null;
| }
|
I also have a save button on each row that does something like:
| public String save() {
| EntityObj obj = this.selectionItem.getEntityObj();
| EntityManager em = this.getEntityManager();
| em.persist(obj);
| return null;
| }
|
This seems to work fine in a class extending EntityHome (provided that in the save function I set the current instance to obj and then do persist on the current instance), but it doesn't work in the class extending entity query.
Tracing through this shows that after the user edits the input boxes and the save function is called, the EntityObj gotten from this.selectionItem.getEntityObj() has the values that were there before the user edit.
selectionItem is the @DataItemSelection of course.
So.. any ideas why this works in one class and not in another? I am using the pages generated by seamgen to test this: I use a ___Edit.xhtml page with the ___Home.java, and a ___List.xhtml with the ___List.java.
Any feedback is greatly appreciated.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093757#4093757
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093757
18Â years, 8Â months
[JBoss Seam] - Re: Re-working EJB Extended Context To Use SMPC - Need Help
by matt.drees
"curtney" wrote :
| Scenario Two:
|
| All ejb components are injected using Seam's @In annotation (Switched from @EJB to @In annotation). Why the switch? I am assuming the switch will solve my problem of the entity manager not being injected. Seam now has control of the creation and injection of the ejb components, thus proper injection of the entity manager. However, that is not the case injection fails on both ejb components and entity manager. Before, it was only the entity manager that did not get injected.
|
|
This should work, and is probably what you want. Could you be more specific on what breaks when you do this? (and post code)
Also, note that the variable name needs to match the component name. So you'll need to change MyStatelessBean's field "myStatelessDAO" to "myStateless". (Or change the component name, or use @In's value attribute, etc).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093756#4093756
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093756
18Â years, 8Â months
[JBoss Portal] - Couldn't create consumer 'self'
by cry4dawn
I am getting the following i am getting the following error when starting up my jboss(portal 2.6.2, AS 4.2.1, both cluster configed) i am using Oracle9i and have it configured to use the oracle stuff.
18:02:08,432 WARN [JDBCExceptionReporter] SQL Error: 2289, SQLState: 42000
18:02:08,448 ERROR [JDBCExceptionReporter] ORA-02289: sequence does not exist
18:02:08,448 INFO [Configuration] Reading mappings from resource : org/jbpm/taskmgmt/def/Task.hbm.xml
18:02:08,463 ERROR [MainDeployer] Could not initialise deployment: file:/C:/Documents and Settings/aanderson/Desktop/test/jboss-4.2.1.GAHEI/serve
r/default/deploy/jboss-portal-ha.sar/portal-wsrp.sar/default-wsrp.xml
org.jboss.deployment.DeploymentException: Failed to parse source: Couldn't create Consumer 'self'; - nested throwable: (org.jboss.xb.binding.JBos
sXBException: Failed to parse source: Couldn't create Consumer 'self')
at org.jboss.portal.wsrp.deployment.WSRPDeployer.init(WSRPDeployer.java:112)
at org.jboss.deployment.MainDeployer.init(MainDeployer.java:872)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:809)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
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.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 org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy229.deploy(Unknown Source)
at org.jboss.portal.wsrp.deployment.WSRPDeployer.startService(WSRPDeployer.java:165)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
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.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
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 $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
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.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 org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy210.start(Unknown Source)
at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
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.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093755#4093755
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093755
18Â years, 8Â months
[JBossCache] - Re: ClassCastException/instanceof fails when getting object
by jason.greeneï¼ jboss.com
"dode" wrote : Naaawww, that "trick" with setting UseJBossWebLoader to true in jbossweb-tomcat55.sar/META-INF/jboss-service.xml doesn't really work either - as soon as I redeploy the webapp I get a ClassCastException again. It seems upon redeploying a new classloader is used so it is again not the same as the one used by the cache.
| After a restart it works fine again - until I redeploy the webapp.
|
| Torsten
Since the cache holds a reference to the object you ask it to store, and since that reference is tied to a class, then the lifespan of the class has to last as long as the cache entry exists. So in other words, if you are going to put stuff in the cache that outlives your deployments, then you need to move those custom types to a deployment that lasts as long as your cache entry. A separate jar file would do.
Also you might want to stay away from UseJBossWebLoader=true, especially if you are using jsps (since classname conflicts are high).
-Jason
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093752#4093752
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093752
18Â years, 8Â months
[Remoting] - Re: CompressingMarshaller and clientConnectAddress
by ron.sigalï¼ jboss.com
Hi Klaus,
You want the compressing marshaller and unmarshaller to work on both sides of the connection, of course, which means you want to tell the client about them, which you do by way of InvokerLocator parameters. When use use the Configuration attribute, only the "subattributes" labeled with isParam="true" get added to the InvokerLocator. Your marshaller and unmarshaller attributes don't have this label, so the client doesn't know about them. This is confusing to me, though, since the client and server shouldn't be able to communicate if they're using different marshaller/unmarshallers. Still, it's a place to start.
I should mention that some people have reported problems with the compression marshaller, particularly in the context of EJBs. See JBREM-677 "Compression marshalling fails intermittently." (http://jira.jboss.com/jira/browse/JBREM-677).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093751#4093751
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093751
18Â years, 8Â months