-
45. Re: migrating TransactionManager and Invokers to POJO
"kabir.khan@jboss.com" wrote:
I could add something to AOP to determine if the instance annotation actually ends up resulting in more aspects (not lifecycle callbacks), and if that is the case return a proxy?
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141314#4141314 -
46. Re: migrating TransactionManager and Invokers to POJO
Adrian
Although http://jira.jboss.com/jira/browse/JBAS-5355 is marked for CR1 it would be very helpful if it was resolved sooner rather than later. I'd like to get the transaction integration changes done in time for CR1 also, but they depends in part on the lifecycle fix. Any chance of you (or anyone else with appropriate knowhow) finding time to look at this in the next couple of weeks? I'd like to be able to resume progress on the transactions integration work after JavaOne i.e. mid-May.
Thanks -
47. Re: migrating TransactionManager and Invokers to POJO
The JMX lifecycle is now tied to the POJO lifecycle.
I've also removed the duplicate invocation of the lifecycle methods
when the POJO doesn't implement ServiceMBeanSupport
(which had been previously hacked to catch the problem). -
48. Re: migrating TransactionManager and Invokers to POJO
Thanks Adrian. The POJO version of the JTA transaction manager now runs fine against AS trunk :-)
BTW, is there a new (injection based?) replacement for things like ServerConfig.SERVER_BIND_ADDRESS or do I need to retain that compile time dependency? -
49. Re: migrating TransactionManager and Invokers to POJO
"jhalliday" wrote:
Thanks Adrian. The POJO version of the JTA transaction manager now runs fine against AS trunk :-)
BTW, is there a new (injection based?) replacement for things like ServerConfig.SERVER_BIND_ADDRESS or do I need to retain that compile time dependency?
The correct way to do this is to inject the value into your bean
then use the system property.<bean name="Whatever"> <property name='bindAddress">${jboss.bind.address}</property> </bean>
The bindAddress property can be either a String or an InetAddress.
If you don't expose it for configuration like this, then nobody can override
it to use some other rule or even hardwire it.
But the default should be our system property. -
50. Re: migrating TransactionManager and Invokers to POJO
OK, so I can do it by injection but I need to retain the compile time dependency anyhow in order to have the correct default. Ah well, I guess I just have to live with an extra .jar in by compile time classpath for now.
The JTS vesion is coming along nicely too, but has hit a snag with ordering events in relation to the ORB startup http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152351 Maybe it's time to POJOize the CorbaORBService too... -
51. Re: migrating TransactionManager and Invokers to POJO
"jhalliday" wrote:
OK, so I can do it by injection but I need to retain the compile time dependency anyhow in order to have the correct default. Ah well, I guess I just have to live with an extra .jar in by compile time classpath for now.
No you don't. You can provide the default in the config, e.g.<property name="bindAddress">${jboss.bind.address:127.0.0.1}</property>
But for the bindAddress, the default is redundant. A long time ago we
fixed it such that the system property was always set during the bootstrap.
See the horrible hack at the top org.jboss.Main ;-)Getopt getopt = new Getopt(programName, args, sopts, lopts); int code; String arg; HERE !!! props.setProperty(ServerConfig.SERVER_BIND_ADDRESS, "127.0.0.1"); System.setProperty(ServerConfig.SERVER_BIND_ADDRESS, "127.0.0.1"); while ((code = getopt.getopt()) != -1) { ... case 'b': arg = getopt.getOptarg(); props.put(ServerConfig.SERVER_BIND_ADDRESS, arg); System.setProperty(ServerConfig.SERVER_BIND_ADDRESS, arg); ... -
52. Re: migrating TransactionManager and Invokers to POJO
OK, so I now have a POJO version of both the JTA and JTS TransactionManager. The next trick will be actually getting it into the app server. I guess I need to do a CR level JBossTS release, since that's where the AS is headed. Once that's published, JBossAS trunk can be changed to consume it. I'd also like to include support for the new crash recovery SPI though, which will mean first doing a new jboss-integration release and putting that into the AS, so that the JBossTS build can use it.
Dimitris, do you have any problem with us doing these updates before AS 5.0 CR1, or do you want to wait until after? -
