November 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss ESB] - Re: JMS Provider(s) Design - JBossMQ/JBossMessaging/ActiveMQ

by mark.little＠jboss.com

Weston, let's wait until Kurt recovers from Thanksgiving festivities. He is tasked with the MQSeries re-qualification. Rosetta already supported MQSeries through whatever mechanism and for expediency (plus the fact it's tried and tested) I'd assume we would use the same approach for the initial GA. Arvinder was driving the ActiveMQ integration, but Kurt was helping due to commitments on Arvinder's part. Rather than play guessing games, let's wait until everyone is online to contribute and we have all of the facts to play with. Cheers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988464#3988464 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988464

19 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMS Provider(s) Design - JBossMQ/JBossMessaging/ActiveMQ

by mark.little＠jboss.com

"kurt.stam(a)jboss.com" wrote : As is typical for ESBs, this release does not support transactions (in the real world most transports will use files, email, ftp etc). For the time being we use plain JMS, no JCA and/or mbeans. However I'm pretty sure we want to be transactional in the (near?) future. So future release will need JCA for sure. But this is more of a Mark question, I'm sure he will comment on this later this weekend. | Yes, we'll definitely need to support transactions in the future (2007). We should leverage the transaction bridging approach that we've used in JBossTS, so transactions can flow between implementations/models (multi-modal transactions). Getting the model right is important. The implementation (which uses JCA BTW) should be pretty straight forward. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988463#3988463 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988463

19 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMS Provider(s) Design - JBossMQ/JBossMessaging/ActiveMQ

by arvinder

I have no idea what is being used right now. If you look back in the thread I did the ActiveMq investigation. AFAIK Kurt was looking at MQS, I just started looking at it this week, although I have yet to install it. anonymous wrote : | So you are using the community edition JCA/JMS adapter? | Without further investigation, I can't answer your question. What community edition are you referring to? This term AFAIK is being applied to the Websphere Application Server Comunity Edition aka wrapper geronimo. AFAICT there is no 'community edition' MQS. So I am unsure what you are referring to when you say community edition JCA/JMS adapter. anonymous wrote : | That is surprising | What about? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988462#3988462 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988462

19 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMS Provider(s) Design - JBossMQ/JBossMessaging/ActiveMQ

by mark.little＠jboss.com

"weston.price(a)jboss.com" wrote : No, IBM has no such RAR. They do not provide a JCA/JMS RAR for WebSphereMQ that I know of. You are more than welcome to use our JMC/JCA adapter with a few exceptions. | | What I want to know about ESB's integration strategy in terms of tranasctional resources in general. We should be using JCA wherever possible. If we don't right now that's fine, but moving forward we should coordinate this type of effort between the teams. | | JCA support is on the roadmap for 2007. Let's talk early next year, i.e., once the 4.0 GA is out the door. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988460#3988460 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988460

19 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMS Provider(s) Design - JBossMQ/JBossMessaging/ActiveMQ

by weston.price＠jboss.com

So you are using the community edition JCA/JMS adapter? That is surprising. Yes, let's wait for Kurt. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988455#3988455 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988455

19 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMS Provider(s) Design - JBossMQ/JBossMessaging/ActiveMQ

by arvinder

There seems to be a rar reference here: http://www-128.ibm.com/developerworks/websphere/library/techarticles/0601... Lets wait for Kurt to join in. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988451#3988451 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988451

19 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMS Provider(s) Design - JBossMQ/JBossMessaging/ActiveMQ

by weston.price＠jboss.com

No, IBM has no such RAR. They do not provide a JCA/JMS RAR for WebSphereMQ that I know of. You are more than welcome to use our JMC/JCA adapter with a few exceptions. What I want to know about ESB's integration strategy in terms of tranasctional resources in general. We should be using JCA wherever possible. If we don't right now that's fine, but moving forward we should coordinate this type of effort between the teams. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988449#3988449 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988449

19 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMS Provider(s) Design - JBossMQ/JBossMessaging/ActiveMQ

by arvinder

Hi Weston, Integration with ActiveMq is done via JCA, for IBM MQS, I beleive there is a rar aswell, although I need to check the distribution. I need to speak to Kurt to see the next set of steps to follow and the best way to code this plugin. Is there something specific you wanted to talk about? Is this related ? http://jira.jboss.com/jira/browse/JBAS-3183 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988448#3988448 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988448

19 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Branch 1_0_XARecovery

by juha＠jboss.org

FYI, Branch XA_Recovery adds build dependency to JBossTM. Also, release-admin has been modified to create a configuration that replaces the AS local TM with JBossTS implementation. For that purpose the build creates a jboss-messaging-integration.jar that contains the relevant integration class implementations. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988439#3988439 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988439

19 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Zero turnaround Java/JBoss

by bill.burke＠jboss.com

Had an IM conversation with Gavin on "Zero turnaround Java". Basically the idea centers around a development turnaround time closer to that of PHP. I thought about a few things of how we could be as Zero-Turnaround as possible. Here is a breakdown of possible tasks/features we could do step by step: * A real "redeploy" event that reuses the DeploymentUnit/Context. In this case deployment metadata could be reused if metadata sources (.class or .xml files) have not changed on disk within the deployment. To make this happen, the deployment unit is going to have to remember all sources of metadata within the deployment. EJB for example would be a set of ejb-jar.xml, jboss.xml, bean class (and superclasses) as well as business interfaces as all these things are sources of metadata. * This point makes me wonder if the *redeploy* event should pass a list of changed files within the deployent unit path. * Hot Swap is useless. Yes it is neat, but since schema changes aren't allowed, its not going to cover 100% of cases. IMO, any Zero Turnaround solution needs to cover 100% of use cases otherwise there will be a lot of user confusion when things go bad. * Since Hot Swap is not viable, we will need to create a new classloader on redeployment to load changed classes. I'm guessing we can greatly speed up classloading on redeployment if we cache resources. The idea is that a classloader has a resource cache, on redeployment, the ClassLoader of the DeploymentUnit hands off its resource cache to a newly created ClassLoader. This way the new ClassLoader does not have to go to disk to load the .class file and can just get things from memory. Not sure how much this would speed up things, but this idea can be used for my next point. BTW, I think running in a debug session of most IDEs would allow for non-schema based code changes are runtime anyways. * When I've used PHP or another scripting language, the coolest thing for me was that there was no build/compilation step and you had WYSIWYG development as the source files were directly in your deployment path. I think we can do the same for Java. The idea would be to have a ".java" based ClassLoader. When a class needs to be resolved, the ClassLoader would look in its classpath for .java files or look in a memory cache for compiled bytecode. I took a look at Eclipse's JDT, the compiler that Tomcat uses to comple JSP source. Its pretty cool. You have total control on where to resolve source and bytecode when compiling something. A scanner would watch all ".java" files within a deployment. If one changed it would cause a redeployment event to happen. The resource-cache-based ClassLoader I talked about above could be used to cache compiled .java source. This would make the JDT compilation step much faster as it would only require a recompiling of modified .java files. * A blog Gavin mentioned to me talked about being able to cache an HTTP Session (or SFSB Session) between a redeploy. This enables Zero-turnaround even further as at runtime you can make a modification to your web application or EJB right in the middle of testing a web app. The way it would work is that the HTTP SEssion/SFSB session would be serialized and reloaded after a new classloader was created to pick up the class changes. I think this is a cool idea, but suffers from the same problems as Hot Swap: - I'm pretty sure that a schema change to a .class file will generate a different SerialVersionUUID for default serialization. So, we would need to use JBoss Serialization to ignore version id mismatches. - I don't know if a schema change (an additional field added) would break the serialized HTTP Session/SFSB Session on deserialization. - Because of both of these problems, I think just using the IDE to do non-schema code changes during and within a test run is good enough. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988437#3988437 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988437

19 years, 4 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 November 2006