[EJB 3.0] - Entity EJB on a client - Best Practices
by octaviob
I'm working on an EJB client application on Eclipse RCP.
I'm getting a MarshalException when transfering to the client entities with recursive bidirectional relationships (plus several other relationships). This exception seems to be caused by serialization limitations in Hibernate,
but I'm not sure.
After several searches and no clear answer to my problem, I'm arriving to the conclusion that it is best to 'construct' complex objects on the client by getting finer grain entities from the server and performing final assembly on the client.
Likewise, the database should be updated by merging finer grain entities. This puts more EJB logic/code on the client than I originally intended.
Any comments on best practices for using entity EJBs on a client will be greatly appreciated.
thanks,
Octavio
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068487#4068487
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068487
19Â years, 1Â month
[JBoss Seam] - Re: Need help with Timer in Seam application
by wise_guybg
In think you should focus on the NPE.
anonymous wrote : 15:28:00,260 ERROR [STDERR] Caused by: java.lang.NullPointerException: facesContext
| 15:28:00,260 ERROR [STDERR] at org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.jav
| a:110)
| 15:28:00,260 ERROR [STDERR] at org.jboss.seam.actionparam.ActionParamBindingHelper.invokeTheExpress
| ion(ActionParamBindingHelper.java:58)
| 15:28:00,260 ERROR [STDERR] at org.jboss.seam.actionparam.ActionParamMethodBinding.invoke(ActionPar
| amMethodBinding.java:75)
| 15:28:00,260 ERROR [STDERR] at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:148)
| 15:28:00,260 ERROR [STDERR] at org.jboss.seam.core.Events.raiseEvent(Events.java:63)
| 15:28:00,260 ERROR [STDERR] at org.jboss.seam.security.Identity.checkPermission(Identity.java:438)
| 15:28:00,260 ERROR [STDERR] at org.jboss.seam.security.Identity.checkEntityPermission(Identity.java
| :601)
You may have an observer (Expressions$2.invoke) of the event (Events.raiseEvent) "org.jboss.seam.notLoggedIn" (Identity.checkPermission) which is causing the trouble. This should be located in the components.xml Some MethodBinding/MethodExpression that is failing. You may need to post some more code if you cannot figure it out by yourself.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068480#4068480
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068480
19Â years, 1Â month
[JBossCache] - Re: RC1->RC3 problems
by supi
"Brian Stansberry in jbosscache-dev" wrote :
| Basically, the state transfer semantics imply that the in-memory state
| is "consistent" with the cluster when start returns. Either its
| "consistent" because it's been transferred, or it's "consistent" because
| it's empty and waiting to be populated from a trusted source (shared
| cache loader or external source like db). Leaving the in-memory state
| around after stop() breaks that.
|
The reasoning is flawed. If an empty state is considered "consistent" because it can externally be "populated from a trusted source", any state can be considered "consistent" as long as a process can be defined that yields a truly consistent state. For example: Leaving the in-memory state aound after stop() is also consistent: it's waiting to be synchronized "from a trusted source".
The definition of "consistent" is either too weak to be useful or does not hold for the start() method.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068475#4068475
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068475
19Â years, 1Â month
[JBoss Messaging] - Jboss Messaging 1.4.0.CR1 and postgresql...
by boniek
... does not work for me.
@WorkerThread#0[127.0.0.1:58493] 21:57:00,325 WARN [JDBCPersistenceManager] SQLException caught - assuming deadlock detected, try:1
[junit] org.postgresql.util.PSQLException: ERROR: relation "jbm_msg_ref" does not exist
[junit] at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1548)
[junit] at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1316)
[junit] at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:191)
[junit] at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
[junit] at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:351)
[junit] at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:305)
[junit] at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:251)
[junit] at org.jboss.messaging.core.impl.JDBCPersistenceManager.updateWithRetry(Unknown Source)
[junit] at org.jboss.messaging.core.impl.JDBCPersistenceManager.updateWithRetry(Unknown Source)
[junit] at org.jboss.messaging.core.impl.JDBCPersistenceManager.addReference(Unknown Source)
[junit] at org.jboss.messaging.core.impl.ChannelSupport.handleInternal(Unknown Source)
[junit] at org.jboss.messaging.core.impl.ChannelSupport.handle(Unknown Source)
[junit] at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.routeInternal(Unknown Source)
[junit] at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.route(Unknown Source)
[junit] at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(Unknown Source)
[junit] at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(Unknown Source)
[junit] at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(Unknown Source)
[junit] at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_6145266547759487588.invokeNext(SessionAdvised$send_6145266547759487588.java)
[junit] at org.jboss.jms.server.container.SecurityAspect.handleSend(Unknown Source)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:585)
[junit] at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
[junit] at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_6145266547759487588.invokeNext(SessionAdvised$send_6145266547759487588.java)
[junit] at org.jboss.jms.server.container.ServerLogInterceptor.invoke(Unknown Source)
[junit] at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_6145266547759487588.invokeNext(SessionAdvised$send_6145266547759487588.java)
[junit] at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(Unknown Source)
[junit] at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(Unknown Source)
[junit] at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(Unknown Source)
[junit] at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
[junit] at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:560)
[junit] at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:383)
[junit] at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:165)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068474#4068474
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068474
19Â years, 1Â month
[JBossCache] - Re: RC1->RC3 problems
by supi
anonymous wrote : When a cache stops, you are meant to lose this in-memory state.
I disagree. When a cache stops, you should lose the ability to operate on the data through the cache interface. I've never seen a database deleting tables when you stop the db server/agent. I would agree with you if a) a stopped cache was not meant to be restarted ever, b) there wasn't a destroy method perfectly suitable for releasing resources.
anonymous wrote :
| The definitions of the terms are:
| ...
| stop() - stops the engine and services - which typically includes the data store
| ...
|
I agree. However, stopping a data store's services does not imply deleting the content.
anonymous wrote :
| The fact that this state stuck around when you stopped and then restarted a cache was a bug.
|
We need the ability to remove a cache from a cluster and add it to a cluster at runtime, so for us it's clearly a feature and not a bug. I can see your point, but what I don't understand is why you don't let the users make their own decision.
anonymous wrote :
| You'd use a cache loader if you want a warm cache (even if it is a delegating cache loader that delegates to another in-memory cache that acts as your 'back-end' cache, while your 'front-end' cache adds behaviour)
|
While we might use something like this eventually, it implies unnecessary code and performance overhead.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068473#4068473
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068473
19Â years, 1Â month