September 2007 - jboss-dev-forums

[Design of JBoss Transaction Services] - Re: IIOP stub compiler design problem

by reverbel

Yes, the client stub for the EJB is being built on the fly by the IIOPStubCompiler. However, that stub should also use the default ORB instance in the AS. Are you using the JNDI context factory that avoids the creation of other ORB instances? If your jndi.properties file (the one in the conf dir of the AS) has a line java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory replace that line with java.naming.factory.initial=org.jboss.iiop.naming.ORBInitialContextFactory You can disable the usage of dynamically generated stubs by putting rmic-generated stubs in the client classpath. This should not be necessary, though. Everything is supposed to work with the dynamic IIOP stubs. Regards, Francisco View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082431#4082431 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082431

18 years, 7 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Getting the release process working with javaee

by scott.stark＠jboss.org

"wolfc" wrote : I modeled the versions in the javaee subprojects to be the same as the spec version. So we should never bump these. Maybe we need a build number in there as well, like in RPMs (jboss-javaee-5.0-1)? Yes, that sounds like a good approach. So while the aggregate may be at Beta3, the subprojects are at the spec version with a build number qualifier. A version like 5.0-a does not match the osgi version conventions we outlined though. It would need to be something like 5.0.0.X-buildnumber as the qualifer portion is free-form and should not impact compatibility comparisons. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082401#4082401 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082401

18 years, 7 months

1
0
0 / 0

[Design of JBoss Media (EMB)] - SCOTT SERAFIN GREGORY CHEW

by HRH

SCOTT SERAFIN IS BLACKLISTED IN THE PETROLEUM TRADING INDUSTRY. ANY PERSON OR COMPANY FOUND DOING BUSINESS WITH SCOTT SERAFIN OR HIS STRAWMEN WILL BE BLACKLISTED. RECENTLY SCOTT SERAPHIN AND GREG CHEW ATTEMPTED TO CIRCUMVENT INTERMEDIARIES AND PRINCIPLES IN A 6,000,000 BARREL JET FUEL TRANSACTION. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082374#4082374 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082374

18 years, 7 months

1
0
0 / 0

MESSAGE REMOVED BY ADMIN

by Mail Admin

MESSAGE REMOVED BY ADMIN - mailman(a)lists.jboss.org

18 years, 7 months

1
0
0 / 0

[Design of JBoss Transaction Services] - IIOP stub compiler design problem

by jhalliday

Francisco or anyone else who had a hand in the IIOP framework for JBossAS 4.0.5: I'm deploying an EJB (v2 vintage) into JBossAS 4.0.5 and trying to access it from another EJB, using RMI/IIOP. It works fine until I need transaction propagation on the call. I've plugged in ArjunaJTS, which registers interceptors with the AS's default ORB instance to handle the transaction context propagation. On most calls these work fine. However, for calls to the EJB, a different ORB is used and it does not have the interceptors registered on it. As far as I can tell, the client stub for the EJB is being built on the fly by the IIOPStubCompiler. How does it determine the ORB to use and how do I force it to use the same one as the rest of AS i.e. the one with the interceptors configured on it? Thanks Jonathan. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082360#4082360 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082360

18 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failure on XAResourceRecoveryTest

by clebert.suconic＠jboss.com

Problem solved! Our testsuite was setting both ObjectStoreDir and XA_NODE_IDENTIFIER on every test. This wasn't a problem until we used XidImple directly, as that started a StatusManager before we set XA_NODE_IDENTIFIER, and later the subsequent test would fail on getTransactionStatus: Because of this scenario, process_id would never be found on _tscTable: >From jbossts (arjuna): public int getTransactionStatus(String transactionType, Uid tranUid) | { | int status = ActionStatus.INVALID; | | // extract process id from uid, use to index into | // hash table to obtain transaction status connector | // with which to retrieve the transaction status. | | String process_id = get_process_id(tranUid); | | if (!_tscTable.containsKey(process_id)) | { | updateTSMI(); | } | | if (_tscTable.containsKey(process_id)) | { | TransactionStatusConnector tsc = (TransactionStatusConnector) _tscTable.get(process_id); | | if (tsc.isDead()) | { | _tscTable.remove(process_id); | tsc.delete(); | tsc = null; | } else | { | status = tsc.getTransactionStatus(transactionType, tranUid); | } | } | | Worse then finding a bug in an apple, is finding a half one :-) This one here was like finding a half one to me... TGIF and this is now solved! And thanks for your help Mark View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082298#4082298 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082298

18 years, 7 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Getting the release process working with javaee

by wolfc

I modeled the versions in the javaee subprojects to be the same as the spec version. So we should never bump these. Maybe we need a build number in there as well, like in RPMs (jboss-javaee-5.0-1)? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082295#4082295 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082295

18 years, 7 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Getting the release process working with javaee

by pgier

"scott.stark(a)jboss.org" wrote : "pgier" wrote : "scott.stark(a)jboss.org" wrote : | | | 1. Being able to to a mvn release:* to create the canonical maven2 artifacts as well as the jboss repo artifacts. A current issue is how the versioning is handled. You have to have x.y-SNAPSHOT releases of every project, and these are updated to x.(y+1)-SNAPSHOT in trunk (unless overriden). This does not match our versioning conventions of x.y.z.[Alpha|Beta|CR|GA] in that there can be several x.y.z releases with only the qualifier changing. Its a pain to have to override the release and next version for a large project like javaee, and worse for the mc. Can we customize this to better match our conventions? | | | | | We don't have many options for customizing the defaults for a release. For example, the release plugin doesn't have any way to know whether the next release after Beta1 should be Beta2 or CR1. For mc I don't think it's an issue because all the modules have the same version, so you just have to type it in once. With javaee since all the sub-projects are at different versions, there isn't any way I can think of to get around just entering the version for each one. | | | We need to start working towards such a feature request then. This is a simple plugin enhancement to obtain the next version, and the plugin can request what info it needs to determine if the release is moving from Beta1 to Beta2 vs Beta1 to CR1 or GA. | The release plugin already prompts you for the release version, tag, and next version. What is the enhancement that you are looking for? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082294#4082294 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082294

18 years, 7 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Getting the release process working with javaee

by scott.stark＠jboss.org

"pgier" wrote : "scott.stark(a)jboss.org" wrote : | | 1. Being able to to a mvn release:* to create the canonical maven2 artifacts as well as the jboss repo artifacts. A current issue is how the versioning is handled. You have to have x.y-SNAPSHOT releases of every project, and these are updated to x.(y+1)-SNAPSHOT in trunk (unless overriden). This does not match our versioning conventions of x.y.z.[Alpha|Beta|CR|GA] in that there can be several x.y.z releases with only the qualifier changing. Its a pain to have to override the release and next version for a large project like javaee, and worse for the mc. Can we customize this to better match our conventions? | | | We don't have many options for customizing the defaults for a release. For example, the release plugin doesn't have any way to know whether the next release after Beta1 should be Beta2 or CR1. For mc I don't think it's an issue because all the modules have the same version, so you just have to type it in once. With javaee since all the sub-projects are at different versions, there isn't any way I can think of to get around just entering the version for each one. | We need to start working towards such a feature request then. This is a simple plugin enhancement to obtain the next version, and the plugin can request what info it needs to determine if the release is moving from Beta1 to Beta2 vs Beta1 to CR1 or GA. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082289#4082289 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082289

18 years, 7 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Getting the release process working with javaee

by scott.stark＠jboss.org

"pgier" wrote : | "scott.stark(a)jboss.org" wrote : | | 2. The eclipse project classpath settings need to be updated for the version updates as part of the release process. | | | Would it be better to not have the .project and .classpath in subversion? I normally use the IDE plugin (http://m2eclipse.codehaus.org/) and it generates the classpath for me from the pom. It's not perfect, but it's gradually getting better. | Also, don't some people use IDEA? The .project and .classpath are useless for them anyway. | The eclipse project files are already in subversion. I don't care about the IDEA users. Our tools platform is not based on it, so they have to fend for themselves. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082287#4082287 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082287

18 years, 7 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 September 2007