November 2008 - jboss-user - Jboss List Archives

[JBoss Messaging] - Re: Comparison to ActiveMQ

by timfox

"ataylor" wrote : | anonymous wrote : - Composite destinations. See http://activemq.apache.org/composite-destinations.html. A comma-separated list of destination names are treated like a single destination. | | no we don't support this at present. | . Can't you get the same effect by create multiple queues bound on the same address? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186801#4186801 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186801

17 years, 5 months

1
0
0 / 0

[JBoss Messaging] - Re: Comparison to ActiveMQ

by ataylor

anonymous wrote : - Virtual destinations. See http://activemq.apache.org/virtual-destinations.html. Messages sent to single destination are copied, filtered, and routed to multiple destinations. we don't virtual destinations but we do support wildcard routing in JBM 2.0. i.e. if you send a message to topic.* the message will get routed to topic.A, topic.B etc. anonymous wrote : - Composite destinations. See http://activemq.apache.org/composite-destinations.html. A comma-separated list of destination names are treated like a single destination. no we don't support this at present. anonymous wrote : - Destinations created on demand. See http://activemq.apache.org/how-do-i-create-new-destinations.html. Similar to temporary queues, we have permanent queues that are created on the fly for communication with a remote process. both JBM 1.4 and JBM 2 have a management API for creating destinations on the fly. If theres anything specific you need feel free to raise a JIRA, we can#t promise to add functionality but if its a value add on it may get done. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186800#4186800 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186800

17 years, 5 months

1
0
0 / 0

[EJB/JBoss] - CallByValue attribute

by rafaelcba

When make sense change the CallByValue attribute of server/default/deploy/ear-deployer.xml and Naming service in server/default/conf/jboss-service.xml? [1] has a description but i try apply this behavior on my JBoss and don't work fine. My test scenario is described at [2]. [1] https://www.jboss.org/community/docs/DOC-9288 [2] http://www.jboss.com/index.html?module=bb&op=viewtopic&t=144724 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186789#4186789 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186789

17 years, 5 months

1
0
0 / 0

[JBoss Cache: Core Edition] - Re: Buddy migration and removal

by genman

It looks like the eviction issue was fixed, but what's the solution to this problem if you use timed removal? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186787#4186787 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186787

17 years, 5 months

1
0
0 / 0

[JBoss Cache: Core Edition] - Buddy migration and removal

by genman

I was trying to get timed removal to work with buddy replication: JBCACHE-1435 So instead of using an eviction policy, I wrote my own timer to remove nodes from the cache. It works fine except when the data gets migrated from one cache to the other. In which case, the data copied to cache2 has no timer active to force removal. Essentially we have: 1. cache1.put(X, Y) 2. cache2.get(X) // returns Y, thanks to migration 3. cache1.remove(X) (from timer) 4. cache1.get(X) // returns Y Here's what I got: | 4328 INFO [main] - ___ service ___ | JBossCacheService#1 state=STARTED cache=/ null | /min null | /500500 null | /5005001042 {V={MDN=5005000958 MIN=5005001042 IP=127.0.0.42 CID= null}} | /_BUDDY_BACKUP_ null | /192.168.0.9_1832 null | /mdn null | /500500 null | /5005000958 {V=5005001042} | channelFactory=org.jgroups.JChannelFactory@18ed77a | 4328 INFO [main] - ___ service2 ___ | JBossCacheService#3 state=STARTED cache=/ null | /_BUDDY_BACKUP_ null | /192.168.0.9_1830 null | /min null | /500500 null | /5005001042 {V={MDN=5005000958 MIN=5005001042 IP=127.0.0.42 CID= null}} | /mdn null | /500500 null | /5005000958 {V=5005001042} | channelFactory=org.jgroups.JChannelFactory@15fc672 | 4547 INFO [main] - ___ wait for remove ___ | 5094 DEBUG [pool-1-thread-1] JBossCacheService - remove 5005001042 | 7547 INFO [main] - ___ service ___ | JBossCacheService#1 state=STARTED cache=/ null | /min null | /500500 null | /_BUDDY_BACKUP_ null | /192.168.0.9_1832 null | /min null | /500500 null | /5005001042 {V={MDN=5005000958 MIN=5005001042 IP=127.0.0.42 CID= null}} | /mdn null | /500500 null | /5005000958 {V=5005001042} | /mdn null | /500500 null | channelFactory=org.jgroups.JChannelFactory@18ed77a | 7547 INFO [main] - ___ service2 ___ | 7547 INFO [main] - | JBossCacheService#3 state=STARTED cache=/ null | /min null | /500500 null | /5005001042 {V={MDN=5005000958 MIN=5005001042 IP=127.0.0.42 CID= null}} | /_BUDDY_BACKUP_ null | /192.168.0.9_1830 null | /min null | /500500 null | /mdn null | /500500 null | /mdn null | /500500 null | /5005000958 {V=5005001042} | channelFactory=org.jgroups.JChannelFactory@15fc672 | Suggestions? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186786#4186786 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186786

17 years, 5 months

1
0
0 / 0

[Microcontainer] - Towards remoting-jboss-beans.xml

by ron.sigal＠jboss.com

I'm working on moving the Remoting related stuff in AS from deploy/remoting-service.xml to deploy/remoting-jboss-beans.xml, and I have a few questions to make sure I'm not doing something "anti-idiomatic". A skeletal version of remoting-jboss-beans.xml is appended below. 1. Are there any hidden gotcha's I'm missing? 2. Are there any conventions, e.g. naming conventions, I should be aware of? 3. Am I correct in understanding that setting "registerDirectly=false" in org.jboss.aop.microcontainer.aspects.jmx.JMX supports hot deployment? 4. JBAS-3926 is "Move remoting transports out of conf/jboss-service.xml to a remoting-beans.xml", but I see that all the *-beans.xml files in AS 5 are named *-jboss-beans.xml. Is the latter form just a convention for *-beans.xml files that come with the AS? Thanks. ================================================================================ | <deployment xmlns="urn:jboss:bean-deployer:2.0"> | | <bean name="UnifiedInvoker" class="org.jboss.invocation.unified.server.UnifiedInvoker"> | <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss:service=invoker,type=unified",exposedInterface=org.jboss.invocation.unified.server.UnifiedInvokerMBean.class,registerDirectly=true)</annotation> | <property name="connector"><inject bean="UnifiedInvokerConnector"/></property> | <depends>TransactionManager</depends> | </bean> | | <bean name="UnifiedInvokerConnector" class="org.jboss.remoting.transport.Connector"> | <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss.remoting:service=Connector,transport=socket",exposedInterface=org.jboss.remoting.transport.ConnectorMBean.class,registerDirectly=true)</annotation> | <property name="serverConfiguration"><inject bean="UnifiedInvokerConfiguration"/></property> | </bean> | | |  | <bean name="UnifiedInvokerConfiguration" class="org.jboss.remoting.ServerConfiguration"> | <constructor> | <parameter>socket</parameter> | </constructor> | |  | <property name="invokerLocatorParameters"> | <map keyClass="java.lang.String" valueClass="java.lang.String"> | <entry><key>serverBindAddress</key> <value>${jboss.bind.address}</value></entry> | <entry> | <key>serverBindPort</key> | <value> | <value-factory bean="ServiceBindingManager" method="getStringBinding"> | <parameter>jboss.remoting:service=Connector,transport=socket</parameter> | <parameter>${port}</parameter> | </value-factory> | </value> | </entry> | <entry><key>dataType</key> <value>invocation</value></entry> | <entry><key>marshaller</key> <value>org.jboss.invocation.unified.marshall.InvocationMarshaller</value></entry> | <entry><key>unmarshaller</key> <value>org.jboss.invocation.unified.marshall.InvocationUnMarshaller</value></entry> | </map> | </property> | |  | <property name="serverParameters"> | <map keyClass="java.lang.String" valueClass="java.lang.String"> |  | </map> | </property> | | <property name="invocationHandlers"> | <map keyClass="java.lang.String" valueClass="java.lang.String"> |  | <entry><key>JSR88</key> <value>org.jboss.deployment.remoting.DeployHandler</value></entry> | </map> | </property> | </bean> | | </deployment> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186782#4186782 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186782

17 years, 5 months

1
0
0 / 0

[JBoss Portal] - Re: JBOSS-Alfresco Integration

by rammyramkumar

Can you please tell me the steps for integrating the alfresco with jboss portal server.? This will be of great help. Is there any documents so that you share with me. thanks in advance View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186779#4186779 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186779

17 years, 5 months

1
0
0 / 0

[Beginners Corner] - Re: TravelAgentBean not bound?

by denisputnam

Hi Jaikiran, Thank you for getting back to me. I am still having trouble connecting the dots. Below it the output of the JMX console. Given this information, what pieces to I need to apply to what files or code to get my bean to be bound? I see the "persistence.units:jar" entry and that is what is in my persistence.xml file, but the getInitialContext() method is failing. Do I need to change one of the p.put() calls? Global JNDI Namespace +- TopicConnectionFactory (class: org.jboss.naming.LinkRefPair) +- jmx (class: org.jnp.interfaces.NamingContext) | +- invoker (class: org.jnp.interfaces.NamingContext) | | +- RMIAdaptor (proxy: $Proxy47 implements interface org.jboss.jmx.adaptor.rmi.RMIAdaptor,interface org.jboss.jmx.adaptor.rmi.RMIAdaptorExt) | +- rmi (class: org.jnp.interfaces.NamingContext) | | +- RMIAdaptor[link -> jmx/invoker/RMIAdaptor] (class: javax.naming.LinkRef) +- HTTPXAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory) +- ConnectionFactory (class: org.jboss.mq.SpyConnectionFactory) +- UserTransactionSessionFactory (proxy: $Proxy15 implements interface org.jboss.tm.usertx.interfaces.UserTransactionSessionFactory) +- HTTPConnectionFactory (class: org.jboss.mq.SpyConnectionFactory) +- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory) +- TransactionSynchronizationRegistry (class: com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionSynchronizationRegistryImple) +- UserTransaction (class: org.jboss.tm.usertx.client.ClientUserTransaction) +- UILXAConnectionFactory[link -> XAConnectionFactory] (class: javax.naming.LinkRef) +- TravelAgent (class: org.jnp.interfaces.NamingContext) | +- remote (proxy: $Proxy69 implements interface com.titan.travelagent.TravelAgentRemote,interface org.jboss.ejb3.JBossProxy) +- UIL2XAConnectionFactory[link -> XAConnectionFactory] (class: javax.naming.LinkRef) +- queue (class: org.jnp.interfaces.NamingContext) | +- A (class: org.jboss.mq.SpyQueue) | +- testQueue (class: org.jboss.mq.SpyQueue) | +- ex (class: org.jboss.mq.SpyQueue) | +- DLQ (class: org.jboss.mq.SpyQueue) | +- D (class: org.jboss.mq.SpyQueue) | +- C (class: org.jboss.mq.SpyQueue) | +- B (class: org.jboss.mq.SpyQueue) +- topic (class: org.jnp.interfaces.NamingContext) | +- testDurableTopic (class: org.jboss.mq.SpyTopic) | +- testTopic (class: org.jboss.mq.SpyTopic) | +- securedTopic (class: org.jboss.mq.SpyTopic) +- console (class: org.jnp.interfaces.NamingContext) | +- PluginManager (proxy: $Proxy48 implements interface org.jboss.console.manager.PluginManagerMBean) +- UIL2ConnectionFactory[link -> ConnectionFactory] (class: javax.naming.LinkRef) +- HiLoKeyGeneratorFactory (class: org.jboss.ejb.plugins.keygenerator.hilo.HiLoKeyGeneratorFactory) +- UILConnectionFactory[link -> ConnectionFactory] (class: javax.naming.LinkRef) +- persistence.units:jar=TitanCruises.jar,unitName=TitanCruisesPU (class: org.hibernate.impl.SessionFactoryImpl) +- QueueConnectionFactory (class: org.jboss.naming.LinkRefPair) +- UUIDKeyGeneratorFactory (class: org.jboss.ejb.plugins.keygenerator.uuid.UUIDKeyGeneratorFactory) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186777#4186777 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186777

17 years, 5 months

1
0
0 / 0

[EJB 3.0] - Re: EJB 3.1 Embeddable

by wolfc

So far can't find anything different than my own setup except junit, which I have as: <dependency> | <groupId>junit</groupId> | <artifactId>junit</artifactId> | <version>[4,)</version> | <scope>test</scope> | </dependency> What JDK are you using? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186776#4186776 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186776

17 years, 5 months

1
0
0 / 0

[JBoss Messaging] - Re: Comparison to ActiveMQ

by mkelley

There are a few ActiveMQ features my company is using that I'm wondering about support for in JBM. - Virtual destinations. See http://activemq.apache.org/virtual-destinations.html. Messages sent to single destination are copied, filtered, and routed to multiple destinations. - Composite destinations. See http://activemq.apache.org/composite-destinations.html. A comma-separated list of destination names are treated like a single destination. - Destinations created on demand. See http://activemq.apache.org/how-do-i-create-new-destinations.html. Similar to temporary queues, we have permanent queues that are created on the fly for communication with a remote process. When the process dies, queues are deleted. Unlike temporary queues, messages outlive a JMS session. Are these among the 'host of other features'? If no, do you have any code/configuration snippets or hints for approximating them (esp. virtual/composite destinations via bridges)? FWIW the existence of these features in ActiveMQ made it an attractive choice and helped us go pretty far in application development by enabling us to change message routing rules extremely quickly. Now that we know much more about what we want from a messaging system we'd happily trade some features for better scalability, stability, and documentation/support. Knowing more details beyond "a host of other features" would be great start. Mike View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186768#4186768 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186768

17 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-user November 2008