Have your say on new features

[jhalliday]

As we approach the next major project milestone and start planning for the following iterations, it's time to ask the community for input on the plans. Please post any suggestions you have for new features or changes. For my part I'd like to discuss these two:

1) Bean based components, dependency injection and annotations, lifecycle management.

The design of the JBossTS internals pre-dates the current trend towards bean based configuration, injection and such. As a result, we have no dependencies on any DI framework, which allows great flexibility of embedding. On the other hand, it's not as easy as it could be to use JBossTS with a bean-oriented framework such as JBoss MC or Spring.

The forthcoming 4.8 release addresses this to some extent by introducing a set of beans representing the configuration properties, allowing these to be configured by a framework rather than via editing the properties file or setting system properties. However, you still need to do this only at JVM startup, because JBossTS is not amenable to being reconfigured on the fly once it's started up, nor to being partially shut down and restarted within the same JVM.

I'm interested in feedback from users who are employing JBossTS outside of the JBoss application server. Do you use a (bean/DI/lifecycle) framework and if so, which one? Would bean based components for wiring and managing the lifecycle of the system be useful? If you don't currently use a framework, would the dependence of JBossTS on one influence your choice of transaction manager?

2) Build system and build time integration of components.

JBossTS uses an ant based build and additionally publishes the resulting .jar files into the JBoss maven repository. However, because it does not use maven internally, there is no meta-data for the pre-requisites in the resulting pom.xml The pre-reqs we use are all checked into our code repository, except for those needed only for the JBossAS integration, which we find at build time via a JBOSS_HOME environment variable. This allows for largely self-contained, i.e. offline, builds and concurrent support of multiple JBossAS versions. However, it limits the integration of JBossTS into maven based builds. Do you use maven? Would the dependence of JBossTS builds on maven help or hinder you?

[smccauli]

"jhalliday" wrote:

I'm interested in feedback from users who are employing JBossTS outside of the JBoss application server. Do you use a (bean/DI/lifecycle) framework and if so, which one? Would bean based components for wiring and managing the lifecycle of the system be useful? If you don't currently use a framework, would the dependence of JBossTS on one influence your choice of transaction manager?

2) Build system and build time integration of components.
Do you use maven? Would the dependence of JBossTS builds on maven help or hinder you?

In the Kepler mission planet finding pipeline we have many worker processes on many machine. Each worker has a transaction manager. The workers execute science processes written in matlab, collect results and store them in Oracle and a custom time series database. We do not use any kind of container or framework. So it would be good for JBossTS to continue to allow configuration without a framework. It would be nice to have a documentation cheat sheet that listed all the parameters and their functions.

I find maven build files completely incomprehensible. If you move to maven please have some documentation that allows me to build the jbossts jars easily. It's not something I do very often.

Thanks!
Sean

[ben.cotton2]

"jhalliday" wrote:
As a result, we have no dependencies on any DI framework, which allows great flexibility of embedding. On the other hand, it's not as easy as it could be to use JBossTS with a bean-oriented framework such as JBoss MC or Spring.

A best outcome might be achieved if JBossTS can simultaneously

1. remain DI framework independent
2. realize the generic merits that come from DI IoC (via a DI provider that complies with a DI standard)

these may not be mutually exclusive. Both JSR299 and JSR330 address delivering a DI standard. A standard that, essentially, delivers a "dependency independence" capability.

(NOTE: That the DI IoC standard is apparently fragmented within the JCP across two separate JSRs may (or may not) be relevant.)

Do you use a (bean/DI/lifecycle) framework and if so, which one? Would bean based components for wiring and managing the lifecycle of the system be useful? If you don't currently use a framework, would the dependence of JBossTS on one influence your choice of transaction manager?

Yes to all of these. Spring is the framework we have used predominantly, but that is not to in any way suggest that Guice and/or MC are less compelling.

Beyond the question "Do the 2 separate DI JSRs currently fragment the DI standard?" it may be valuable to know which JSR(s) the DI framework providers prioritize implementing. The JBoss MC team has explicitly indicated a priority to implement both JSR299 and JSR330.

Do you use maven? Would the dependence of JBossTS builds on maven help or hinder you?

We are right now Mavenizing all our build projects. Though maven's full capability is largely unfamiliar to many of us, some very smart people have convinced us that mavenizing our build process is both valuable and necessary.