-
1. Re: New ClassPool sub-project; structure
flavia.rainone Aug 3, 2009 10:09 AM (in response to alesj)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. -
2. Re: New ClassPool sub-project; structure
alesj Aug 3, 2009 10:19 AM (in response to alesj)"flavia.rainone@jboss.com" wrote:
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. :-) -
3. Re: New ClassPool sub-project; structure
alesj Aug 7, 2009 11:32 AM (in response to 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, ... -
4. Re: New ClassPool sub-project; structure
flavia.rainone Aug 14, 2009 8:48 AM (in response to alesj)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? -
5. Re: New ClassPool sub-project; structure
alesj Aug 16, 2009 6:38 AM (in response to 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. :-) -
6. Re: New ClassPool sub-project; structure
flavia.rainone Aug 27, 2009 3:33 PM (in response to alesj)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 callingClassPoolRepository.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?