April 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBossCache] - Re: Rigid design of state transfer manager, factories, integ

by supi

Because it is not possible to keep external resources in sync with the cache. If a cache contains node A before the transfer, and node A is recreated by the integrator (e.g. network interrupt), no create notification should take place. Likewise, when data is modified (application hook necessary to decide this), node modified events should be fired. Finally, it must be possible to detect removed nodes. Also, even though delete-all and create-all may work for the cache (although arguably a poor solution), the same cannot be expected from listeners/business semantics. Basil View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038061#4038061 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038061

18 years, 11 months

1
0
0 / 0

[Design of JBossCache] - JBCACHE-1025: JBossCache mbean registration fails on WebSphe

by JerryGauth

Here's more information on this issue - At least two JBossCache customers have reported that JBC fails when the cache is started on WebSphere 6.1 due to an exception indicating that an attempt has been made to register an already registered mbean. This occurs on initial startup so it's not necessary to stop and restart the cache to trigger the problem. I've googled and found that similar WebSphere mbean registration problems have also been reported in forums for Spring and ActiveMQ. According to the ActiveMQ posting, the problem occurs because WebSphere modifies the registration name during the registration process (i.e., it appends some WebSphere goo). So code that only proceeds if an object isn't registered may fail since the registration is under a different name. Deregistration might also be affected but I'm not sure yet. I haven't confirmed the reported cause yet but I'm going to debug this issue on a WebSphere environment this afternoon. Assuming it's as reported, the most logical fix would be to retrieve the actual registration name during the registration process and then use this subsequently. This would require adding an instance variable to TreeCache to store the name as well as a getter/setter so that MBeanConfigurator can access the information. Alternative options would include modifying the registration method signature to pass the name or perhaps caching the information in MBeanConfigurator (ugh). The ActiveMQ posting suggests another alternative would be to use queryNames() instead of isRegistered() to determine whether an object is registered. I suppose the best alternative would be for WebSphere to modify their behavior. :) I'm planning to fix this initially for my employer as we're going to ship JBC 1.4.1 SPx with our next release for use on WebSphere. I can then apply whatever fix is appropriate to the JBC 1.4 code base. I know that the 2.0 code base is different so I'm not sure what would be appropriate there right now. I'll advise if my debugging turns up anything different but this is my current understanding of the problem and potential solutions. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038059#4038059 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038059

18 years, 11 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JCA's relation to ESB

by weston.price＠jboss.com

anonymous wrote : | My question is, how is ESB different than JCA? What are its value adds? | JCA is an 'enabling' technology, not a platform in and of itself. An ESB, as I understand it, provides a higher set of services (ie routing, rules, transformations etc). Again, I could be wrong on this being that the definition of an ESB is a bit hard to pin down. anonymous wrote : | Use Case #1: ESB is interacting with ESB-unaware message producers and consumers. | | In this case, where the ESB is sitting between two ESB-unaware clients, I don't think ESB provides any value (unless its doing some JBPM or Drools stuff) beyond JCA+MDB (inflow) and JCA outflow. I do see a benefit in the actions working with a generic, unifying Message interface though. | JCA just provides the mechanism for inflow and outflow it 'enables' a node to receive and send, what should be (again just my opinion) a generic message format. In the use case you mentioned, the ESB would be have to do *something* right? anonymous wrote : | The thing I worry about Use Case #2 is when JMS is involved. The JMS API is always going to be richer and more flexible than any all-in-one universal ESB messaging API. | Why? JMS is JMS. Are you saying is that all ESB related messaging semantics and characteristics should be able to be mappend onto JMS? Or again, am I completely missing something? It was my understanding that in an ESB, regardless of messaging type or technology (ie JMS) it has to go through some form of central authority managed by the ESB. To do this you need some internal representation of the message. If you choose JMS, are you basically saying that the ESB is JMS dependent at that point, regardless of client type. I thought that JMS was simply a transport/messaging format (one of many) that the ESB will support. anonymous wrote : | So ESB advantages: | | * Actions work with a unified Message interface. (Although I do think Seam integration will make this a bit mute). | * Clients work with a unified abstract Messaging interface that is protocol unaware. | | Yep, this more lin line with how I thought of an ESB. JCA simply provides the 'glue' to accomplish this from node to node. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038049#4038049 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038049

18 years, 11 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Finding the EPR for a provider from a notifier

by bill.burke＠jboss.com

JCA should not be a problem for 4.2. I know how it could be done based on the current code base. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038041#4038041 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038041

18 years, 11 months

1
0
0 / 0

[Design of JBoss ESB] - JCA's relation to ESB

by bill.burke＠jboss.com

Please tell me if I'm on the right track.... My question is, how is ESB different than JCA? What are its value adds? Use Case #1: ESB is interacting with ESB-unaware message producers and consumers. In this case, where the ESB is sitting between two ESB-unaware clients, I don't think ESB provides any value (unless its doing some JBPM or Drools stuff) beyond JCA+MDB (inflow) and JCA outflow. I do see a benefit in the actions working with a generic, unifying Message interface though. Use Case #2: ESB interacting with ESB aware message producers and consumers. In this case, ESB's messaging abstraction shines. The client is not aware of the protocol, or even underlying API the message is being published with. The thing I worry about Use Case #2 is when JMS is involved. The JMS API is always going to be richer and more flexible than any all-in-one universal ESB messaging API. Most of this richness can be hidden as attributes in the EPR (security, persistence, priority), but things like transacted delivery cannot (I guess this could be added to the ESB api). So ESB advantages: * Actions work with a unified Message interface. (Although I do think Seam integration will make this a bit mute). * Clients work with a unified abstract Messaging interface that is protocol unaware. BTW, I'm doing this to figure out in my mind why you guys do what you do. Why do you need a registry? So that clients can get at EPRs. Why do you have EPRs? So that clients have a protocol independent abstraction. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038040#4038040 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038040

18 years, 11 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - POP3 and MDB

by tomerbd2

Hi, Is there an option to have an MDB that listens to pop3 events via pop3 connector? Thanks Tomer View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038038#4038038 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038038

18 years, 11 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: JBossCX -- JBossJCA and Remoting

by anil.saldhana＠jboss.com

More than the tech, the name has become an issue of contention. JBossCX seems appropriate. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038035#4038035 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038035

18 years, 11 months

1
0
0 / 0

[Design of JBoss Serialization] - Re: JBSER-84 - Improving serialization

by mister__m

I think there are two use cases that would require a different API. First, if you are working with a third-party class, you may not be able to change it to implement Immutable. Another scenario is when it is safe to replace a Class, but it is not actually immutable. For instance, there might be a JavaBean named Order. When an order is equal to another one, it can be safely replaced, but it is not actually immutable. So I suggest the interface is renamed to Replaceable and a method is added to JOS that allows use-case replaceable classes to be registered. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038034#4038034 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038034

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: MDB/JCA adapter connection failures

by timfox

"adrian(a)jboss.org" wrote : | What I don't see is an invocation of the ExceptionListener | when it encounters this problem, instead it just logs a warning: | | | WARN 28-03 17:15:21,093 (JBossConnectionConsumer.java:run:303) -Connection consumer closing due to error in listening thread JBossConnectionConsumer[22, 1] | | javax.jms.JMSException: Unable to get a server session java.lang.Exception: Cannot get a server session after the pool is stopped | | | which is useless for recovery. | So we should call the connection's exception listener in this situation? I'm just querying this since this code was more or less ported from the JBoss MQ connection consumer which doesn't call the exception listener either. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038033#4038033 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038033

18 years, 11 months

1
0
0 / 0

[Design of JBossCache] - Re: Rigid design of state transfer manager, factories, integ

by manik.surtani＠jboss.com

There isn't any mechanism to inject a custom state transfer integrator/generator at the moment - and won't be for the foreseeable future. Why do you feel the default notification when state is integrated is insuffcient? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038032#4038032 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038032

18 years, 11 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-dev-forums April 2007