Long standing issues

[adrian.brock]

Weston, I just assigned a couple of long standing issues
to you. See the linked issues and discussion threads.

The first isn't very important. It basically revolves around
create a DataSource from a java(m)bean deployment
or programmatically.
http://jira.jboss.com/jira/browse/JBAS-1793
The code that already exists is inside the rar.

The second is the most important because it will greatly simplify
the code we have to support for EJB2.1/3 and JBossMQ/JBoss Messsaging
integration.
http://jira.jboss.com/jira/browse/JBAS-1434
On the latter task, I'd prefer it if the jms inflow was based upon
a generic framework for inbound messaging where "aspects" of
the inflow could be plugged in. Leaving the user to just write
some simple definition of what they want to use.

But it is more important to get the jms inbound rar tested and
production ready first.
You can find some basic tests in "messagedriven" in the testsuite.
Each test also has a counterpart test using the old JMSContainerInvoker.
But this needs a lot more tests to cover all the functionality, including
error checking and exceptionlistener handling.

[adrian.brock]

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.

[adrian.brock]

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
issues fixed.

I've got to the point where I tell people this feature doesn't exist.
It is just their imagination. It is fundamentally broken. ;-)

[weston.price]

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.

[adrian.brock]

Everything on this thread should be done in the 4.0.x branch.

[weston.price]

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

org.jboss.resource.ds.deployment
org.jboss.resource.ds.metadata

etc, etc.

[adrian.brock]

Yes

[weston.price]

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.

[weston.price]

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
DataSourceConnectionPoolMetaData
ConnectionFactoryConnectionPoolMetaData

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.