February 2009 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Transaction Services] - Re: 'public' API stability when embedded in JBossAS

by mark.little＠jboss.com

"adinn" wrote : anonymous wrote : | | This works for other projects, so I'm not sure why we need to make special rules. XTS is different in that there is no standard API for it to conform to, but I assume it's still using the internal/mwlabs approach so the above still applies. | | | | Err, well, not exactly -- we currently "expose" just the tip of the iceberg. i.e. we have split the deployed code into an "api" jar plus a set of "interna"l jars culled from the sar, WSAS, WSCF, WS-C, WS-T and WSTX components (ok, it's a little more messy but . . .). This split is only conventional -- all the jars are present in the deployed service archive but only one of them has 'api' in the name. The intention is that we install a copy of this jar in the AS client directory for users to compile against. | OK. A little strange, since I'm pretty sure we didn't have an api package in the past or have an equivalent elsewhere. But hey ho ;-) anonymous wrote : | The API jar only contains the (very) small number of classes required for AT and BA client code to compile correctly,-- not just the UserTX//BA and TX/BAManager classes but also ancillary classes like Vote, SystemException etc. | Wouldn't it be so much better if there was a JSR 156 jar to target ;-) ? anonymous wrote : | This also happens to be the exact same set of classes which comprise the API documented in the User Guide. There is no reason why a straight AT/BA client should ever need to look under the hood at what is contained in the internal jars. | Sure, I get that. anonymous wrote : | Of course this does not mean that someone cannot actually look under the hood. But there is very little incentive to do this with XTS. | There should be very little reason to do so with any project using internal structuring. In fact we typically don't even generate javadocs for those classes/interfaces which further discourages such deviant behaviour. anonymous wrote : | It does not provide any extensibility mechanisms for the benefit of XTS clients on a par with, for example, the LockManager or StateManager classes implemented by ArjunaCore. I agree we should proceed by deprecating public classes/methods in these internal jars | No, you misunderstand. Anything in the internal package structure (or mwlabs from legacy) can change without being deprecated. Of course you COULD deprecate it, but it's not necessary and the docs make that clear. Only public things (in api for the case of XTS) MUST be covered by the deprecation rules. anonymous wrote : | but I'd be surprised if anyone who was not implementing an extension to the XTS package ever needed to build on this code (e.g.perhaps the SOA platform guys might need to open them up). | Maybe, but in that case we could open them up either through moving them to public (the public interfaces can grow and shrink) or add new public wrappers to expose them. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209090#4209090 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209090

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: How to reliably determine if BeanMetaData contains depen

by kabir.khan＠jboss.com

"kabir.khan(a)jboss.com" wrote : "kabir.khan(a)jboss.com" wrote : T | | 6) getDependencies() is called with an AbstractInjectionValueMetaData and the dependency is picked out as expected. | | | should be: | 6) getDependencies() is called with an AbstractInjectionValueMetaData (child of 2) and the dependency is picked out as expected. | lol "6) getDependencies() is called with an AbstractInjectionValueMetaData (child of 5) and the dependency is picked out as expected." View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209087#4209087 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209087

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: How to reliably determine if BeanMetaData contains depen

by kabir.khan＠jboss.com

"kabir.khan(a)jboss.com" wrote : T | 6) getDependencies() is called with an AbstractInjectionValueMetaData and the dependency is picked out as expected. | should be: 6) getDependencies() is called with an AbstractInjectionValueMetaData (child of 2) and the dependency is picked out as expected. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209086#4209086 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209086

17 years, 1 month

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: 'public' API stability when embedded in JBossAS

by adinn

anonymous wrote : | This works for other projects, so I'm not sure why we need to make special rules. XTS is different in that there is no standard API for it to conform to, but I assume it's still using the internal/mwlabs approach so the above still applies. | Err, well, not exactly -- we currently "expose" just the tip of the iceberg. i.e. we have split the deployed code into an "api" jar plus a set of "interna"l jars culled from the sar, WSAS, WSCF, WS-C, WS-T and WSTX components (ok, it's a little more messy but . . .). This split is only conventional -- all the jars are present in the deployed service archive but only one of them has 'api' in the name. The intention is that we install a copy of this jar in the AS client directory for users to compile against. The API jar only contains the (very) small number of classes required for AT and BA client code to compile correctly,-- not just the UserTX//BA and TX/BAManager classes but also ancillary classes like Vote, SystemException etc. This also happens to be the exact same set of classes which comprise the API documented in the User Guide. There is no reason why a straight AT/BA client should ever need to look under the hood at what is contained in the internal jars. Of course this does not mean that someone cannot actually look under the hood. But there is very little incentive to do this with XTS. It does not provide any extensibility mechanisms for the benefit of XTS clients on a par with, for example, the LockManager or StateManager classes implemented by ArjunaCore. I agree we should proceed by deprecating public classes/methods in these internal jars but I'd be surprised if anyone who was not implementing an extension to the XTS package ever needed to build on this code (e.g.perhaps the SOA platform guys might need to open them up). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209083#4209083 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209083

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB3 enterprise module?

by camunda

Damn, it seems that linking a Timer to an EJB3 Entity seems not to be possible like in EJB 2.1 (regarding https://jira.jboss.org/jira/browse/JBPM-886). Or if anybody has an idea I would be delighted. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209081#4209081 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209081

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: How to reliably determine if BeanMetaData contains depen

by kabir.khan＠jboss.com

That is exactly what I had and which does not work, see my first post... Reorganising the code a bit | private void getDependencies(ArrayList<ValueMetaData> dependencies, MetaDataVisitorNode node) | { | if (node instanceof AbstractDependencyValueMetaData) | { | dependencies.add((AbstractDependencyValueMetaData)node); | } | | Iterator<? extends MetaDataVisitorNode> children = node.getChildren(); | | if (children != null) | { | while (children.hasNext()) | { | MetaDataVisitorNode child = children.next(); | getDependencies(dependencies, child); | } | } | } | 1) getDependencies() gets called with an AbstractBeanMetaData, this finds a child and calls getDependencies() 2) getDependencies() gets called with an AbstractPropertyMetaData (child of 1), this finds a child and calls getDependencies() 3) getDependencies() gets called with an AbstractValueMetaData (child of 2), this finds a child and calls getDepedencies() 4) getDependencies() gets called with a PropertyMap (child of 3), this finds a child and calls getDepedencies() 5) getDependencies() gets called with a PropertyMap$ValueInfo (child of 4), this has no children and the loop returns Looking at the PropertyMap$ValueInfo, it contains the AbstractInjectionValueMetaData I want, but no way to get hold of it. From my debugger: | node PropertyMap$ValueInfo (id=113) | hashCode -2147483648 | log Logger (id=118) | name "dependency" (id=120) | toString SoftReference<T> (id=124) | value AbstractInjectionValueMetaData (id=126) | PropertyMap$ValueInfo seems wrong, replacing | public Iterator<? extends MetaDataVisitorNode> getChildren() | { | return value.getChildren(); | } | with | public Iterator<? extends MetaDataVisitorNode> getChildren() | { | return Collections.singletonList(value).iterator(); | } | I get this for 5) onwards: 5) getDependencies() gets called with a PropertyMap$ValueInfo (child of 4), this finds a child and calls getDepedencies() 6) getDependencies() is called with an AbstractInjectionValueMetaData and the dependency is picked out as expected. So either PropertyMap$ValueInfo.getChildren() needs to be fixed, or you need to come up with something else if that fix is not valid. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209080#4209080 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209080

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: split-brain between live and backup node

by jmesnil

from #jbossmessaging channel http://www.antwerkz.com/javabot/javabot/home/3/%23jbossmessaging/2/11/1/0...: | [14:33] jbossfox: i solved the problem | [14:33] jbossfox: jmesnil: it's a combination of a few things | [14:33] jbossfox: jmesnil: firstly - the issue i explained on the forums | [14:33] jbossfox: jmesnil: when the client fails over | [14:33] jbossfox: jmesnil: this results in the backup server closing the replicating connection from the live server | [14:34] jbossfox: jmesnil: but this closure forces a ConectionDestroyed, not ConectionException | [14:34] jbossfox: jmesnil: in NoCacheConnectionLifeCycleListener | [14:34] jbossfox: jmesnil: so the replicating channel is never set to null | [14:34] jbossfox: jmesnil: basically like i explained on the forums | [14:34] jbossfox: jmesnil: but on top of that | [14:35] jbossfox: jmesnil: there was a bug where the replicatingconnection wasn't being set to null | [14:35] jbossfox: jmesnil: only the replicating channel | [14:35] jbossfox: jmesnil: so subsequent createsession attempts would attempt to replicate still | [14:35] jbossfox: jmesnil: and hang | [14:35] jmesnil: jbossfox: ah, ok, that's where the replicating channel was coming from | [14:35] jbossfox: jmesnil: yeah it was creating a new connection to the backup | [14:35] jbossfox: jmesnil: and then... | [14:36] jbossfox: jmesnil: a further bug | [14:36] jbossfox: jmesnil: where the server still thinks it has a backup | [14:36] jbossfox: jmesnil: even after the replicating connection fails | [14:36] jbossfox: jmesnil: so when getreplicatingconnection is called it creates a new one | [14:36] jbossfox: jmesnil: so i set backupconnectorFactory to null in this case | [14:36] jbossfox: jmesnil: then..... | [14:37] jbossfox: jmesnil: there is a further interesting quirk | [14:37] jbossfox: jmesnil: if backupconnectorfactory is not null then when getreplicatingconnection is called it will create a new connection | [14:37] jbossfox: jmesnil: so it was basically just creating a new backup connection to the backup | [14:37] jbossfox: jmesnil: and then.... | [14:38] jbossfox: jmesnil: when you create a new consumer on the live, you've got to remember the old server side consumer from before client failove is still there! | [14:38] jbossfox: jmesnil: so any messages will be round robin'd between them | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209069#4209069 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209069

17 years, 1 month

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: 'public' API stability when embedded in JBossAS

by mark.little＠jboss.com

Anything that is within the internal package should not be covered by deprecation. It's in the docs and the support guys are aware of it. Anything public can change through normal deprecation rules. This works for other projects, so I'm not sure why we need to make special rules. XTS is different in that there is no standard API for it to conform to, but I assume it's still using the internal/mwlabs approach so the above still applies. The trouble with listing interfaces/classes is that it's fairly arbitrary. Do we take only what we use in the AS? What about when running stand-alone? What about JTS or any of the extensions we have to the various standards? So I'd prefer that we stick with the .internal. and use the deprecation rules (which don't prevent changes that are incompatible with previous releases, but in a controlled manner.) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209060#4209060 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209060

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: How to reliably determine if BeanMetaData contains depen

by alesj

You're doing it wrong. ;-) This is all you need: | void doVisit(MetaDataVisitorNode node) | { | // check node | someNodeCheck(node); | | Iterator<? extends MetaDataVisitorNode> children = node.getChildren(); | if (children != null) | { | while(children.hasNext()) | { | doVisit(children.next()); | } | } | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209051#4209051 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209051

17 years, 1 month

1
0
0 / 0

[Design of the JBoss EJB Container] - JBoss 5 EJB Container JNDI question

by deruelle_jean

Hi, We are currently porting our implementation of Sip Servlets (see http://www.mobicents.org/products_sip_servlets.html) on top of JBoss 5 (currently working on Tomcat and Jboss AS 4.2.3). Our source code for the port is currently available from http://code.google.com/p/mobicents/source/browse/trunk/servers/sip-servle... (svn browsing) The Sip Servlets spec mandates that for converged containers, a SipFactory would appear as java:/comp/env/sip///SipFactory (where appname is the name of the sip servlets application deployed similarly to a web applciation) in the JNDI mapping or injected as an @Resource annotation. This annotation can be used in any SIP Servlet or a JEE application component deployed on the converged container in the same EAR archive file. The SipFactory is an interface for a variety of SIP Servlet API abstractions, which could allow an EJB to initiate a sip call by example. In an EAR, we could have many Sip Servlets Applications, so we would need when deploying the sip applications (Tomcat Contexts) to be able to access the private naming context (java:/comp/env/) of the JEE components in the EAR file (EJB, webservices, mdb, ...) to inject the SipFactory of each app bundled within the EAR. I was currently able to do it quite easily (see http://code.google.com/p/mobicents/source/browse/trunk/servers/sip-servle...) But I want to be 100% this will work in all cases so here is my questions : Can I be 100% sure that the EJB Containers will always be deployed before the web applications ? On what is based the deploy ordering of components within an EAR ? To detect that a deployment unit has JEE componenst I check if it has an Ejb3Deployment attached to its deployment unit (see http://code.google.com/p/mobicents/source/browse/trunk/servers/sip-servle...), may I miss some other JEE components this way ? Thanks in advance Best regards Jean Deruelle, JBoss, a division of Red Hat View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209049#4209049 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209049

17 years, 1 month

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 February 2009