Weston, you know those JIRA comments go in the release notes.
JIRA should just be a record of what needs doing,
how it was fixed and whether there are any workarounds.
If you need to make a comment do it here in the forums.
Another long standing issue is this:
http://jira.jboss.com/jira/browse/JBREM-236 + linked.
Which Tom still has at low priority.
This has been broken since the 4.0.0 release and Tom wrote the original
but hasn't been supporting it, despite me prodding him to get the
I've got to the point where I tell people this feature doesn't exist.
It is just their imagination. It is fundamentally broken. ;-)
Quick question. I am assuming that we are targeting most of this work, save maybe the aspectized inflow stuff for the 4.x generation. Is this correct? It would seem that we can do most of this stuff in current time frame rather than targeting the 5.0 stuff.
Let me know if I am being stupid.
Everything on this thread should be done in the 4.0.x branch.
As far as the programatic *-ds.xml deployment stuff, I thought following the basic design of the RARDeployer would be a good fit. Basically use JBossXB in conjunction with a new DSDeployer to accomplish what we do for *.rar files now. This new deployer would of course allow for programmatic deployment as well.
New package structure would look something like
As far as the inflow stuff goes, I thought as a 'pseudo' test, and one that can enhance and complete the documentation on the Wiki would be to fully integrate WebSphereMQ with JBoss, filling in the last piece of having an MDB listen to a WebSphereMQ instance. I have the software at my disposal. While this wouldn't go into the testsuite proper, I think it would be a viable solution for 'kicking the tires' of the inflow stuff. Maybe some other issues will shake out.
This would more like as not be down with WebSphereMQ 6.0, seing as this actual supports the latest JMS stuff.
I have seen quite a few people asking for examples of this type of configuration...while I have the patient open, might be worth the day or so to set this up.
Looking into the JBossXB stuff to handle the *-ds.xml deployment. The working model I am using right now, and coding to is the idea of an AbstractConnectionFactoryMetatData which can either represent a ConnectionFactoryMetaData or a DataSourceMetaData. While I am working on this I am operating under the assumption that pooling specifics, transaction specifics etc, etc, can also be expressed generically with the appropriate subtypes
Further, 'aspects' of the pool (criteria), or the connection itself (transaction support) are also generic.
Ideally, it would be interesting to factor out pooling information that has primarily to do with LifeCycle management (size, blocking-timeout, etc, etc) and subtype specific values such as the valid-connection-checker, sql etc, etc.