[EJB 3.0] - Re: can any one help me - having a bad day with ejb3 server
by wiggy
wolfgang,
I changed my 4.2 server ejb to
|
| @Stateless
| public class HelloUserBean implements HelloUserRemote
| {
|
explicitly as the interface that has the @Remote annotation and deploy to the 4.2 server.
if i then do the basic jndi lookup from the embedded server then i get a valid reference and the test call works.
however if i try to use DI in the embedded server to get a reference to the ejb it doesnt work and i get
anonymous wrote :
| 59,433 INFO [MCKernelAbstraction] installing bean: jboss.j2ee:jar=bin,name=TestBean,service=EJB3 with dependencies:
| 17:22:59,603 INFO [EJBContainer] STARTED EJB: TestBean ejbName: TestBean
| 17:22:59,623 INFO [MCKernelAbstraction] installing bean: jboss.j2ee:jar=classes,name=HelloUserBean,service=EJB3 with dependencies:
| 17:22:59,633 INFO [EJBContainer] STARTED EJB: app.HelloUserBean ejbName: HelloUserBean
| Exception in thread "main" java.lang.NullPointerException
| at ClientApp.init(ClientApp.java:75)
| at ClientApp.main(ClientApp.java:61)
|
from test code now looking like
| /**
| *
| */
| import java.util.Hashtable;
|
| import javax.ejb.EJB;
| import javax.naming.InitialContext;
|
|
| import org.apache.log4j.Level;
| import org.apache.log4j.Logger;
| import org.jboss.ejb3.embedded.EJB3StandaloneBootstrap;
|
| import app.client.HelloUser;
| import app.client.HelloUserRemote;
|
| /**
| * @author Will
| *
| */
| public class ClientApp
| {
| @EJB (name="HelloUserRemote")
| public HelloUserRemote tstHandler;
|
| @EJB (name="Test")
| public Test test;
|
| public ClientApp () {}
|
| public static void main(String[] args) throws Exception
| {
|
| Logger log = Logger.getLogger(ClientApp.class);
| log.setLevel(Level.DEBUG);
| //log.debug("Welcome to Wills App");
|
| // Boot the JBoss Microcontainer with EJB3 settings, automatically
| // loads ejb3-interceptors-aop.xml and embedded-jboss-beans.xml
| EJB3StandaloneBootstrap.boot(null);
|
| // Deploy custom stateless beans (datasource, mostly)
| //EJB3StandaloneBootstrap.deployXmlResource("META-INF/NeilsApp-beans.xml");
|
| // Deploy all EJBs found on classpath (fast, scans build directory)
| // This is a relative location, matching the substring end of one
| // of java.class.path locations. Print out the value of
| // System.getProperty("java.class.path") to see all paths.
| EJB3StandaloneBootstrap.scanClasspath();
|
| InitialContext ctx = getInitialContext();
|
|
| // Look up the stateless TestHandler EJB
| //HelloUserRemote tstHandlerLoc = (HelloUserRemote) ctx.lookup("HelloUserBean/remote");
| // Call the stateless EJB
| //String message = tstHandlerLoc.sayHello("hello Will");
|
| //try dependency injection!
| //new TestBean().message("hi there");
| new ClientApp().init ();
|
|
|
|
| //Shut down EJB container
| EJB3StandaloneBootstrap.shutdown();
|
| }
|
| public void init()
| {
| //trigger the DI for test
| //test.message("try again");
| tstHandler.sayHello("hello there via DI");
| }
| ...
|
|
my tstHandler is a DI injected reference in the top of the clientApp class.
This gets the null pointer ref - hence the embedded container DI isnt working - but my jndi hard work version does - why cant the DI pick up the remote reference in the embedded app version ? (I new i think that 4.2AS didnt have the application client loader - hence the use of the embedded container to run my client class.
Wiggy
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4049086#4049086
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4049086
19 years, 1 month
[JBoss jBPM] - Re: logging process execution in file instead of database
by pattchen
anonymous wrote : 3: it is only to a small extend for logs (although it might be the biggest amount of data).
that's the problem!! I don't want to use a database to store process (even at deploytime). So, if I use db logging,i must create a database just for that.
(I works on a JAVA SE application which will load a process definition from an xml file every minute and execute it.)
anonymous wrote :
| 5: ok, but only part of that is in the logs
That's good to know...
anonymous wrote : 6: a small delete statement on a db could work as well, right?
It's right.
Another issue I 've just think about:
Database logging is more slower than file logging (isn't it?please correct me if I'm wrong), and since the process must be executed as fast as possible (it processes a client request ),and that the only logging use case which interests me is undo functionality, db logging seems to be overkill...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4049081#4049081
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4049081
19 years, 1 month
[JBoss Seam] - Treecache / JBoss Cache Issue
by cwiesing
Hello,
I have a problem with the treecache configuration. First of all I?m my application runs under the following versions:
JBoss 4.0.5 GA
JBoss Seam 1.2.1 GA
JBoss Cache 1.4.0 SP1
Hibernate 3.2.0 GA
The treecache.xml is looking like this:
| <?xml version="1.0" encoding="UTF-8" ?>
| <server>
| <classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar" />
|
| <mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=TreeCache">
| <depends>jboss:service=Naming</depends>
| <depends>jboss:service=TransactionManager</depends>
|
| <attribute name="TransactionManagerLookupClass">org.jboss.cache.JBossTransactionManagerLookup</attribute>
| <attribute name="NodeLockingScheme">PESSIMISTIC</attribute>
| <attribute name="IsolationLevel">NONE</attribute>
|
| <attribute name="CacheMode">LOCAL</attribute>
|
| <attribute name="UseInterceptorMbeans">false</attribute>
|
| <attribute name="LockAcquisitionTimeout">15000</attribute>
|
| <attribute name="EvictionPolicyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
|
| <attribute name="EvictionPolicyConfig">
| <config>
| <attribute name="wakeUpIntervalSeconds">5</attribute>
| <region name="/_default_">
| <attribute name="maxNodes">10000</attribute>
| <attribute name="timeToLiveSeconds">3600</attribute>
| <attribute name="maxAgeSeconds">86400</attribute>
| </region>
| <region name="/net/package/xxx">
| <attribute name="maxNodes">5000</attribute>
| <attribute name="timeToLiveSeconds">30</attribute>
| </region>
| </config>
| </attribute>
|
| <attribute name="CacheLoaderConfiguration">
| <config>
| <passivation>false</passivation>
| <shared>false</shared>
|
| <cacheloader>
| <class>org.jboss.cache.loader.FileCacheLoader</class>
| <properties>
| location=treecache
| </properties>
| <async>false</async>
| <fetchPersistentState>true</fetchPersistentState>
| <ignoreModifications>false</ignoreModifications>
|
| <purgeOnStartup>true</purgeOnStartup>
| </cacheloader>
| </config>
| </attribute>
| </mbean>
| </server>
|
I?m using the EntityManager with ExtendedPersistenceContext. So when I try an update of a dataset the following Exception is thrown:
| [17:26:07] [Administrator] [INFO ] [...STDOUT :152 ] >> Hibernate: update SCHEMA.CONTRACT set description=? where id=?
| [17:26:07] [Administrator] [WARN ] [...che.interceptors.TxInterceptor:104 ] >> Commit failed. Clearing stale locks.
| [17:26:07] [Administrator] [ERROR] [....OrderedSynchronizationHandler:119 ] >> failed calling afterCompletion() on TxInterceptor.LocalSynchronizationHandler(gtx=GlobalTransaction:<null>:5, tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=urraco/25, BranchQual=, localId=25])
| java.lang.RuntimeException: Commit failed.
| at org.jboss.cache.interceptors.TxInterceptor.runCommitPhase(TxInterceptor.java:716)
| at org.jboss.cache.interceptors.TxInterceptor$RemoteSynchronizationHandler.afterCompletion(TxInterceptor.java:1007)
| at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.afterCompletion(TxInterceptor.java:1103)
| at org.jboss.cache.interceptors.OrderedSynchronizationHandler.afterCompletion(OrderedSynchronizationHandler.java:83)
| at org.jboss.tm.TransactionImpl.doAfterCompletion(TransactionImpl.java:1526)
| at org.jboss.tm.TransactionImpl.completeTransaction(TransactionImpl.java:1198)
| at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:377)
| at org.jboss.tm.TxManager.commit(TxManager.java:240)
| at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:140)
| at org.jboss.seam.jsf.AbstractSeamPhaseListener.commitOrRollback(AbstractSeamPhaseListener.java:324)
| at org.jboss.seam.jsf.TransactionalSeamPhaseListener.handleTransactionsAfterPhase(TransactionalSeamPhaseListener.java:45)
| at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:111)
| at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager.java:89)
| at org.apache.myfaces.lifecycle.LifecycleImpl.invokeApplication(LifecycleImpl.java:345)
| at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:86)
| at javax.faces.webapp.FacesServlet.service(FacesServlet.java:137)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at net.tmobile.trp.security.AuthorizationFilter.doFilter(AuthorizationFilter.java:89)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:127)
| at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:277)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:63)
| at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:60)
| at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
| at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
| at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
| at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:57)
| at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
| at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:79)
| at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
| at org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| 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:432)
| 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.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)
| Caused by: java.lang.Exception: transaction GlobalTransaction:<null>:5 not found in transaction table
| at org.jboss.cache.loader.FileCacheLoader.commit(FileCacheLoader.java:220)
| at org.jboss.cache.interceptors.CacheStoreInterceptor.invoke(CacheStoreInterceptor.java:95)
| at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
| at org.jboss.cache.interceptors.CacheLoaderInterceptor.invoke(CacheLoaderInterceptor.java:197)
| at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
| at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
| at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
| at org.jboss.cache.interceptors.TxInterceptor.handleCommitRollback(TxInterceptor.java:660)
| at org.jboss.cache.interceptors.TxInterceptor.runCommitPhase(TxInterceptor.java:702)
| ... 57 more
|
I tried to debug the source code and it seams like that the prepare-Method of the JBoss-Cache is never called before the commit-Method (which includes the remove-Statement) was called.
But when I remove the CacheLoaderConfiguration part from my treecache-configuration it seams to be working.
Which reason can caused this Exception?
Thanks in advance
Christian
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4049079#4049079
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4049079
19 years, 1 month
[Installation, Configuration & Deployment] - Could not start on port 1099, Address already in use
by sirji
Hi all,
I am seeing following error message everytime, I start my JBoss server instance 4.0.5.
| 21:14:30,807 INFO [Log4jService$URLWatchTimerTask] Configuring from URL: resource:jboss-log4j.xml
| 21:14:31,198 ERROR [NamingService] Could not start on port 1099
| java.net.BindException: Address already in use: JVM_Bind
| at java.net.PlainSocketImpl.socketBind(Native Method)
| at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359)
| at java.net.ServerSocket.bind(ServerSocket.java:319)
| at java.net.ServerSocket.<init>(ServerSocket.java:185)
| at javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:169)
| at org.jnp.server.Main.initBootstrapListener(Main.java:354)
| at org.jnp.server.Main.start(Main.java:305)
| at org.jboss.naming.NamingService.startService(NamingService.java:243)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
| at sun.reflect.GeneratedMethodAccessor2.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.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 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 $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)
|
>From the error stack trace, I can understand that it is binded by some other application. But using active port, I can see that it is binded by a JVM instance.
Trust me, this is the ONLY jvm instance I have running. Verified through task manager. I have also tried to change it to something else. But I am seeing the same error message with different port.
Any assistance will be helpful.
Thanks & regards,
SR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4049076#4049076
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4049076
19 years, 1 month
[JBoss Seam] - Re: Domain model duplicates validation
by fernando_jmt
Hi.
anonymous wrote :
| But in some weird case where my validation require some kind of twisted logic using some properties from the Person entity and all the other entities already persisted, is there a clean way to add this logic in the model? Or this is conceptually wrong?
|
For me, putting validation logic in your model is nasty. And it's conceptually wrong. If you want to validate something related to one or several entities, and you don't have another way to do it (according your requirements) then you should perfom such validation in your controller (SLSB or SFSB).
The example I gave you it was recently adopted by me for validate duplicates for an entity (of course when the properties are not the @Ids). Time ago I was doing this validation in a session bean, something as follows:
| public void persis(Person entity){
|
| try {
| em.createQuery("select p from P where p.lastName=:lastName and
| p.firstName = :firstName).setParameter("lastName",
| entity.lastName).setParameter("firstName",
| entity.firstName).getSingleResult();
|
| //user exists, then throw some AlreadyExistException.
| } catch (NoResultException e) {
| em.persist(entity);
| }
|
| }
|
But the above code involves two SQL's:
| select from person ...where lastname....
| insert into person...... (if the above sql does not return value)
|
But delegating this validation to DB layer (@UniqueConstraint) the only SQL will always be:
| insert into person....
|
So, in order to reduce the DB round trip I decided to use DB approach for this case. Of course, if you are free to make changes in the database schema. I think this is total portable, because I don't know some database server that does not allow to use "UNIQUE" constraints.
anonymous wrote : The validation you gave me works great. The only complain is that a get some error logs about:
Yes, this is annoying, I ask the same time ago, see below link (I din't try it yet myself):
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=98560
anonymous wrote :
| Hey, i'm your neighbor! From Paraguay :D
|
Nice to hear it.
Cheers.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4049075#4049075
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4049075
19 years, 1 month