[JBoss Messaging] - Does JBoss Messaging violate the JEE 5 Specification?
by Peer Bech Hansen
Peer Bech Hansen [http://community.jboss.org/people/bech] created the discussion
"Does JBoss Messaging violate the JEE 5 Specification?"
To view the discussion, visit: http://community.jboss.org/message/562832#562832
--------------------------------------------------------------
Hi JBoss people
For the project I’m currently working on, I’m trying to get JBoss Messaging to bridge messages from a JBoss queue to a IBM WebSphere MQ queue.
I’m using IBM’s “WebSphere MQ resource adapter” and JCA administered objects to bind remote WMQ queues to my local JNDI.
The guides I have followed, to configure the resource adaptor and to define my queues is found here:
http://www.ibm.com/developerworks/websphere/library/techarticles/0710_rit... http://www.ibm.com/developerworks/websphere/library/techarticles/0710_rit...
http://community.jboss.org/docs/DOC-12535 http://community.jboss.org/wiki/UsingWebSphereMQSeriesWithJBossASPart4
To Bridge the messages im using the *org.jboss.jms.server.bridge.BridgeService* MBean as shown below:
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?>
<server>
<mbean code="org.jboss.jms.server.bridge.BridgeService"
name="jboss.messaging:service=Bridge,name=WMQBridge"
xmbean-dd="xmdesc/Bridge-xmbean.xml">
<!-- The JMS provider loader that is used to lookup the source destination -->
<depends optional-attribute-name="SourceProviderLoader">jboss.messaging:service=JMSProviderLoader,name=JMSProvider</depends>
<!-- The JMS provider loader that is used to lookup the target destination -->
<depends optional-attribute-name="TargetProviderLoader">jboss.messaging:service=JMSProviderLoader,name=JMSWMQProvider</depends>
<!-- The JNDI lookup for the source destination -->
<attribute name="SourceDestinationLookup">queue/messagedistribution_contact_out</attribute>
<!-- The JNDI lookup for the target destination -->
<attribute name="TargetDestinationLookup">queue/WMQTest_out</attribute>
<!-- Optional: The Quality Of Service mode to use, one of:
QOS_AT_MOST_ONCE = 0;
QOS_DUPLICATES_OK = 1;
QOS_ONCE_AND_ONLY_ONCE = 2; -->
<attribute name="QualityOfServiceMode">1</attribute>
<attribute name="MaxBatchSize">1</attribute>
<attribute name="MaxBatchTime">-1</attribute>
<attribute name="FailureRetryInterval">5000</attribute>
<attribute name="MaxRetries">-1</attribute>
</mbean>
</server>der loader that is used to lookup the target destination -->
<depends optional-attribute-name="TargetProviderLoader">jboss.messaging:service=JMSProviderLoader,name=JMSWMQProvider</depends>
<?xml version="1.0" encoding="UTF-8"?>
<server>
<mbean code="org.jboss.jms.server.bridge.BridgeService"
name="jboss.messaging:service=Bridge,name=WMQBridge"
xmbean-dd="xmdesc/Bridge-xmbean.xml">
<depends optional-attribute-name="SourceProviderLoader">jboss.messaging:service=JMSProviderLoader,name=JMSProvider</depends>
<depends optional-attribute-name="TargetProviderLoader">jboss.messaging:service=JMSProviderLoader,name=JMSWMQProvider</depends>
<attribute name="SourceDestinationLookup">queue/messagedistribution_contact_out</attribute>
<attribute name="TargetDestinationLookup">queue/WMQTest_out</attribute>
<attribute name="QualityOfServiceMode">1</attribute>
<attribute name="MaxBatchSize">1</attribute>
<attribute name="MaxBatchTime">-1</attribute>
<attribute name="FailureRetryInterval">5000</attribute>
<attribute name="MaxRetries">-1</attribute>
</mbean>
</server>
When the bridging is performed i get the following error:
10:15:06,820 WARN [Bridge] jboss.messaging:name=WMQBridge,service=Bridge Failed to set up connections
com.ibm.msg.client.jms.DetailedIllegalStateException: MQJCA1031: The method can only be called in the application client container. The application was not running in the application client container when this method was called. Ensure that the application runs in the application client container, or modify the application to avoid this method call.
at com.ibm.mq.connector.services.JCAExceptionBuilder.buildException(JCAExceptionBuilder.java:149)
at com.ibm.mq.connector.services.JCAExceptionBuilder.buildException(JCAExceptionBuilder.java:86)
at com.ibm.mq.connector.outbound.ConnectionWrapper.setExceptionListener(ConnectionWrapper.java:183)
at org.jboss.jms.server.bridge.Bridge.setupJMSObjects(Bridge.java:1017)
at org.jboss.jms.server.bridge.Bridge.setupJMSObjectsWithRetry(Bridge.java:1223)
at org.jboss.jms.server.bridge.Bridge.access$1600(Bridge.java:68)
at org.jboss.jms.server.bridge.Bridge$FailureHandler.run(Bridge.java:1569)
at java.lang.Thread.run(Thread.java:619)
The “WebSphere MQ resource adapter” fails; telling me that an illegal method has been called.
On line 1017 and 1025 of the class *o* *http://anonsvn.jboss.org/repos/messaging/tags/JBossMessaging_1_4_3_GA/src/main/org/jboss/jms/server/bridge/Bridge.java rg.jboss.jms.server.bridge.Bridge*, the method setExceptionListener() is called on the on the JMS ConnectionFactory.
On page 133 - 134 of the Java™ Platform, Enterprise Edition (Java EE) Specification, v5 ( http://jcp.org/aboutJava/communityprocess/final/jsr244/index.html http://jcp.org/aboutJava/communityprocess/final/jsr244/index.html) it is clearly stated that call to this method (and other methods), from web or EJB containers is prohibited.
The “WebSphere MQ resource adapter” has implemented this restriction and throws an Exception if the method is call on their ConnectionFactory implementation.
So the questions is:
Isn’t JBoss Messaging violating the JEE5 specification, and how do I create a workaround for the problem?
I have had the exact same error when using the JBoss ESB http://community.jboss.org/thread/156545 http://community.jboss.org/thread/156545
Looking forward to hear your opinions.
Kind regards
Peer Bech Hansen
Logica Denmark
Environment used:
Microsoft Windows XP SP3
JBoss AS 5.1.0 GA
JBoss Messaging 1.4.3 GA
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/562832#562832]
Start a new discussion in JBoss Messaging at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months
[JBoss Cache] - Hibernate JbossCache integration
by Marilen Corciovei
Marilen Corciovei [http://community.jboss.org/people/marilenc] created the document:
" Hibernate JbossCache integration"
To view the document, visit: http://community.jboss.org/docs/DOC-15863
--------------------------------------------------------------
h2. Introduction
JbossCache is a wonderfully complex piece of software. Trying to use it with Hibernate might seem an easy task at first but in reality it can also prove wonderfully complicated.
First question is: *why would you consider using it in the first place?* Compared to ehcache for instance there are a few theoretical advantages: clustering (scalability), configurability and jmx monitoring.
Next question which is not quite obvious is *which version to use?* The answer is a bit complicated since there are a lot of changes in versions which vary from architectural to configuration points. This document is concerned with integration of hibernate 3.3.1 with jboss cache 3.1.0 (Cascabel) as they are shipped in jboss 5.1.0.GA.
h2. Choices
I think most people consider that cache integration should be a matter of switching a config option. I cannot argue with this logic and for them the most appropriate configuration (as described in most documents) is as following (if using a hibernate-service.xml .har configuration):
<property name="cacheRegionFactoryClass">org.hibernate.cache.jbc2.MultiplexedJBossCacheRegionFactory</property>
along with activation of second level and query cache:
<property name="queryCacheEnabled">true</property>
<property name="secondLevelCacheEnabled">true</property>
This will probably work from start but also from start you will loose one of the advantages: jmx monitoring
Let’s go back to the cacheRegionFactoryClass and it’s hibernate.cache.region.factory_class equivalent. The hibernate documentation states there are 4 options for this property. Here is my understanding of them:
* SharedJBossCacheRegionFactory will create a Cache (as in org.jboss.cache.Cache) based on a treecache.xml configuration and use it for it’s caching purposes. You can provide your configuration (in fact you must provide it) and everything seems perfect except that you cannot have jmx instrumentation. I have found no way to obtain the Cache from a SessionFactory and pass it to a CacheJmxWrapper for instrumentation.
* JndiSharedJBossCacheRegionFactory seems the perfect solution for the above problem as you can create your cache and jmx via a -jboss-beans.xml configuration and then pass it to hibernate. *Can you? No.* As there is no way to bind the cache to JNDI from the -jboss-beans.xml configuration. No problem I might say. I will bind it myself. However the Cache object is not serializable and you will end with an exception. *No again.*
javax.naming.CommunicationException [Root exception is java.io.NotSerializableException:
* MultiplexedJBossCacheRegionFactory is the most recommended solution. What it does is to create multiple Caches managed by a CacheManager. Remember: you can still have multiple cache regions with different eviction policies even in a single cache so the reason for multiple caches seems an extreme case for me such as: having different passivations or transport options. Note that this CacheManager is created by hibernate and is not exposed to jmx. If you want to have a clustering environment with not much fuss you will end up with jboss default cache manager which also creates several Cache’s of it’s own.
* JndiMultiplexedJBossCacheRegionFactory seems then a wises choice as it will let you connect/use the existing CacheManager created by jboss (I will discuss configuration issues later).
h2. Configuration
Here are some example configurations for the cases described above.
h3. treecache.xml for the SharedJbossCacheRegionFactory
You have to put it somewhere in the classpath root, for instance in your .har file. The following example is local, does not uses jgroups and has a special region for timestamps.
<?xml version="1.0" encoding="UTF-8"?>
<jbosscache xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.1">
<!--
isolation levels supported: READ_COMMITTED and REPEATABLE_READ
nodeLockingSchemes: mvcc, pessimistic (deprecated), optimistic (deprecated)
-->
<locking isolationLevel="REPEATABLE_READ" lockParentForChildInsertRemove="false" lockAcquisitionTimeout="20000" nodeLockingScheme="mvcc" writeSkewCheck="false" useLockStriping="true" concurrencyLevel="500" />
<!-- Used to register a transaction manager and participate in ongoing transactions. -->
<transaction transactionManagerLookupClass="org.jboss.cache.transaction.GenericTransactionManagerLookup" syncRollbackPhase="false" syncCommitPhase="false" />
<!-- Used to register JMX statistics in any available MBean server -->
<jmxStatistics enabled="true" />
<!-- If region based marshalling is used, defines whether new regions are inactive on startup. -->
<startup regionsInactiveOnStartup="true" />
<!--
Used to register JVM shutdown hooks.
hookBehavior: DEFAULT, REGISTER, DONT_REGISTER
-->
<shutdown hookBehavior="DEFAULT" />
<!-- Used to define async listener notification thread pool size -->
<listeners asyncPoolSize="1" asyncQueueSize="100000" />
<!-- Used to enable invocation batching and allow the use of Cache.startBatch()/endBatch() methods. -->
<invocationBatching enabled="false" />
<!-- serialization related configuration, used for replication and cache loading -->
<serialization objectInputStreamPoolSize="12" objectOutputStreamPoolSize="14" version="3.0.0" marshallerClass="org.jboss.cache.marshall.VersionAwareMarshaller" useLazyDeserialization="false" useRegionBasedMarshalling="false" />
<!--
Eviction configuration. WakeupInterval defines how often the eviction thread runs, in milliseconds. 0 means
the eviction thread will never run.
-->
<eviction wakeUpInterval="500">
<default algorithmClass="org.jboss.cache.eviction.LRUAlgorithm" eventQueueSize="200000">
<property name="maxNodes" value="5000" />
<property name="timeToLive" value="40000" />
</default>
<region name="/TS" algorithmClass="org.jboss.cache.eviction.NullEvictionAlgorithm">
</region>
</eviction>
</jbosscache>
h3. -jboss-beans.xml deployement
Of a cache which cannot be bound to jndi and passed to SharedJbossCacheRegionFactory, also local:
<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0">
<!-- First we create a Configuration object for the cache -->
<bean name="DiapasonCacheConfig"
class="org.jboss.cache.config.Configuration">
<property name="runtimeConfig">
<bean class="org.jboss.cache.config.RuntimeConfig">
<property name="transactionManager">
<inject bean="jboss:service=TransactionManager"
property="TransactionManager"/>
</property>
<!--
<property name="muxChannelFactory"><inject bean="JChannelFactory"/></property>
-->
</bean>
</property>
<property name="multiplexerStack">udp</property>
<property name="clusterName">Diapason-EntityCache</property>
<property name="isolationLevel">REPEATABLE_READ</property>
<property name="cacheMode">LOCAL</property>
<property name="stateRetrievalTimeout">15000</property>
<property name="syncReplTimeout">20000</property>
<property name="lockAcquisitionTimeout">15000</property>
<property name="exposeManagementStatistics">true</property>
</bean>
<!-- Factory to build the Cache. -->
<bean name="DefaultCacheFactory" class="org.jboss.cache.DefaultCacheFactory">
<constructor factoryClass="org.jboss.cache.DefaultCacheFactory"
factoryMethod="getInstance" />
</bean>
<!-- The cache itself -->
<bean name="DiapasonCache" class="org.jboss.cache.Cache">
<constructor factoryMethod="createCache">
<factory bean="DefaultCacheFactory"/>
<parameter class="org.jboss.cache.config.Configuration"><inject bean="DiapasonCacheConfig"/></parameter>
<parameter class="boolean">false</parameter>
</constructor>
</bean>
<!-- JMX Management -->
<bean name="DiapasonCacheJmxWrapper" class="org.jboss.cache.jmx.CacheJmxWrapper">
<annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss.cache:service=DiapasonTreeCache", exposedInterface=org.jboss.cache.jmx.CacheJmxWrapperMBean.class, registerDirectly=true)</annotation>
<constructor>
<parameter><inject bean="DiapasonCache"/></parameter>
</constructor>
</bean>
<!-- a bean I tried to use to register the cache to jndi, ignore
<bean name="CacheX" class="ro.len.CacheX">
<property name="cache"><inject bean="DiapasonCache"/></property>
</bean>
-->
</deployment>
h3. MultiplexedJBossCacheRegionFactory
No config is needed in this case as hibernate will use 2 files jbc2-configs.xml and jgroups-stacks.xml both found in hibernate-jbosscache2.jar. Of course if you want to take advantage of the configurability of Jboss Cache you will have to take these files and adapt them to your need.
h3. JndiMultiplexedJBossCacheRegionFactory
This option will give you most of the things you want and can be configured as following:
<property name="cacheRegionFactoryClass">org.hibernate.cache.jbc2.JndiMultiplexedJBossCacheRegionFactory</property>
<property name="deployedCacheManagerJndiName">java:/CacheManager</property>
This will make use of the existing CacheManager which is registered to JNDI. However if using the “default” configuration for jboss this is not the case. You will need to copy jboss-cache-manager.sar and jgroups-channelfactory.sar from the all/deploy/cluster to default/deploy/cluster along with an extra jar for pojo cache (jbosscache-pojo.jar, still don’t know the use of that).
In order to configure your cache you will need to edit the jboss-cache-manager-jboss-beans.xml file notably the optimistic-entity entry which hibernate will use.
h2. Conclusions
You might ask: *why use jboss cache after all?* it does seem a bit too complicated. I think you can find at least the following benefits:
* Configurability related to *cache regions*. This seems the most interesting benefit from my point of view, can be done in any of the previous configs and does not require a CacheManager or clustering.This is where you can configure various eviction policies. You might want for instance some data to be evicted much slower than other or some data never to evicted. This means of course some mapping (.hbm) changes in case of entities consisting in adding the region attribute to the cache part of the mapping and some code change in case of queries.
* *JMX* is of great use. First, it allows to see that the eviction configured really works and second it shows lock problems which unfortunately where a problem in previous jboss cache versions (as in jboss 4.2.2 GA). Let’s hope it will no longer be the case.
* Of least importance for most people it will be *clustering*. But even if initially it might be of reduced importance it’s good to know if you ever need it support is already there and only some configuration is required
h2. Links
Finally here are some links which I read a lot of times in the process of testing these configurations and are the base for this article which intended to be much more shorter:
* http://docs.jboss.org/jbosscache/3.1.0.CR1/userguide_en/html_single/index... documentation for this cache version
* http://docs.jboss.org/jbossclustering/hibernate-caching/3.3/en-US/html_si... hibernate, jboss cache integration
* http://community.jboss.org/message/270922#270922 post discussing the jmx/jndi exposure (found it later but describes similar observations)
* http://www.len.ro/2010/02/jboss-migration-4-2-2-ga-to-5-1-0-ga/ migration from jboss 4 to 5 document (why I arrived to this problem)
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15863]
Create a new document in JBoss Cache at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years, 3 months
[Beginner's Corner] - JBOSS 5.1 Server -> org.hibernate.ejb.HibernatePersistence cannot be cast to javax.persistence.spi.PersistenceProvider
by Amar Kintu
Amar Kintu [http://community.jboss.org/people/amar4kintu] created the discussion
"JBOSS 5.1 Server -> org.hibernate.ejb.HibernatePersistence cannot be cast to javax.persistence.spi.PersistenceProvider"
To view the discussion, visit: http://community.jboss.org/message/562814#562814
--------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
" http://java.sun.com/dtd/web-app_2_3.dtd http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
<!-- Servlets -->
<servlet>
<servlet-name>springGwtRemoteServiceServlet</servlet-name>
<servlet-class>org.spring4gwt.server.SpringGwtRemoteServiceServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>springGwtRemoteServiceServlet</servlet-name>
<url-pattern>/gwtspring/springGwtServices/*</url-pattern>
</servlet-mapping>
<!-- Default page to serve -->
<welcome-file-list>
<welcome-file>GWTSpring.html</welcome-file>
</welcome-file-list>
</web-app>
Hello friends,
I am developing an application using SPRING 3.0.4, JPA 2, Hibernate 3.5.5.
I an trying an existing example given on link http://www.javacodegeeks.com/2010/05/jboss-42x-spring-3-jpa-hibernate.html http://www.javacodegeeks.com/2010/05/jboss-42x-spring-3-jpa-hibernate.html.
only difference is that I am using latest versions of libraries and JBOSS server.
Following is list of my /WEB-INF/lib directory files
antlr-2.7.6.jar
aopalliance.jar
c3p0-0.9.1.jar
commons-collections-3.1.jar
commons-logging-1.1.1.jar
dom4j-1.6.1.jar
gwt-dev.jar
gwt-user.jar
hibernate3.jar
hibernate-jpa-2.0-api-1.0.0.Final.jar
hsqldb.jar
javassist-3.9.0.GA.jar
jta-1.1.jar
log4j-1.2.16.jar
org.springframework.aop-3.0.4.RELEASE.jar
org.springframework.asm-3.0.4.RELEASE.jar
org.springframework.aspects-3.0.4.RELEASE.jar
org.springframework.beans-3.0.4.RELEASE.jar
org.springframework.context.support-3.0.4.RELEASE.jar
org.springframework.context-3.0.4.RELEASE.jar
org.springframework.core-3.0.4.RELEASE.jar
org.springframework.expression-3.0.4.RELEASE.jar
org.springframework.instrument.tomcat-3.0.4.RELEASE.jar
org.springframework.instrument-3.0.4.RELEASE.jar
org.springframework.jdbc-3.0.4.RELEASE.jar
org.springframework.jms-3.0.4.RELEASE.jar
org.springframework.orm-3.0.4.RELEASE.jar
org.springframework.oxm-3.0.4.RELEASE.jar
org.springframework.test-3.0.4.RELEASE.jar
org.springframework.transaction-3.0.4.RELEASE.jar
org.springframework.web.portlet-3.0.4.RELEASE.jar
org.springframework.web.servlet-3.0.4.RELEASE.jar
org.springframework.web.struts-3.0.4.RELEASE.jar
org.springframework.web-3.0.4.RELEASE.jar
slf4j-api-1.5.8.jar
slf4j-log4j12-1.6.1.jar
spring4gwt-0.0.1.jar
Following is my /WEB-INF/web.xml file
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
http://java.sun.com/dtd/web-app_2_3.dtd>
<web-app>
<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
<!-- Servlets -->
<servlet>
<servlet-name>springGwtRemoteServiceServlet</servlet-name>
<servlet-class>org.spring4gwt.server.SpringGwtRemoteServiceServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>springGwtRemoteServiceServlet</servlet-name>
<url-pattern>/gwtspring/springGwtServices/*</url-pattern>
</servlet-mapping>
<!-- Default page to serve -->
<welcome-file-list>
<welcome-file>GWTSpring.html</welcome-file>
</welcome-file-list>
</web-app>
Following is my /WEB-INF/applicationContext.xml file
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p"
xmlns:aop="http://www.springframework.org/schema/aop" xmlns:context="http://www.springframework.org/schema/context"
xmlns:jee="http://www.springframework.org/schema/jee" xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:task="http://www.springframework.org/schema/task"
xsi:schemaLocation="
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-3.0.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.0.xsd
http://www.springframework.org/schema/task http://www.springframework.org/schema/task/spring-task-3.0.xsd">
<context:component-scan base-package="com.javacodegeeks.gwtspring" />
<task:annotation-driven executor="myExecutor" scheduler="myScheduler" />
<task:executor id="myExecutor" pool-size="5" />
<task:scheduler id="myScheduler" pool-size="10" />
<tx:annotation-driven />
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalEntityManagerFactoryBean">
<property name="persistenceUnitName" value="MyPersistenceUnit" />
</bean>
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
</bean>
</beans>
Following is my /src/resources/META-INF/petsistence.xml file
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
version="2.0">
<persistence-unit name="MyPersistenceUnit" transaction-type="RESOURCE_LOCAL">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<non-jta-data-source>java:/gwtDS</non-jta-data-source>
<properties>
<property name="hibernate.hbm2ddl.auto" value="update" />
<property name="hibernate.show_sql" value="false" />
<property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect" />
<property name="hibernate.connection.driver_class" value="org.hsqldb.jdbcDriver" />
<property name="hibernate.connection.url" value="jdbc:hsqldb:mem:salvation" />
<property name="hibernate.connection.username" value="sa" />
<property name="hibernate.connection.password" value="" />
<property name="hibernate.c3p0.min_size" value="5" />
<property name="hibernate.c3p0.max_size" value="20" />
<property name="hibernate.c3p0.timeout" value="300" />
<property name="hibernate.c3p0.max_statements" value="50" />
<property name="hibernate.c3p0.idle_test_period" value="3000" />
</properties>
</persistence-unit>
</persistence>
Now when I am trying to complile it using JBOSS server it gives me following error
11:34:17,828 INFO [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221053)] Started in 19s:985ms
11:34:28,437 INFO [PersistenceUnitDeployment] Starting persistence unit persistence.unit:unitName=#MyPersistenceUnit
11:34:29,046 ERROR [AbstractKernelController] Error installing to Start: name=persistence.unit:unitName=#MyPersistenceUnit state=Create
java.lang.ClassCastException: org.hibernate.ejb.HibernatePersistence cannot be cast to javax.persistence.spi.PersistenceProvider
at org.jboss.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:300)
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:597)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:362)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:255)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Can anyone here help me to solve the problem.
Please let me know if you need anything else from me.
Thanks.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/562814#562814]
Start a new discussion in Beginner's Corner at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months
[JBoss Portal] - Re: https starting up on wrong port
by Adrian H
Adrian H [http://community.jboss.org/people/adrian.howchin] created the discussion
"Re: https starting up on wrong port"
To view the discussion, visit: http://community.jboss.org/message/562802#562802
--------------------------------------------------------------
Even though this is over 2 years old, I thought I'd reply anyway for the sake of sharing knowledge..
I'm using JBoss AS 5.1.0_GA. In the conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml file there is an XSL transformation at the bottom, which starts like this:
<xsl:template match = "Connector">
<Connector>
<xsl:for-each select="@*">
<xsl:choose>
... etc.
This XSL transform applies to the server.xml file under deploy/jbossweb.sar/server.xml. It modifies the ports you put in there (I have no idea how or why - anyone?).
The key line from this section is:
<xsl:variable name="portAJP" select="$port - 71"/>
Note that your chose value (24443) is 71 greater than the value chosen by JBoss (24364). Ie. 24443 - 71 = 24364. My assumption is that for some bizarre reason this transform is applying to your port number.
Can anyone explain the purpose and behaviour of the XSL transfrom to me?
Cheers,
Adrian
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/562802#562802]
Start a new discussion in JBoss Portal at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months
[JBoss Remoting] - SocketClientInvoker - NEW ClientSocketWrapper Errors
by vidhya Baskaran
vidhya Baskaran [http://community.jboss.org/people/vbs_jboss_accnt] created the discussion
"SocketClientInvoker - NEW ClientSocketWrapper Errors"
To view the discussion, visit: http://community.jboss.org/message/562780#562780
--------------------------------------------------------------
We have a messaging server running with the following versions and have a few clients that connect to this messaging server (with the same version of jar files....)
jboss messaging 1.4.6
jboss remoting 2.5.2
Once in a few days , We get this error on the server debug logs and the whole messaging server freezes and we need to restart the server to make it work again -
The odd thing being the IP address (X) on the thread name is different from the bisocket's one...(Is this OK ? ). Any inputs to fix this issue is appreciated..... What does this exception mean ???
DEBUG [org.jboss.remoting.transport.socket.MicroSocketClientInvoker,] (WorkerThread#194[*X*:46255]) SocketClientInvoker[6ffe4080, bisocket://*Y*:950817640] got exception: NEW ClientSocketWrapper[Socket[addr=/*Y*,port=1640,localport=14396].e4e0c40]
java.io.IOException: Connection reset
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:96)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at java.io.DataOutputStream.flush(DataOutputStream.java:106)
at org.jboss.jms.wireformat.ClientDelivery.write(ClientDelivery.java:93)
at org.jboss.jms.wireformat.JMSWireFormat.write(JMSWireFormat.java:237)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedWrite(MicroSocketClientInvoker.java:1325)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:861)
at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:461)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:167)
at org.jboss.remoting.Client.invoke(Client.java:1917)
at org.jboss.remoting.Client.invoke(Client.java:768)
at org.jboss.remoting.Client.invokeOneway(Client.java:817)
at org.jboss.remoting.callback.ServerInvokerCallbackHandler.handleCallback(ServerInvokerCallbackHandler.java:835)
at org.jboss.remoting.callback.ServerInvokerCallbackHandler.handleCallbackOneway(ServerInvokerCallbackHandler.java:708)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.performDelivery(ServerSessionEndpoint.java:1467)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.handleDelivery(ServerSessionEndpoint.java:1379)
at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.handle(ServerConsumerEndpoint.java:327)
at org.jboss.messaging.core.impl.RoundRobinDistributor.handle(RoundRobinDistributor.java:119)
at org.jboss.messaging.core.impl.MessagingQueue$DistributorWrapper.handle(MessagingQueue.java:583)
at org.jboss.messaging.core.impl.ClusterRoundRobinDistributor.handle(ClusterRoundRobinDistributor.java:79)
at org.jboss.messaging.core.impl.ChannelSupport.deliverInternal(ChannelSupport.java:665)
at org.jboss.messaging.core.impl.MessagingQueue.deliverInternal(MessagingQueue.java:506)
at org.jboss.messaging.core.impl.ChannelSupport.handle(ChannelSupport.java:246)
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.routeInternal(MessagingPostOffice.java:2345)
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.route(MessagingPostOffice.java:515)
at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:777)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:399)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:87)
at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeNext(SessionAdvised$send_7280680627620114891.java)
at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:157)
at sun.reflect.GeneratedMethodAccessor234.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeNext(SessionAdvised$send_7280680627620114891.java)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvised.java)
at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendRequest.java:95)
at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:157)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:897)
at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:768)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:721)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:575)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/562780#562780]
Start a new discussion in JBoss Remoting at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months
[JBoss Messaging] - Messages being delivered but not removed from jbm_msg and jbm_msg_ref
by Joe Mihalich
Joe Mihalich [http://community.jboss.org/people/jmihalich1] created the discussion
"Messages being delivered but not removed from jbm_msg and jbm_msg_ref"
To view the discussion, visit: http://community.jboss.org/message/562767#562767
--------------------------------------------------------------
Hi,
We're seeing a pretty significant bug in jboss messaging 1.4.2.GA on Jboss 4.2.3.GA. We're seeing this using both sql server 2005 and and mysql 5.1.
We put the JMS system under a load where sometimes hundreds, if not thousands of messages are published to a topic to be processed.
Occasionally we see a bug where the message is delivered to the MDB (verfied through our internal logging), but does not get removed from the jbm_msg or the jbm_msg_ref tables. The "State" column in the jbm_msg_ref table varies across the messages so it's not like they're getting stuck in some state. We are seeing this live in the field at customer's sites as well as in house.
The evil part about this is that the message will and not be redelivered during the course of the app server being up. however, if you restart the app server, the message is immediately redelivered to the MDB.
We have upgraded our system internally to 1.4.5GA of jboss messaging...but we have not had enough run time on it yet to see if a bug was fixed in this area or not. And, I don't see anything in the list of fixes that would indicate this problem was fixed.
Any ideas how this can happen?
Thanks,
Joe
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/562767#562767]
Start a new discussion in JBoss Messaging at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months
[JNDI and Naming] - Using JNDI in clouds like EC2, GoGrid, Rackspace, etc
by Kevin Duffey
andjarnic [http://community.jboss.org/people/andjarnic] created the discussion
"Using JNDI in clouds like EC2, GoGrid, Rackspace, etc"
To view the discussion, visit: http://community.jboss.org/message/562611#562611
--------------------------------------------------------------
Hi all,
I am looking into deploying a JEE6 solution, complete with front end API interface, JMS, and back end EJB servers and MySQL db. Naturally I want to be able to scall all four tiers. We're considering a cloud solution like EC2 or Rackspace. The problem we're running into everywhere is nobody supports multi-cast, so the easy street clustering and lookup of servers is completely blocked for us.
So my question is, has anoyone deployed a scalable JEE6 setup in one of these hosted locations and able to make scaling of different tiers relatively painless.. or for that matter, how did you scale at all?
The only way we can think of right now is to manually turn on instances ourselves, get the IP info, and add it to a database of servers/ips and somehow make use of that for each tier to identify new servers in the cluster to load balance to, or fail over to.
Thank you for any feedback on how to get around this issue and make scaling possible.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/562611#562611]
Start a new discussion in JNDI and Naming at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months