[JBoss Messaging] - Re: XARecovery: setting the provider name
by mskonda
As RecoveryManager starts before the DefaultJMSPrvider is hooked up, we may receive name not found exceptions something like this:
| 2007-03-14 16:14:26,542 INFO [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.info.loading] Local XARecoveryModule loading org.jboss.jms.recovery.MessagingXAResourceRecoveryDefaultJMSProvider
| 2007-03-14 16:14:26,549 ERROR [org.jboss.jms.recovery.MessagingXAResourceRecovery] Failed to look up provider adaptor
| javax.naming.NameNotFoundException: DefaultJMSProvider not bound
| at org.jnp.server.NamingServer.getBinding(NamingServer.java:529)
| at org.jnp.server.NamingServer.getBinding(NamingServer.java:537)
| at org.jnp.server.NamingServer.getObject(NamingServer.java:543)
| at org.jnp.server.NamingServer.lookup(NamingServer.java:296)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:625)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
| at javax.naming.InitialContext.lookup(InitialContext.java:351)
| at org.jboss.jms.recovery.MessagingXAResourceRecovery.initialise(MessagingXAResourceRecovery.java:102)
| at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.<init>(XARecoveryModule.java:356)
| at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.<init>(XARecoveryModule.java:76)
| at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
| at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
| at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
| at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
| at java.lang.Class.newInstance0(Class.java:350)
| at java.lang.Class.newInstance(Class.java:303)
| at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.loadModule(PeriodicRecovery.java:355)
| at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.loadModules(PeriodicRecovery.java:324)
| at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.<init>(PeriodicRecovery.java:85)
| at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:128)
| at com.arjuna.ats.arjuna.recovery.RecoveryManager.<init>(RecoveryManager.java:255)
| at com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:121)
| at com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:102)
| at com.arjuna.ats.jbossatx.jta.TransactionManagerService.startService(TransactionManagerService.java:140)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
| at sun.reflect.GeneratedMethodAccessor4.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 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.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy4.start(Unknown Source)
| at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
| 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 org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
| 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 $Proxy5.deploy(Unknown Source)
| at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
| at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
| at org.jboss.Main.boot(Main.java:200)
| at org.jboss.Main$1.run(Main.java:490)
| at java.lang.Thread.run(Thread.java:595)
| 2007-03-14 16:14:26,554 INFO [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.noxanodes] No XA recovery nodes specified. Will only recover saved states.
| 2007-03-14 16:14:26,559 INFO [com.arjuna.ats.arjuna.logging.arjLogger] RecoveryManagerImple is ready on port 41897
|
Supressing with a one-line waring message and retrying after the server is back(after few minutes) might do the cure.
Thanks
Madhu
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028017#4028017
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028017
19Â years, 1Â month
[JBoss Seam] - Re: since today (JBSEAM-954?) I get NPE in setEntityManagerF
by codelion
Exactly, I agree with
anonymous wrote : A missing login-required should be interpreted as null, and delegate to the more general widcard.
And that's where dom4j and the existing DTD are messing with us. Because there isn't a way to tell the login-required isn't there. Dom4j insists on saying it is false, per existing DTD, even if it isn't there.
Now people who don't want to use the new functionality can keep using the old DTD.
The "forcing" is meant to make sure one site uses the same DTD for all page.xml, because otherwise a single page could have an older DTD, which could be easy to overlook, e.g. copy and paste from an example.
The overlooked DTD would make that page less secure, no login-required, a bad oops.
The "forcing" is in a well isolated piece of the patch (yet to submit 3rd version) so it can/could be removed/not incorporated by itself.
I think it is figured out relatively nicely, so if it doesn't come across clearly I'll be happy to answer questions.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028015#4028015
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028015
19Â years, 1Â month
[JBoss Seam] - Re: seam, spring activemq
by henderson_mk
no luck .
changed it as you said:
|
| <bean id="listenerService"
| class="org.banana.services.UpdateListener"
| depends-on="broker1" lazy-init="true">
| <property name="brokerService"><ref local="broker1"/></property>
| <property name="springHook"><ref local="springHook"/></property>
| </bean>
|
| <seam:instance id="springHook" name="springHook" proxy="true" />
|
| @Name("springHook")
| @Scope(METHOD)
| @Intercept(ALWAYS)
| @Startup
| public class SpringHook {
| private static Log log = LogFactory.getLog(SpringHook.class);
|
| @In(create=true)
| private Session svDatabase;
|
| public void test(){
| log.info("hib session=" + this.svDatabase);
| }
|
| public Session getSession(){return this.svDatabase;}
| public void setSession(Session s){this.svDatabase = s;}
| }
|
|
|
but its barfing on startup now with error that seams needs to be configured before spring.
not to worry... I have the workaround anyhoo.
thanks for the help!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028013#4028013
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028013
19Â years, 1Â month
[EJB 3.0] - Dependency Injection of EntityManager / -Factory in Servlet
by pmaedel
Hello i would like to use Application-Managed Entitymanager in my Application and have been tryin to get Dependency Injection workin in my Servlet for quite a time now and have not found the error yet. The PersistenceUnit is mapped successfully when deployed on JBoss 4.0.5 but it seems to me that it is not reachable within the servlet for some reasons?
My directory structure:
lecker-ear.ear
\ META-INF ( application.xml, jboss-app.xml )
\ lecker-ejb.jar ( META-INF( persistence.xml, jboss.xml ), model.Login.java )
\ lecker-war.war ( WEB-INF( web.xml, jboss-web.xml ) + classes & jsps )
application.xml
<?xml version="1.0" encoding="UTF-8"?>
| <application xmlns="http://java.sun.com/xml/ns/javaee"
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
| xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
| http://java.sun.com/xml/ns/javaee/application_5.xsd"
| version="5">
| <display-name>MyApp</display-name>
| <module id="lecker-ejb">
| <ejb>lecker-ejb.jar</ejb>
| </module>
| <module id="lecker-war">
| <web>
| <web-uri>lecker-war.war</web-uri>
| <context-root>lecker-war</context-root>
| </web>
| </module>
| </application>
I have put this into the jboss-app.xml cause I read i need to specify som ClassLoader though I do not really understand how this is going to affect anything:
jboss-app.xml
<?xml version="1.0"?>
| <!DOCTYPE jboss-app PUBLIC "-//JBoss//DTD J2EE Application 1.4//EN"
| "http://www.jboss.org/j2ee/dtd/jboss-app_4_0.dtd">
| <jboss-app>
| <loader-repository>lecker-ear:archive=lecker-ear.ear</loader-repository>
| </jboss-app>
persistence.xml
| <?xml version="1.0" encoding="UTF-8"?>
| <persistence xmlns="http://java.sun.com/xml/ns/persistence">
| <persistence-unit name="leckerPU" transaction-type="JTA">
| <jta-data-source>java:/LeckerDS</jta-data-source>
| <class>model.Login</class>
| </persistence-unit>
|
web.xml
| <?xml version="1.0" encoding="UTF-8"?>
| <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
|
| <session-config>
| <session-timeout>
| 30
| </session-timeout>
| </session-config>
| <welcome-file-list>
| <welcome-file>Login.jsp</welcome-file>
| </welcome-file-list>
|
| <servlet>
| <servlet-name>LoginServlet</servlet-name>
| <servlet-class>Login</servlet-class>
| </servlet>
| <servlet-mapping>
| <servlet-name>LoginServlet</servlet-name>
| <url-pattern>/login</url-pattern>
| </servlet-mapping>
| </web-app>
|
I have tried several different ways to obtain the EntityManager within the Login Servlet but none worked. If I inject it directly the Objects just stay null:
Login.javal
| public class Login extends HttpServlet {
| @PersistenceUnit
| EntityManagerFactory emf;
| @PersistenceContext
| EntityManager em;
|
|
| protected final void doPost(final HttpServletRequest request, final HttpServletResponse response) throws ServletException, IOException {
| if(em ==null)
| System.out.println("em is null");
| if(emf ==null)
| System.out.println(" emf is null");
|
Specifying the UnitName doesnt help:
Login.javal
| public class Login extends HttpServlet {
| @PersistenceUnit(unitName = "leckerPU")
| EntityManagerFactory emf;
| @PersistenceContext(unitName = "leckerPU")
| EntityManager em;
|
|
| protected final void doPost(final HttpServletRequest request, final HttpServletResponse response) throws ServletException, IOException {
| if(em ==null)
| System.out.println("em is null");
| if(emf ==null)
| System.out.println(" emf is null");
|
If I try to look up the EntityManager or -Factory by JNDI I get a NameNotBound Exception what makes me think the problem already occurs while looking up the PU.
Login.javal
| @PersistenceContext(name="persistence/lecker", unitName = "leckerPU", type = PersistenceContextType.EXTENDED)
| public class Login extends HttpServlet {
|
| protected final void doPost(final HttpServletRequest request, final HttpServletResponse response) throws ServletException, IOException {
| try {
| EntityManager em = (EntityManager) new InitialContext().lookup("java:/comp/env/persistence/lecker");
| } catch (NamingException e) {
| System.out.println("grrh");
| e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates.
| }
| }
|
Looking up the EntityManagerFactory in JNDI doesnt work either.
So what am I actually doing wrong?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028003#4028003
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028003
19Â years, 1Â month
[JBossCache] - Memory leak when using JbossCache and JOTM
by atijms
Hi,
When using JbossCache in Tomcat 5.5 with JOTM as the JTA transaction manager, I stumbled upon a memory leak. After investigating with a profiler I noticed that an object I removed from JbossCache kept being referenced by a org.jboss.cache.marshall.JBCMethodCall, which was via among others a org.jboss.cache.TransactionEntry being referenced by a org.objectweb.jotm.SubCoordinator.
I'm using JBossCache in the typical way:
| TreeCache treeCache = new TreeCache();
| PropertyConfigurator config = new PropertyConfigurator();
| config.configure(treeCache, "META-INF/treecache.xml");
| treeCache.startService();
|
| UserTransaction tx = (UserTransaction) new GenericTransactionManagerLookup().getTransactionManager();
|
| tx.begin();
|
| treeCache.put( "/test" , "foo", someTestObject );
|
| tx.commit();
|
| treeCache.removeData( "/test" ); // extra, for test
| treeCache.remove( "/test" );
|
| treeCache.stopService();
| treeCache.destroyService();
|
After executing this code, "someTestObject" remains in memory.
Is this a known problem? Could it be a bug in JOTM or is the problem with JBossCache?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028001#4028001
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028001
19Â years, 1Â month