[JBoss Seam] - Re: Quartz TimerService
by dilator
Ok getting a bit closer - been rooting about FishEye and I came across a new ejb-timer-service.xml yay!
| <?xml version="1.0" encoding="UTF-8"?>
| <server>
| <!-- TODO: the ejb deployer must depend on this -->
|
| <!-- ================================================ -->
| <!-- Defines the Quartz configuration for -->
| <!-- the EJB3 Timer Service -->
| <!-- ================================================ -->
| <mbean code="org.jboss.ejb3.timerservice.quartz.jmx.EJB3TimerService" name="jboss.ejb:service=EJB3TimerService">
| <depends>jboss:service=Naming</depends>
|
| <depends>jboss:service=TransactionManager</depends>
| <depends optional-attribute-name="DataSource">jboss.jca:service=DataSourceBinding,name=DefaultDS</depends>
|
| <attribute name="Properties">
| org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreCMT
| org.quartz.jobStore.nonManagedTXDataSource=myDS
| org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.HSQLDBDelegate
| org.quartz.jobStore.tablePrefix=QRTZ_
| org.quartz.jobStore.dataSource=myDS
|
| # To get it to work with hypersonic
| # FIXME: this doesn't lock the row
| org.quartz.jobStore.selectWithLockSQL=SELECT * FROM qrtz_locks WHERE lock_name = ?
|
| # from quartz.properties
| org.quartz.scheduler.instanceName=JBossEJB3QuartzScheduler
| org.quartz.scheduler.rmi.export=false
| org.quartz.scheduler.rmi.proxy=false
| org.quartz.scheduler.wrapJobExecutionInUserTransaction=false
|
| org.quartz.threadPool.class=org.quartz.simpl.SimpleThreadPool
| org.quartz.threadPool.threadCount=10
| org.quartz.threadPool.threadPriority=5
| org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread=true
|
| org.quartz.jobStore.misfireThreshold=60000
| </attribute>
| <attribute name="SqlProperties">
| CREATE_DB_ON_STARTUP = TRUE
|
| CREATE_TABLE_JOB_DETAILS = CREATE TABLE qrtz_job_details(JOB_NAME VARCHAR(80) NOT NULL, JOB_GROUP VARCHAR(80) NOT NULL, \
| DESCRIPTION VARCHAR(120) NULL, JOB_CLASS_NAME VARCHAR(128) NOT NULL, IS_DURABLE VARCHAR(1) NOT NULL, \
| IS_VOLATILE VARCHAR(1) NOT NULL, IS_STATEFUL VARCHAR(1) NOT NULL, REQUESTS_RECOVERY VARCHAR(1) NOT NULL, \
| JOB_DATA BINARY NULL, PRIMARY KEY (JOB_NAME,JOB_GROUP))
| CREATE_TABLE_JOB_LISTENERS = CREATE TABLE qrtz_job_listeners(JOB_NAME VARCHAR(80) NOT NULL, JOB_GROUP VARCHAR(80) NOT NULL, \
| JOB_LISTENER VARCHAR(80) NOT NULL, PRIMARY KEY (JOB_NAME,JOB_GROUP,JOB_LISTENER), FOREIGN KEY (JOB_NAME,JOB_GROUP) \
| REFERENCES QRTZ_JOB_DETAILS(JOB_NAME,JOB_GROUP))
| CREATE_TABLE_TRIGGERS = CREATE TABLE qrtz_triggers(TRIGGER_NAME VARCHAR(80) NOT NULL, TRIGGER_GROUP VARCHAR(80) NOT NULL, \
| JOB_NAME VARCHAR(80) NOT NULL, JOB_GROUP VARCHAR(80) NOT NULL, IS_VOLATILE VARCHAR(1) NOT NULL, DESCRIPTION VARCHAR(120) NULL, \
| NEXT_FIRE_TIME NUMERIC(13) NULL, PREV_FIRE_TIME NUMERIC(13) NULL, TRIGGER_STATE VARCHAR(16) NOT NULL, \
| TRIGGER_TYPE VARCHAR(8) NOT NULL, START_TIME NUMERIC(13) NOT NULL, END_TIME NUMERIC(13) NULL, CALENDAR_NAME VARCHAR(80) NULL, \
| MISFIRE_INSTR NUMERIC(2) NULL, JOB_DATA BINARY NULL, PRIMARY KEY (TRIGGER_NAME,TRIGGER_GROUP), FOREIGN KEY (JOB_NAME,JOB_GROUP) \
| REFERENCES QRTZ_JOB_DETAILS(JOB_NAME,JOB_GROUP))
| CREATE_TABLE_SIMPLE_TRIGGERS = CREATE TABLE qrtz_simple_triggers(TRIGGER_NAME VARCHAR(80) NOT NULL, \
| TRIGGER_GROUP VARCHAR(80) NOT NULL, REPEAT_COUNT NUMERIC(7) NOT NULL, REPEAT_INTERVAL NUMERIC(12) NOT NULL, \
| TIMES_TRIGGERED NUMERIC(7) NOT NULL, PRIMARY KEY (TRIGGER_NAME,TRIGGER_GROUP), FOREIGN KEY (TRIGGER_NAME,TRIGGER_GROUP) \
| REFERENCES QRTZ_TRIGGERS(TRIGGER_NAME,TRIGGER_GROUP))
| CREATE_TABLE_CRON_TRIGGERS = CREATE TABLE qrtz_cron_triggers(TRIGGER_NAME VARCHAR(80) NOT NULL, \
| TRIGGER_GROUP VARCHAR(80) NOT NULL, CRON_EXPRESSION VARCHAR(80) NOT NULL, TIME_ZONE_ID VARCHAR(80), \
| PRIMARY KEY (TRIGGER_NAME,TRIGGER_GROUP), FOREIGN KEY (TRIGGER_NAME,TRIGGER_GROUP) \
| REFERENCES QRTZ_TRIGGERS(TRIGGER_NAME,TRIGGER_GROUP))
| CREATE_TABLE_BLOB_TRIGGERS = CREATE TABLE qrtz_blob_triggers(TRIGGER_NAME VARCHAR(80) NOT NULL, \
| TRIGGER_GROUP VARCHAR(80) NOT NULL, BLOB_DATA BINARY NULL, PRIMARY KEY (TRIGGER_NAME,TRIGGER_GROUP), \
| FOREIGN KEY (TRIGGER_NAME,TRIGGER_GROUP) REFERENCES QRTZ_TRIGGERS(TRIGGER_NAME,TRIGGER_GROUP))
| CREATE_TABLE_TRIGGER_LISTENERS = CREATE TABLE qrtz_trigger_listeners(TRIGGER_NAME VARCHAR(80) NOT NULL, \
| TRIGGER_GROUP VARCHAR(80) NOT NULL, TRIGGER_LISTENER VARCHAR(80) NOT NULL, \
| PRIMARY KEY (TRIGGER_NAME,TRIGGER_GROUP,TRIGGER_LISTENER), FOREIGN KEY (TRIGGER_NAME,TRIGGER_GROUP) \
| REFERENCES QRTZ_TRIGGERS(TRIGGER_NAME,TRIGGER_GROUP))
| CREATE_TABLE_CALENDARS = CREATE TABLE qrtz_calendars(CALENDAR_NAME VARCHAR(80) NOT NULL, CALENDAR BINARY NOT NULL, \
| PRIMARY KEY (CALENDAR_NAME))
| CREATE_TABLE_PAUSED_TRIGGER_GRPS = CREATE TABLE qrtz_paused_trigger_grps(TRIGGER_GROUP VARCHAR(80) NOT NULL, \
| PRIMARY KEY (TRIGGER_GROUP))
| CREATE_TABLE_FIRED_TRIGGERS = CREATE TABLE qrtz_fired_triggers(ENTRY_ID VARCHAR(95) NOT NULL, TRIGGER_NAME VARCHAR(80) NOT NULL, \
| TRIGGER_GROUP VARCHAR(80) NOT NULL, IS_VOLATILE VARCHAR(1) NOT NULL, INSTANCE_NAME VARCHAR(80) NOT NULL, \
| FIRED_TIME NUMERIC(13) NOT NULL, STATE VARCHAR(16) NOT NULL, JOB_NAME VARCHAR(80) NULL, JOB_GROUP VARCHAR(80) NULL, \
| IS_STATEFUL VARCHAR(1) NULL, REQUESTS_RECOVERY VARCHAR(1) NULL, PRIMARY KEY (ENTRY_ID))
| CREATE_TABLE_SCHEDULER_STATE = CREATE TABLE qrtz_scheduler_state(INSTANCE_NAME VARCHAR(80) NOT NULL, \
| LAST_CHECKIN_TIME NUMERIC(13) NOT NULL, CHECKIN_INTERVAL NUMERIC(13) NOT NULL, RECOVERER VARCHAR(80) NULL, \
| PRIMARY KEY (INSTANCE_NAME))
| CREATE_TABLE_LOCKS = CREATE TABLE qrtz_locks(LOCK_NAME VARCHAR(40) NOT NULL, PRIMARY KEY (LOCK_NAME))
| INSERT_TRIGGER_ACCESS = INSERT INTO qrtz_locks values('TRIGGER_ACCESS')
| INSERT_JOB_ACCESS = INSERT INTO qrtz_locks values('JOB_ACCESS')
| INSERT_CALENDAR_ACCESS = INSERT INTO qrtz_locks values('CALENDAR_ACCESS')
| INSERT_STATE_ACCESS = INSERT INTO qrtz_locks values('STATE_ACCESS')
| INSERT_MISFIRE_ACCESS = INSERT INTO qrtz_locks values('MISFIRE_ACCESS')
| </attribute>
|
| </mbean>
| </server>
|
And that seems to get the Quartz implementation going. But looks like it's not quite finished :D
| Caused by: java.lang.RuntimeException: NYI
| at org.jboss.ejb3.timerservice.quartz.TimerServiceImpl.getTimers(TimerServiceImpl.java:207)
|
Getting there!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994438#3994438
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994438
19 years, 7 months
[JBoss Seam] - Re: Quartz TimerService
by dilator
I've not tried using Quartz via the resource adapter - I'll have to check that out. I was more interested in using Quartz as a drop-in replacement for the EJB TimerService.
My main reason for this is I would like to create an arbitrarily large set of timers (for example 2 or 3 timers for each user on a website). As I understand (and have done a bit of testing which confirms this), that whilst the default TimerService implementation uses java.util.Timer, it creates a new java.util.Timer for every ejb Timer requested, rather than scheduling a new entry on an existing Timer - so basically 1 thread per ejb Timer, which obviously does not scale. As far as I can see there is no reason why this could not be implemented differently?
Anyways http://jira.jboss.org/jira/browse/EJBTHREE-619 says you simply have to change a system property to get the Quartz implementation running. I've done this, and can see that the QuartzTimerServiceFactory is being created, but no TimerServices are being injected anymore, so something isn't quite right...
I'm suprised I don't have to change anything in the ejb-timer-service.xml?
Thanks again - i'll cross post this to the EJB3 forum too
ben
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994435#3994435
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994435
19 years, 7 months
[EJB 3.0] - Re: ClassCastException with ActiveMQ RA
by dyzma
I have a similar problem with MDB from EJB 2 (not from EJB 3). To access ActiveMQ from JBoss I am following the instructions from this article http://devzone.logicblaze.com/site/integrating-apache-activemq-with-jboss.... The only difference is I have ActiveMQ running on a separate machine, whereas in the article ActiveMQ runs in embedded mode. That is why I have the following entry in ra.xml:
<config-property>
Sets the XML configuration file used to configure the embedded ActiveMQ broker via
Spring if using embedded mode.
BrokerXmlConfig is the filename which is assumed to be on the classpath unless
a URL is specified. So a value of foo/bar.xml would be assumed to be on the
classpath whereas file:dir/file.xml would use the file system.
Any valid URL string is supported.
<config-property-name>BrokerXmlConfig</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
(the difference is that in the article the config-property-value is set to xbean:broker-config.xml, and in my ra.xml it is empty).
During JBoss startup I am getting the following error:
17:06:25,546 WARN [JMSContainerInvoker] JMS provider failure detected for ApplicationRecieve
org.jboss.deployment.DeploymentException: Error during queue setup; - nested throwable: (java.lang.ClassCastException: org.apache.activemq.command.ActiveMQQueue)
at org.jboss.deployment.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:53)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker.innerStartDelivery(JMSContainerInvoker.java:811)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker.startService(JMSContainerInvoker.java:839)
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.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.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.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:194)
at org.jboss.ejb.MessageDrivenContainer.startService(MessageDrivenContainer.java:272)
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.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.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 $Proxy54.start(Unknown Source)
at org.jboss.ejb.EjbModule.startService(EjbModule.java:429)
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.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.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 $Proxy25.start(Unknown Source)
at org.jboss.ejb.EJBDeployer.start(EJBDeployer.java:662)
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.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
at org.jboss.ws.integration.jboss.DeployerInterceptor.start(DeployerInterceptor.java:92)
at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
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 $Proxy26.start(Unknown Source)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor54.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 $Proxy8.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
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.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.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 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)
Caused by: java.lang.ClassCastException: org.apache.activemq.command.ActiveMQQueue
at org.jboss.mq.SpyConnectionConsumer.(SpyConnectionConsumer.java:107)
at org.jboss.mq.SpyConnection.createConnectionConsumer(SpyConnection.java:209)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker.innerStartDelivery(JMSContainerInvoker.java:795)
... 159 more
I am using jboss 4.0.4 and activemq 4.0.1. I have checked that same situation occures while using jboss 4.0.5.
Could you help me with solving this problem? Does a document that better describes JBoss and ActiveMQ integration exists?
Regards,
Lukasz Indyk.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994433#3994433
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994433
19 years, 7 months
[JBoss jBPM] - AssignmentHandler problem
by bnsbr
Hi all,
I was trying to implement an AssignmentHandler to replace the ExpressionAssignmentHandler. In the docs, the section '11.11.3. Removing the identity component', says:
anonymous wrote :
| The ExpressionAssignmentHandler is dependent on the identity component so you will not be able to use it as is. In case you want to reuse the ExpressionAssignmentHandler and bind it to your user data store, you can extend from the ExpressionAssignmentHandler and override the method getExpressionSession.
|
Following these instructions, I especified my AssignmentHandler implementation (that extends ExpressionAssignmentHandler) at the 'class' attribute of the assignment tag and found that my AssignmentHandler wasn't instantiated when the 'expression' attribute is especified in the same tag.
There are any other necessary steps to take, other than extending the ExpressionAssignmentHandler, override its method and specify the new class at the 'class' attribute in the assignment tag ?
Any help appreciated!
Thanks,
Bruno
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994426#3994426
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994426
19 years, 7 months
[JBoss Portal] - hibernate exception
by m.heidari
hello,
i have a portlet that connection to MSsql server via hibernate but time of this query is very long and at last i see exception on my page.
in portal-sqlserver-ds.xml i locate this code:
<max-pool-size>200</max-pool-size>
| <min-pool-size>1</min-pool-size>
| <idle-timeout-minutes>100</idle-timeout-minutes>
| but yet i see this exception:
| javax.servlet.ServletException: Transaction is not active: tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=portalserver/4717, BranchQual=, localId=4717]
| org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:214)
| javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
| javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
|
| if you have solution for this problem please help me.
| thanks
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994420#3994420
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994420
19 years, 7 months
[JBoss Seam] - Re: Seam 1.1.5 & SeamSecurity...
by fcorneli
anonymous wrote : <s:secure> is gone, it's been replaced with EL expressions s:hasRole and s:hasPermission.
Does this mean that the "view" will also have servlet container security enabled on it? In my own Seam application I've places only the controller Seam BBs within a security domain. Thus these components can use the @RolesAllowed stuff. I'm using a servlet filter to push the session credentials to the client-login JAAS context. My view has no servlet container security enabled on it, but it can access the current used via #{currentUser} if needed for view purposes only, since that's the only task of the view (SoC). For this I used a simple Tomcat valve configured via context.xml.
IMHO the view should not have security enabled on it, since it can only expose data or perform operations via the controller components. Thus placing the controller components inside a security domain does the trick. Servlet container security doesn't bring anything in case of an MVC framework like Seam. And, since Seam 1.1 we can have a nice error page in case of an RBAC exception, thus the view does not need to get access to the RBAC itself. This is also in line with another security aspect: input validation. Via the Hibernate annotations, they've also made the view "dumb" as it comes to input validation. Anyone has opinion on this? Can anyone already shed some light on which direction this is going to take? At JavaPolis someone of JBoss said they where going to use a rules thingy for the Seam security... KISS please... we already have a security system via EJB3, one should be enough.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994418#3994418
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994418
19 years, 7 months
[JBoss Seam] - Re: Quartz TimerService
by msduk
This worked fine for me. I have the quartz jar in the lib folder and I believe that was it. This is on 4.0.5 GA.
I noticed that I have jobs.xml, .properties and the xsd in my WEB-INF from an earlier attempt to run it the non-ejb way. Maybe it requires this?
@MessageDriven(activationConfig = { @ActivationConfigProperty(propertyName = "cronTrigger", propertyValue = "0/15 * * * * ?") })
| @ResourceAdapter("quartz-ra.rar")
|
| public class TestQuartzTarget implements Job {
|
| @PersistenceContext
| EntityManager em;
|
| private static final Logger log = Logger
| .getLogger(TestQuartzTarget.class);
|
| public PendingOrderQuartzTarget() {
| super();
| System.out.println("Quartz-bean is constructed()");
| }
|
| public void execute(JobExecutionContext jobExecutionContext)
| throws JobExecutionException {
|
| long start = System.currentTimeMillis();
|
| log.debug(this.getClass().getName() + " STARTING RUN");
| log.debug(em);
|
| //Do your work here
|
| log.debug(this.getClass().getName() + " FINISHING RUN");
| log.debug("RUNTIME: " + (System.currentTimeMillis() - start) + " ms");
| }
|
| }
>From web.xml
<servlet>
| <servlet-name>QuartzInitializer</servlet-name>
| <servlet-class>org.quartz.ee.servlet.QuartzInitializerServlet</servlet-class>
|
| <init-param>
| <param-name>config-file</param-name>
| <param-value>quartz-nrg2.properties</param-value>
| </init-param>
|
| <init-param>
| <param-name>shutdown-on-unload</param-name>
| <param-value>true</param-value>
| </init-param>
|
| <init-param>
| <param-name>start-scheduler-on-load</param-name>
| <param-value>true</param-value>
| </init-param>
| <load-on-startup>1</load-on-startup>
| </servlet>
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994405#3994405
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994405
19 years, 7 months
[JBoss Seam] - Re: Seam & Maven2
by mzeijen
I have been look through the current JBoss maven2 repository at http://repository.jboss.com/maven2. I have noticed that it isn't really maintained. I also have some remarks on the JBoss artifact structure within it:
1. Most JBoss artifacts have a groupId of 'jboss' and some 'org.jboss'. I.M.H.O this should be 'org.jboss'. The idea behind the groupId is the same idea behind packages of Java. You should use the domain of the creators of the library as groupId.
2. The current 1.01-GA artifacts (core, ui, debug) of seam have the groupId 'jboss'. I.M.H.O this should be 'org.jboss.seam'. This groups the seam libraries within on group and makes it easier to find/maintain.
3. The current version used is 1.0.1-GA. This reflects the version that is used by JBoss itself. I am not so sure if it is a good id to use the GA within Maven2 versions. In Maven2 the -{code} behind a version number represents a qualifier. A qualifier is intended to indicate a version prior to a release. So the use of -alpha, -beta, -cr1, etc isn't a problem, but we probably shouldn't use the GA because Maven2 then doesn't see the library as a release. The GA could result in problems with the dependency management of Maven2.
Is there someone who I can contact about the Maven2 repository of JBoss?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994404#3994404
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994404
19 years, 7 months
[JBoss/Spring Integration] - Re: Spring deployer + cluster
by alesj
anonymous wrote : Does the applicationcontext get registred under jndi?
Yes.
This is the code that does it (AbstractBeanFactoryLoader class):
NonSerializableFactory is used, since we don't want to impound Serializability to all of our beans.
| // JNDI stuff
|
| public static void bind(BeanFactory beanFactory, String name) throws BeansException
| {
| InitialContext ctx = null;
| try
| {
| ctx = new InitialContext();
| NonSerializableFactory.rebind(ctx, name, beanFactory);
| }
| catch (NamingException e)
| {
| throw new FatalBeanException("Unable to bind BeanFactory into JNDI", e);
| }
| finally
| {
| if (ctx != null)
| {
| try
| {
| ctx.close();
| }
| catch (Throwable ignored)
| {
| }
| }
| }
| }
|
anonymous wrote : Would it mean that using a cluster jndi I would have a single bean shared through the cluster
Hmm ... never tried it. But you can probably try HAJndi.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994398#3994398
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994398
19 years, 7 months
[JBoss/Spring Integration] - EJB3 SLSB from Spring MVC
by leetgeezer
Hello,
I am designing an app using Spring MVC + EJB3. Both Web and EJB modules get packaged into MyApp.ear and deployed into JBoss 4.0.5GA. Currently, to reference the stateless session bean (local if.) from one of the Controllers, I say:
| InitialContext ctx = new InitialContext();
| userService = (UserService) ctx.lookup(
| "MyApp/UserServiceBean/local");
|
What I don't like, however, is that this method relies on "MyApp/UserServiceBean/local" string (What if, say, MyApp name changes?)
My question is: is there any better way (DI?) to reference the stateless session bean locally? I checked Spring's LocalStatelessSessionProxyFactoryBean but it appears that it applies to EJB 2.1 (Home IF's & stuff). Does @EJB or @Resource apply here?
Regards,
Leet Geezer
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994397#3994397
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994397
19 years, 7 months
[JBossCache] - Re: Problem with JBoss JDBCCacheLoader
by archanaa_panda
Thanks a lot, Hany. Yes I seem to have goofed up with the cache configuration. The real one is below :)). Sorry about that. I will definitely try your suggestion - this looks to be a very plausible reason for the problem. I will let you know the result in my next post. In the meantime, just take a look at the actual configuration I am posting below and let me know if you find anything else that attracts your attention-
<?xml version="1.0" encoding="UTF-8"?>
|
| <!-- ===================================================================== -->
| <!-- -->
| <!-- Sample TreeCache Service Configuration -->
| <!-- -->
| <!-- ===================================================================== -->
|
| <server>
|
| <classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar"/>
|
|
| <!-- ==================================================================== -->
| <!-- Defines TreeCache configuration -->
| <!-- ==================================================================== -->
|
| <mbean code="org.jboss.cache.TreeCache"
| name="jboss.cache:service=ArchTreeCache">
|
| <depends>jboss:service=Naming</depends>
| <depends>jboss:service=TransactionManager</depends>
|
| <!--
| Configure the TransactionManager
| -->
| <attribute name="TransactionManagerLookupClass">org.jboss.cache.DummyTransactionManagerLookup</attribute>
|
| <!--
| Isolation level : SERIALIZABLE
| REPEATABLE_READ (default)
| READ_COMMITTED
| READ_UNCOMMITTED
| NONE
| -->
| <!--
| <attribute name="NodeLockingScheme">OPTIMISTIC</attribute>
| -->
|
| <attribute name="IsolationLevel">READ_COMMITTED</attribute>
|
| <!--
| Valid modes are LOCAL
| REPL_ASYNC
| REPL_SYNC
| INVALIDATION_ASYNC
| INVALIDATION_SYNC
| -->
| <attribute name="CacheMode">REPL_SYNC</attribute>
|
| <!--
| Just used for async repl: use a replication queue
| -->
| <attribute name="UseReplQueue">false</attribute>
|
| <!--
| Replication interval for replication queue (in ms)
| -->
| <attribute name="ReplQueueInterval">0</attribute>
|
| <!--
| Max number of elements which trigger replication
| -->
| <attribute name="ReplQueueMaxElements">0</attribute>
|
| <!-- Name of cluster. Needs to be the same for all clusters, in order
| to find each other
| -->
| <attribute name="ClusterName">ArchTreeCache-Cluster</attribute>
|
| <!-- JGroups protocol stack properties. Can also be a URL,
| e.g. file:/home/bela/default.xml
| <attribute name="ClusterProperties"></attribute>
| -->
|
| <attribute name="ClusterConfig">
| <config>
| <!-- UDP: if you have a multihomed machine,
| set the bind_addr attribute to the appropriate NIC IP address, e.g bind_addr="192.168.0.2"
| -->
| <!-- UDP: On Windows machines, because of the media sense feature
| being broken with multicast (even after disabling media sense)
| set the loopback attribute to true -->
| <UDP mcast_addr="228.1.3.4" mcast_port="48866"
| ip_ttl="64" ip_mcast="true"
| mcast_send_buf_size="150000" mcast_recv_buf_size="80000"
| ucast_send_buf_size="150000" ucast_recv_buf_size="80000"
| loopback="true"/>
| <PING timeout="20000" num_initial_members="3"
| up_thread="false" down_thread="false"/>
| <MERGE2 min_interval="10000" max_interval="20000"/>
| <!-- <FD shun="true" up_thread="true" down_thread="true" />-->
| <FD_SOCK/>
| <VERIFY_SUSPECT timeout="1500"
| up_thread="false" down_thread="false"/>
| <pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800"
| max_xmit_size="8192" up_thread="false" down_thread="false"/>
| <UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10"
| down_thread="false"/>
| <pbcast.STABLE desired_avg_gossip="20000"
| up_thread="false" down_thread="false"/>
| <FRAG frag_size="8192"
| down_thread="false" up_thread="false"/>
| <pbcast.GMS join_timeout="5000" join_retry_timeout="2000"
| shun="true" print_local_addr="true"/>
| <pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/>
| </config>
| </attribute>
|
|
| <!--
| Whether or not to fetch state on joining a cluster
| NOTE this used to be called FetchStateOnStartup and has been renamed to be more descriptive.
| -->
| <attribute name="FetchInMemoryState">true</attribute>
|
| <!--
| The max amount of time (in milliseconds) we wait until the
| initial state (ie. the contents of the cache) are retrieved from
| existing members in a clustered environment
| -->
| <attribute name="InitialStateRetrievalTimeout">500000</attribute>
|
| <!--
| Number of milliseconds to wait until all responses for a
| synchronous call have been received.
| -->
| <attribute name="SyncReplTimeout">200000</attribute>
|
| <!-- Max number of milliseconds to wait for a lock acquisition -->
| <attribute name="LockAcquisitionTimeout">15000</attribute>
|
|
|
| <!-- Name of the eviction policy class. -->
| <attribute name="EvictionPolicyClass"></attribute>
|
| <!--
| Indicate whether to use marshalling or not. Set this to true if you are running under a scoped
| class loader, e.g., inside an application server. Default is "false".
| -->
|
| <attribute name="CacheLoaderConfiguration">
| <config>
| <passivation>false</passivation>
| <preload>/</preload>
| <shared>true</shared>
| <cacheloader>
| <class>org.jboss.cache.loader.JDBCCacheLoader</class>
| <properties>
| cache.jdbc.table.name=jbosscache
| cache.jdbc.table.create=true
| cache.jdbc.table.drop=false
| cache.jdbc.table.primarykey=jbosscache_pk
| cache.jdbc.fqn.column=fqn
| cache.jdbc.fqn.type=varchar(255)
| cache.jdbc.node.column=node
| cache.jdbc.node.type=blob
| cache.jdbc.parent.column=parent
| cache.jdbc.driver=oracle.jdbc.driver.OracleDriver
| cache.jdbc.url=jdbc:oracle:thin:@132.186.106.26:1541:ACRMDEV
| cache.jdbc.user=FASTDEV
| cache.jdbc.password=fastdev123$
| </properties>
| <async>false</async>
| <fetchPersistentState>true</fetchPersistentState>
| <ignoreModifications>false</ignoreModifications>
| </cacheloader>
| </config>
| </attribute>
| </mbean>
|
|
|
|
| <!-- Uncomment to get a graphical view of the TreeCache MBean above -->
| <!-- <mbean code="org.jboss.cache.TreeCacheView" name="jboss.cache:service=TreeCacheView">-->
| <!-- <depends>jboss.cache:service=TreeCache</depends>-->
| <!-- <attribute name="CacheService">jboss.cache:service=TreeCache</attribute>-->
| <!-- </mbean>-->
|
|
| </server>
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994389#3994389
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994389
19 years, 7 months