[jboss-dev-forums] [JBoss Microcontainer Development] - Re: New ClassPool sub-project; structure

[flavia.rainone@jboss.com]

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:
anonymous wrote : 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?


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252130#4252130

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252130