[Design of POJO Server] - Re: AS 5 interoperability rules
by bstansberry＠jboss.com
Thinking out loud a bit here, so feel free to ignore me... :-)
The JBAS-4802 issue is a simpler aspect of the general problem, since as you say I can just keep the old policy impl around and people can make a config change to revert to the old policy if they want to use older clients.
Trickier is the LoadBalancePolicy interface itself, which unfortunately has this method:
public Object chooseTarget (FamilyClusterInfo clusterFamily,
org.jboss.invocation.Invocation routingDecision);
That's the legacy invocation class. Useless method for an AOP-based client. Our standard impls don't currently use this method, but http://jira.jboss.com/jira/browse/JBAS-4455 is a customer feature request that would. Logically, an AOP-based client should support an analogous method, with org.jboss.aop.joinpoint.Invocation as the param type.
I'd like to refactor this into a base interface, and then an AOP-based subinterface, with the existing legacy interface also a subinterface. But, can't really do that since the legacy interface is used extensively in EJB3 client code (in @Clustered, in the bean proxy classes, in the cluster interceptor.) Changing the type used there will break older clients.
What I should be able to do is create a subinterface of the existing LoadBalancePolicy adding
public Object chooseTarget (FamilyClusterInfo clusterFamily,
org.jboss.aop.joinpoint.Invocation invocation);
The only place that type would be used would be in the ClusterChooserInterceptor, which could do an instanceof check on the lbp and call the overloaded method if available. That shouldn't break existing clients, since if they have an old version of ClusterChooserInterceptor, they don't have that code.
I'll also deprecate the method with the legacy Invocation class.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4091767#4091767
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4091767
18 years, 6 months
[Design of JBoss Transaction Services] - Re: UserTransaction over iiop
by reverbel
"jhalliday" wrote : I guess we need to distinguish between doing remote (i.e. client side) transaction control for what are really non-distributed tx vs. doing real distributed tx.
|
| The code in question is the former, with an iiop transport. Similarly there is a default UserTransaction implementation that provides client-side control to the JTA (over the old jboss remoting?) For real JTS e.g. using AS with JBossTS JTS, the client side UserTransaction implementation will need to be different.
I don't see why there need to be a difference at the client side. If the OTS context propagation format is used in both cases (non-distributed tx and distributed tx), then what the client-side UserTransaction implementation does in the non-distributed case is the same it would do in the distributed case: obtain an OTS context from the TM, associate it with the current thread, and propagate it along with outgoing requests. The real difference is in the server/TM side.
"jhalliday" wrote : I agree the existing code can be copied back, so long as it's abstracted by some API so we can replace it with a different one when integrating the JBossTS JTS. That may be as simple as registering a different object in JNDI.
The problem with the deleted code is that (at the server-side) it had hard dependencies on JBoss TM classes (XidFactory and TransactionImpl).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4091746#4091746
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4091746
18 years, 6 months
[Design of POJO Server] - Getting runtime component name from attachment
by alesj
Is there a better way of doing this:
| public class BasicMetaDataNameProvider implements MetaDataNameProvider
| {
| public Object getRuntimeComponentName(Serializable attachment)
| {
| if (attachment instanceof BeanMetaData)
| {
| BeanMetaData beanMetaData = (BeanMetaData)attachment;
| return beanMetaData.getName();
| }
| else if (attachment instanceof ServiceMetaData)
| {
| ServiceMetaData serviceMetaData = (ServiceMetaData)attachment;
| return serviceMetaData.getObjectName().getCanonicalName();
| }
| throw new IllegalArgumentException("Cannot handle attachment of type: " + attachment.getClass());
| }
| }
|
Since I quickly stumbled upon this:
| java.lang.IllegalArgumentException: Cannot handle attachment of type: class org.jboss.resource.metadata.mcf.LocalDataSourceDeploymentMetaData
| at org.jboss.profileservice.management.BasicMetaDataNameProvider.getRuntimeComponentName(BasicMetaDataNameProvider.java:49)
| at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.dispatch(KernelBusRuntimeComponentDispatcher.java:52)
| at org.jboss.profileservice.management.ManagementViewImpl.updateComponent(ManagementViewImpl.java:659)
|
And by looking at LocalDataSourceDeploymentMetaData, I didn't see anything that would resemble some component's name.
Only if I pulled out what is under its jndi name?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4091698#4091698
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4091698
18 years, 6 months
[Design of JBoss Transaction Services] - Integration of different tx manager with AS (and EAP) build+
by jhalliday
By default the app server has a JTA implementation i.e. transactions don't span multiple JVMs. There is a limited ability to do remote (client side) demarcation of transaction boundaries, but it's transport dependent. Full, interoperable distributed transactions over IIOP are available by plugging in JBossTS JTS.
Up to now the AS+JTS configuration been a second class citizen in terms of test coverage. However, it's going to be a supported part of the next enterprise platform, so I've been thinking about how to test the AS in that configuration. Some of the AS testsuite does not make sense, since there is no ORB in the default configuration. It should be possible to run those tests using the JTS code i.e. .jar files, configured for JTA mode operation (different property file). The tests for the all configuration are still valid, but there is no automatic way to build and test the server with the JTS rather than JTA.
The general form of this question is: how to make the AS build and test process support a pluggable transaction manager. Pluggability is there at the API level, and getting there with respect to the testsuite code itself. However, the automated build+test process does not reflect it. It would be great to be able to inject an arbitrary implementation of the transaction-spi through build time configuration file and have it pulled in from a repository, have the app server built with it and have the tests run using it.
That's probably going to need hooks in the build system though, since only the transaction system implementation knows e.g. what jar files need to go where, what config files need to go into each AS profile and so on. Right now that information is hardcoded into the AS build scripts and supports only JBossTS JTA. We can hardcod the JjBossTS JTS too, or look at ways to generalize the build process. That may apply to other pluggable components too e.g. pull in another WS stack or messaging bus at build time. Basically anything which is a pluggable component of the AS i.e. has an SPI defined for it.
Any thoughts from the AS team?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4091694#4091694
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4091694
18 years, 6 months