September 2007 - jboss-dev-forums

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

by jhalliday

When I'm running outside the app server Properties p = new Properties(); p.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.cosnaming.CNCtxFactory"); p.put("java.naming.corba.orb", myORB.orb()); p.put(Context.PROVIDER_URL, "corbaloc::localhost:3528/JBoss/Naming/root"); seems to be the way to go since ORBInitialContextFactory is not available. Inside the app server ORBInitialContextFactory does the right thing. Now if we can just sort out the TxServerInterceptor hardcoding, pluggable JTS integration may actually work. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086085#4086085 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086085

18 years, 6 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Running tests against the real transaction manager

by adrian＠jboss.org

I've updated all the org.jboss.test.tm tests to run inside the appserver so they test the real transaction manager rather than TxManager. These were mainly stress tests of the TransactionLocal. The good news is that there are no new failures. I'm going to look at doing the same thing for the jca tests and any others that are testing against the old transaction manager. P.S. You know the transaction timeout tests are failing with 4.3.0-beta1 in HEAD? I already ported the fixed version of the test from 4.2 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086083#4086083 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086083

18 years, 6 months

1
0
0 / 0

[Design of JBoss Transaction Services] - TxServerInterceptor hardwiring

by adrian＠jboss.org

This is just to document what Jonathon discovered and communicated in a private e-mail The iiop servants for EJBs (both home and ejbobject) hardwire the TxServerInterceptor to retrieve the transaction from the request. There is a similar problem for the security. We need to come up with some integration api such that the iiiop ejb proxy doesn't depend upon specific transport configuration like what interceptors are used. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086077#4086077 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086077

18 years, 6 months

1
0
0 / 0

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

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : Does the generated code do runtime lookup of the ORB to use in the client JVM? It is handled by the ORB itself. anonymous wrote : How do I interfere with that process. This hack would involve something like casting the object to a corba ObjectImpl and setting the delegate manually. Not sure how that would work if you are changing ORBs???? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086076#4086076 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086076

18 years, 6 months

1
0
0 / 0

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

by adrian＠jboss.org

"jhalliday" wrote : Adrian - | What's the correct technique where a client application is needing to use dynamically generated stubs? Presumably the compilation occurs on the server and the stub is sent down to the client. Does the generated code do runtime lookup of the ORB to use in the client JVM? How do I interfere with that process, since ORBInitialContextFactory is not present on the client? Or do I need to add it to the client classpath, even though it's part of the /server/lib not /client/lib It seems like if I can do a ORBInitialContextFactory.setORB(myORB); in the client and the dynamically loaded stubs will respect it then that should work? The ORBInitialContextFactory should be automatically setup by the appclient environment. If you are outside an appclient then you need to do it yourself. Other alternatives include: 1) Setting the ORB in the environment yourself (after the initial context is constructed) 2) Configuring the ORBInitialContextFactory yourself 3) Writing your own ICF 4) Let CosNaming create an ORB for every request, but override all the system properties to make it use JacORB when it creates a new one (see the testsuite for details). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086067#4086067 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086067

18 years, 6 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Resource adapter transaction timeout enforcement

by adrian＠jboss.org

"david.lloyd(a)jboss.com" wrote : | Remoting has no state, or direct awareness of transactions. However, whatever service you're connecting to by way of Remoting may (and probably does). The reason Remoting 3 has this capability is so that there's a single standard way to propagate transaction state between endpoints - whether it's a database to an app server, two app servers together, or two client applications that don't even know anything about JTA or JCA or anything like that. | I don't understand. Unless I've misunderstand your requirement. What you describe is called OTS/JTS. It's already a standard and is probably a lot more complicated than you've envisoned to do correctly and efficiently. :-) There's also already an implementation of JTS that uses remoting in JBoss5 - see the transaction project, but we are dropping it in favour of JBoss JTS (which should be augmented with a version that runs over remoting rather than just RMI/IIOP). There's also some overlap with transactional webservices. You need to speak to the transaction team and make sure you are on the same page. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086052#4086052 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086052

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Unifying metadata

by adrian＠jboss.org

"alex.loubyansky(a)jboss.com" wrote : Except for addParam and importEjbJarXml that are used during parsing. All the parsing has been dropped. Any mutation that wasn't part of the parsing should be covered by methods that throw UnsupportedOperationExceptions (unless you can figure out how to support the mutation operation via the bridge :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086040#4086040 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086040

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Unifying metadata

by adrian＠jboss.org

"wolfc" wrote : but shouldn't we ditch all the old stuff? No. Unless we are going to ditch the whole EJB2 container and replace it with EJB3 equivalents (including a CMP1.1 and CMP2 impl for backwards compatibility). The old BeanMetaData is part of the api for the old EJB2 container that people used to write their interceptors. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086037#4086037 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086037

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Unifying metadata

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : The org.jboss.metadata from the metadata project, for example: | https://svn.jboss.org/repos/jbossas/projects/metadata/trunk/src/main/java... | | is not usable as a replacement for the server project version, because its abstract. Its also not a complete replacement for the existing version. How was this generated, and why is the MethodMetaData abstract? | It isn't possible to provide a complete mapping of some of the metadata without going through a long winded and unnecessary mapping/combining process of the different parts of the model. The method metadata is stored in multiple places. If we'd had interfaces in the correct places in the original model then we could do a lot more. In practice it isn't necessary. The MethodMetaData is never accessed for everything all at once. So we just provide delegates for the aspect where it is used. e.g. There is a getTransactionMethods() in the old BeanMetaData so we create a delegate that only gives access to the transaction attributes of the method. Or similarly for permissions. https://svn.jboss.org/repos/jbossas/projects/metadata/trunk/src/main/java... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086033#4086033 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086033

18 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: Patch adding transactional putSilent() method

by Cyberax

"manik.surtani(a)jboss.com" wrote : Just an initial thought on your patch, but by not suspending any ongoing transactions and working on the workspace nodes directly means that this fix isn't portable across node locking schemes. In the pessimistic case this will still allow cache failures to cause your business transactions to roll back. Yes, I know. I was not interested in pessimistic locking when I wrote this patch. Please, correct me if I'm wrong, I think that we can just discard exceptions from put() method in pessimistic locking mode. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086030#4086030 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086030

18 years, 6 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