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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: XA recovery integration

by juha＠jboss.org

Well it's not a placeholder anymore, since the required methods have been filled in. So the required hookup should be in place for server startup. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988838#3988838 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988838

19 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: XA recovery integration

by timfox

If you mean, in the 1_0 branch, then yes, but this code is basically just a placeholder. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988836#3988836 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988836

19 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: XA recovery integration

by timfox

Not sure what you mean by "already". The code in TRUNK doesn't load the transactions at startup. Since this was to be done as part of the transaction recovery task. Although the intention was it would do that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988834#3988834 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988834

19 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: XA recovery integration

by juha＠jboss.org

"juha(a)jboss.org" wrote : | Ok, so from that thread you appear to be saying that you already populate the tx map at server startup. Is that the case or not? | | And according to ServerPeer, yes you do. TransactionRepository is created and loadPreparedTransactions is called which populates the tx map with prepared transactions. So we should be fine on that account. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988830#3988830 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988830

19 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBossTS/JBossJCA XA/Local transactions

by rupertlssmith

Thank goodness for JBossTS. It is the missing piece in turning JBoss into a 'real' application server. I suggested on the other thread, that if it _really_ needs to support the broken XA implementation of JBossTM, purely for backward compatibility convenience, maybe a config switch should be added to turn it on? With suitable warnings issued at start up, or when enlisting multiple local tx resources? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988827#3988827 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988827

19 years, 4 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: 2 NICS 2 Networks, slow results

by galder.zamarreno＠jboss.com

Please, use the User forums for such question. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988823#3988823 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988823

19 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: ESB configuration

by mark.little＠jboss.com

Sacha, we'll definitely support MC in the next release. That's on our roadmap. OSGi is something we're seeing requests for, but it's a longer term issue. Since the ESB architecture is not to mandate any implementation of anything (e.g., service or container) in order to ensure we offer customers a much better capability to leverage their existing infrastructural investments, how we approach that from an implementation perspective is important. It sounds like MC could be the basis for this multi-container support. But for the 4.0 release, where we won't have MC (or OSGi) support, we still need configurations that are simple enough for people to understand and use. Those configurations will change for the better in the next GA release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988807#3988807 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988807

19 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ControllerStates sequential flow for dependent Contexts

by vickyk

anonymous wrote : | The bean / state will 'go' as far as you let him to go - applying the deployment mode, defined state, dependencies, demand, ... | Correct.... But for the scenario which I explained earlier I wanted to know the intermediate context states, let me check the code. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988806#3988806 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988806

19 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: ESB configuration

by sacha.labourey＠jboss.com

Guys, I think we need to clarify a few things. First, the relationship between the MC (or MK, that's the same here) and the AS. The AS is JUST a SPECIFIC set of services running on top of the AS. Consequently, if you: - take JBoss AS - drop ALL services from /deploy and unneeded files from /lib and /conf - add your ESB JAR and services definition This IS your ESB and has NOTHING to do with the AS. Again, this is just about what services YOU decide to deploy, or not, this is MARKETING: at heart, EVERYTHING is just a MC on steroids. Now, on the MC vs. MK. MC will obviously offer MUCH MORE than what the MC offers, but I DOUBT that the MK currently lacks ANYTHING you need for the ESB: For example, starting a few mbeans and putting your esb configuration at the MBean levels rather than inside a conf file, is really trivial. Also, your MK MBean definitions ARE totally backward compatible with the MC => you will be able to deploy your MK files/services/MBeans definition AS-IS, without the need to first POJO-ize them. That offers a VERY smooth migration path for the ESB and should be leveraged IMHO. Last point: OSGi vs. MC. We should definitively leverage the MC. Our MC offers more than what an OSGi implementation would: OSGi is just a "personnality" of the MC, nothing more. Also, the JBoss strategy is really to use the MC as a way to embed our JEMS components (*including* things such as the PORTAL) in other AS or other environments. Then, it is UP TO the MC to do that "mapping job": it shouldn't be the job of the ESB team to map the ESB to the MC, then to a phone, then to Weblogic, then to OSGi, then to Webshpere, etc. your responsibility is to map the ESB to the MC and that's all, then it will be the MC's responsibility to map the MC services to all of these environments. That way, if we want to have, let's say, the portal run in Weblogic, we trivially get it as well: once the MC is migrated to WL, anything that runs on the MC would now run on WL. You should really discuss with Scott and/or Adrian I think, that might clarify a few things. Also, Adrian has been working on a "Servivces API and SPI" so that if you need specific services, you can bind in this MC API instead, so that the MC can then properly do its mapping job to services offered by the hosting environment. Also, the MC is the way to get support from JBoss ON (through the Profiles service). Cheers, sacha View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988805#3988805 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988805

19 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: ESB Packaging

by mark.little＠jboss.com

Wizards is a general catch-all term that we've been using to cover simplifying the deployment and configuration of the ESB. It's not just configuring a few XML files, but may require integration code. That could certainly encompass MBeans for an AS deployment. I think we're agreed that the two deployment choices our "wizards" need to support are inside of AS and a stand-alone (outside of AS) deployment. We'll have something in place for the GA that covers both. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988804#3988804 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988804

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