New ClassPool sub-project; structure

[alesj]

I did a quick look at the jboss-classpool.
- http://anonsvn.jboss.org/repos/jbossas/projects/jboss-classpool/
It looks like a big mess. :-)

I don't know enough about how it's actually implemented,
to properly say what should be spi.

But from what I saw, there is a lot of impl details that can be properly moved/hidden.

e.g.
Lets at least properly expose API - the code the user should touch,
everything else should be plugins == impl details, something user can only touch at his own risk.

If there is some spi, I guess you can re-factor that as well,
but I must say I don't see a lot of interfaces that would be really intended to help the dev change the behavior.
They are mostly there to have good abstraction over the impl.

Perhaps you could also join in together the code for 4.x and 5.x:
* jboss4, ucl --> jboss4/pool, jboss4/cl
* jboss5, jbosscl --> jboss5/pool, jboss5/cl
Or whatever you feel fits pool and cl better.
e.g. cl could be called structure

And I guess we can do some simple "cleanup" of root org.jboss.classpool package.
e.g. some split into pool, resource-plugins, strategy, ...

[flavia.rainone]

That's exactly the type of work I'm going to do during this week, Ales.

The first phasis of the work consisted in "having something running" and of course, I didn't bothered looking into package names and the like. I copied the package names from JBoss AOP's original integration project.

I agree with moving things away from package classpool. I'll do an initial cleanup first and then I'll let you know when this initial cleanup is done, so we can discuss my questions regarding the spi.

[alesj]

then I'll let you know when this initial cleanup is done, so we can discuss my questions regarding the spi.

OK, questions I can answer, code I cannot look/understand. :-)

[alesj]

spi - functional split of the actual module architecture

e.g. see MC's Dependency module in Kernel sub-project.

The spi pieces are Controller, ControllerContext, DependencyInfo, DependencyItem, ...
Where the impl is AbstractController, AbstractControllerContext, ...
Where everything external (and even internal) should simply "talk" to spi, meaning the actual impl can be changed at any time.

api - what users can "touch"

It doesn't matter how you split these classes,
as long as you're able to keep them unchanged as long as possible.

impl/plugins - everything else :-)

I don't know how much of classpool you can convert to spi,
give it some thought and whatever you come up with it's fine by me.

But you should focus on api, so it's easy to use classpool from Reflect, AS, ...

[flavia.rainone]

The main problem with working with classpools is that there is no interface: classpools are classes.

I have moved the classes that form the basic architecture to a org.jboss.classpool.spi package, but classes that don't belong to that package have references to package-protected constructors of the spi classes. Ales, how would you handle that? Is there a trick to workaround that or I'll have to make those constructors public?

[alesj]

What's the reason those are package-protected ctors?

Perhaps you can extract some (abstract) super classes from those
who access those pckg-prot ctors / methods and place them in the spi pckg.
Or all of them can be spi, and only have proper api to expose them - via some factory.

The bottom point is that there is no magic bullet.
Only common sense and logic. :-)

[flavia.rainone]

Ales,

I think I have solved the protected constructor issue the best I could, using common sense.

Could you please take a look at the current package structure of the class pool project?
http://anonsvn.jboss.org/repos/jbossas/projects/jboss-classpool/trunk/src/main/java/org/jboss/classpool/

I have placed only 4 classes in the spi:
- AbstractClassPool: an abstract subclass of javassist.scopedpool.ScopedClassPool that is super class common to all classpool subclasses in the project
- AbstractClassPoolFactory: an implementation of javassist.scopedpool.ScopedClassPoolFactory that is the super class of all classpoolfactories in the project
- ClassPoolRepository: extends javassist.scopedpool.ScopedClassPoolRepository and contains the entry point of the project:

ClassPool ClassPoolRepository.registerClassLoader(ClassLoader)

In order to use the repository, you must first configure the factory by calling

ClassPoolRepository.setClassPoolFactory(ScopedClassPoolFactory factory)

It is at this point where you decide which one of the several factories you want to use.
- ClassPoolRepositoryCallback: a callback interface so you can be notified when a classloader is registered and unregistered

Now, according to your classification:

spi - functional split of the actual module architecture

e.g. see MC's Dependency module in Kernel sub-project.

The spi pieces are Controller, ControllerContext, DependencyInfo, DependencyItem, ...
Where the impl is AbstractController, AbstractControllerContext, ...
Where everything external (and even internal) should simply "talk" to spi, meaning the actual impl can be changed at any time.

api - what users can "touch"

I think I should create an api package containing:
- ClassPoolRepository
- ClassPoolRepositoryCallback
And, then, AbstractClassPool and AbstsractClassPoolFactory would the spi. What do you think?
Or, maybe, when you say "functional split of the actual module architecture", you would like to include more classes, such as the classes that are currently part of org.jboss.classpool.base package?