[dmlloyd]

"alesj" wrote:

Is this something that can/should be included with JBossMC?

I see you already have a split - common vs. MC.
I would put the common into commons :-),
e.g. common-threads:
- http://anonsvn.jboss.org/repos/common/threads

Hmm, okay. Come to think of it, this looks like the best home for my log manager too...

"alesj" wrote:
And the MC part into deployers/deployers-impl.
(similar place where I put my -scanning.xml and -dependency.xml metadata)

I'll look these over and see what I need to do to make the threads deployer "fit in"...

"alesj" wrote:

If so, what are the criteria and what is the procedure for inclusion?

The criteria is usage/dependency, e.g. vfs based stuff goes to deployers-vfs.
Procedure is full mavenization (we already have this) + complete test coverage (parsing + actual usage).

I'll have to hit up a maven expert for the mavenization part. And I guess I'll have to read over how your test cases are built and duplicate that - I've had little success developing tests for MC things.

[alesj]

I'll look these over and see what I need to do to make the threads deployer "fit in"...

You just need to find the right parent package to create your 'threads' package.

I'll have to hit up a maven expert for the mavenization part.

No need for this - for the deployers code - since it's all already there.
For commons I would just do a copy/paste with brain involved. :-)

And I guess I'll have to read over how your test cases are built and duplicate that - I've had little success developing tests for MC things.

What was the problem?

There are two (main) test types in Deployers.
One that mocks AS bootstrap, the other one is custom deployers test framework.
In the 1st one, you already have bunch of deployers present and MC as a kernel is already involved.
In the 2nd you build your own VDF framework from scratch, with a lot of hooks to override.

[dmlloyd]

"alesj" wrote:
You just need to find the right parent package to create your 'threads' package.

Oh I see. Integrate the deployer right into the deployers module. Sure, that'll be easy. :-)

"alesj" wrote:
What was the problem?

I could never get a bootstrap off the ground in a useful manner. And I had to move on to other things so I didn't get a chance to figure it out. I've learned more about deployers since then though, so maybe I'll have better luck this time (especially with examples to copy).

[dmlloyd]

One observation about using a corePoolSize of 0. The most obvious reason you'd do this is to prevent a thread pool from having threads hanging around when there are no tasks. However, if you have a non-zero-length queue, then no threads will be started until the queue is full. This means that if the queue is never filled, the tasks will never run.

I think that for this use case, the proper solution, introduced as of JDK6 into ThreadPoolExecutor, is to use a non-zero corePoolSize and enable core thread timeouts.

[dmlloyd]

"alesj" wrote:
...And the MC part into deployers/deployers-impl.
(similar place where I put my -scanning.xml and -dependency.xml metadata)

Is this really the right place for adding a threads deployer? All the deployers that "do stuff" seem to be in deployers-vfs (that's where all the other SchemaResolverDeployers are), but this doesn't really seem like the right place either since they're all related to J2EE deployment unit types for the most part. This project might be the right place but maybe the threads deployer should be its own module? I don't think it fits in in deployers-impl, unless that module is *intended* for such general-purpose deployers and there just doesn't happen to be any yet...

The most similar deployer to the ThreadsMetaData deployer I can think of is the ClassLoadingMetaData deployer, and that project lives completely separately. This suggests to me that perhaps jboss-threads ought to be a separate project after all.

Also, What is there to gain by providing an interface-based view over metadata (like how it's done in org.jboss.deployers.spi.annotations)? I haven't done this in my project - partially because I don't see the benefit, and partially because implementing BeanMetaDataFactory on the root metadata object might complicate things. Am I missing out?