[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
15 years, 8 months
[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
15 years, 8 months
[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
15 years, 8 months
[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
15 years, 8 months
[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
15 years, 8 months