[Persistence, JBoss/CMP, Hibernate, Database] - Re: why nobody talks openJPA here?
by nitros
I don't think openJPA is recommended to use with JBoss and it is not supported by JBoss either.
I personally started off my project with openJPA and I ran into problems (see my post - help needed with openJPA and JBoss)
To help you with your problem, I assume you are talking of a bidirectional relationship, this is how I set it up in hibernate and it works smooth:
Address_Detail - > * - 1 -> Address
@ManyToOne(optional = false, cascade = { CascadeType.PERSIST, CascadeType.REFRESH })
@JoinColumn(name = "ADDRESS_ID", nullable = false)
private Address address;
and in address, the definition is
@OneToMany(mappedBy = "address", cascade = { CascadeType.ALL })
private Collection addressDetails;
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138371#4138371
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138371
18 years, 1 month
[JBossWS] - resource injection in WS handler not working in jboss JAX-WS
by actonwang
hi,
I tried to use resource injection in WS Handler as described in JAX-WS spec which is a MUST feature.
I tested it in both Sun impl and Jbosss JAX-WS 2.0.x with Jboss 4.2.2. It is working well in Sun impl but not working in JBoss WS.
here is the simple test. I am using web war as deployement, inside web.xml, I have the following:
<env-entry>
<env-entry-name>customFormat</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>Path1: $PATH_INFO, Outbound: $MESSAGE_OUTBOUND_PROPERTY - $NODE</env-entry-value>
<injection-target>
<injection-target-class>testjaxws.handler.DefaultCustomLoggingWrapperHandler</injection-target-class>
<injection-target-name>customFormat</injection-target-name>
</injection-target>
</env-entry>
inside DefaultCustomLoggingWrapperHandler class, I have:
@Resource
private String customFormat = null;
defined.
It is never gets injected with this value no matter what I tried.
Anyone could help to explain if jboss WS has implemented it or not? If it is implemented, how should we make it work?
Thanks a lot!!
actonwang
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138368#4138368
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138368
18 years, 1 month
[Persistence, JBoss/CMP, Hibernate, Database] - why nobody talks openJPA here?
by ajay662
Hello all,
I am trying to port an application from weblogic to jboss AS 4.2.2. My application uses JPA and I was using OpenJPA as the persistence provider in weblogic.
I don't see too much discussion here about openJPA and was wondering if anyone has tried using openJPA with jboss successfully and whether it works.
I quickly tried to use hibernate as the persistence provider and am running into an Exception "org.hibernate.MappingException: Unable to find column with logical name userid in table userContact", where userid is the mapped column name for a ManyToOne relation. This code works fine with openJPA in both weblogic and websphere. Since I want to keep the code base same for this application for all 3 platforms (weblogic, websphere, jboss), I am inclined to use openJPA.
I will try it next week. Just that I could not find any relevant document and lack of discussion here makes me little nervous.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138367#4138367
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138367
18 years, 1 month
[Messaging, JMS & JBossMQ] - MDB failing - not able to restart delivery
by aazaroff
We have an MDB deployed in jboss 4.0.5 container. This code has been in production for 3+years and has never had an issue, until today.
For some reason the MDB failed. I don't think it was actually the MDB as the stack trace indicates it is an error in the JMSContainerInvoker.getMetaData class/method.
The symptoms were that the MDB just stopped processing messages from it's associated queue. The queue was still accepting messages (the load on this queue processes 6-8K messages per day) and we could see the count on the queue increase through the jmx-console while we were trying to figure out what was wrong.
When we went to inspect the MDB it's state was failure. Upon attempting to restart delivery we got this error
| 2008-03-21 10:59:47,405 WARN [org.jboss.system.ServiceController] Problem starting service jboss.j2ee:service=EJB,plugin=invoker,binding=message-driven-bean,jndiName=local/XMLMerchantProcess@711460
| java.lang.NullPointerException
| at org.jboss.ejb.plugins.jms.JMSContainerInvoker.getMetaData(JMSContainerInvoker.java:264)
| at org.jboss.ejb.plugins.jms.JMSContainerInvoker$ExceptionListenerImpl.handleFailure(JMSContainerInvoker.java:1337)
| at org.jboss.ejb.plugins.jms.JMSContainerInvoker.startService(JMSContainerInvoker.java:845)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
| 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.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
| at $Proxy0.start(Unknown Source)
| at org.jboss.system.ServiceController.start(ServiceController.java:417)
| at sun.reflect.GeneratedMethodAccessor10.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.ServiceMBeanSupport.start(ServiceMBeanSupport.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)
| 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.jmx.adaptor.control.Server.invokeOpByName(Server.java:258)
| at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223)
| at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262)
| at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
| at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
| at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
| at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
| at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:419)
| at org.apache.catalina.valves.FastCommonAccessLogValve.invoke(FastCommonAccessLogValve.java:495)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
| at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
| at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
| at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
| at java.lang.Thread.run(Thread.java:595)
|
|
|
We then decided to do something more drastic and tried to destroy and recreate the bean. After creation the bean's state was stopped and everything looked good in the jmx-console. When we attempted to start delivery on the bean again it threw the exact same exception and the state changed to fail once again.
We then tried a hot redeploy of the MDB in the container (moved the jar out of deploy and back into deploy) This made no difference in the outcome and produced the exact same stack trace.
I scoured this forum (and the internet in general) for any solution but the only one I found was to take the exact same actions we had already taken. That was to restart the bean with (startDelivery method on mbean) which kept throwing the above error.
Since the volume here is large enough that people were starting to complain that the messages were not being processed we tried the only other solution we could think of, which was to restart the entire app server, which really should not be the solution in my opinion. Once restarted it processed the 2300+ messages backed up in the queue withing 30 or so minutes and is currently running Ok.
This code has been really stable historically as the app server almost never gets shut down. The last restart of the server we had was on 3/12/08 when we deployed code for another application (our admins have a bounce policy when deploying new code for some reason). The timestamp on the jar for this MDB is 11/18/2006 so it has been in production for almost 18 months without having any problems.
I guess my question would ultimately be:
Am I running into a 4.0.5 bug and need to upgrade my server?
The stack trace seems to indicate that the MDB's metadata has been dropped from the container. Why undeploying and redeploying would not correct this problem is probably a question for the developers.
Thaks for any info/insight anyone can provide.
Andre
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138363#4138363
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138363
18 years, 1 month