[jboss-dev-forums] [JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor

[jesper.pedersen]

anonymous wrote : 
  | The use case is the example from JIRA issue.
  | 
  | e.g.
  | All our restrictions are held in Module, but that's mostly impl detail.
  | The way we expose that is via proper visitor pattern.
  | 
  | e.g.
  | A user can provide ScanningMetaData on-the-fly,
  | and we should take that in account when:
  | * re-creating old serialized AR
  | * creating AR at runtime
  | 
  | Not to mention resources lookup is *the* use-case where you need to apply visitor pattern. 
  | 

That is a finer grained API than the current API - and some of it will be in a SPI. But this also implies a more dynamic annotation model - which is maybe something for a 1.1 release based on feedback from the community.

anonymous wrote : 
  | That's too simplistic.
  | You should have a proper abstraction. 
  | 

Creating the needed metadata is an assembly time operation - so it only need to be done once. And yes, supporting additional methods of reading existing metadata could benefit the indexer.

anonymous wrote : 
  | I don't like to say this, but I'll still go ahead,
  | Papaki as it's currently in the trunk, is complete re-invent of the wheel.
  | Standalone argument doesn't convince me.
  | 
  | And I spent the whole weekend looking at it and thinking about it how to best integrate it with Deployers,
  | only to realize that complete re-write is what we should do.
  | 
  | Here is my version of it, which can be quite easily integrated with Deployers,
  | plus it uses all of the abstraction that are already under JBoss umbrella:
  | * Reflect -- abstraction between JDK Introspection and Javassist
  | * MDR - simplifying lookup via Signature
  | * VFS - resources lookup abstraction and visitor pattern
  | * ClassLoading - exact class resources visitor pattern
  | 
  | Location: http://anonsvn.jboss.org/repos/jbossas/projects/annotations/branches/AnnEnv/ 
  | 

The goal of Papaki is to provide a simple API for developers and thereby being able to deploy the library in any environment (like one of the current users on WebSphere).

If the current API and scope of the project doesn't fit into the MC project I welcome a fork of the code into a new project where we can share ideas across the projects.

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

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