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

[david.lloyd@jboss.com]

"alesj" wrote : "david.lloyd at jboss.com" wrote : 
  |   | Far simpler than designing a plugin mechanism for restrictions is to simplify the API so that you just give it the input streams of classes you want to index.  Simplfying the API is usually preferable to adding an abstraction.
  |   | 
  | A? What kind of nonsense is this?
  | 
  | And how do you plan on providing this streams?
  | Via abstraction!!!!
  | 

No, I'm saying rather than having the scanner pull in the classes, the API consumer pushes the classes into the scanner.  This way you don't have to worry about missing use cases when you design the abstraction.  This way, Papaki is less limited by usage patterns.

Case in point, say Papaki depends on VFS and uses that project's visitor system to scan classes.  Now later on we want to scan classes that are not found on VFS (maybe they're being downloaded).  In this case, tying to VFS was an arbitrary restriction that we pay for later since now all classes have to be wedged in there whether it makes sense or not.  On the other hand, if we push classes in, then both use cases are easily accommodated.

"alesj" wrote : [Or how else are you gonna know which one's should or shouldn't be scanned?
  | Should I list them by hand, all of the 1M classes?
  | Or what about if tomorrow Sun speeds up its modules impl,
  | and we all start doing module-info.java?

This logic would be something that belongs in the module-loading layer (which is currently spread between deployers and classloading as far as I can tell), not in the scanning layer.  The scanning layer does not have semantic awareness of what should or should not be scanned, so there's no reason to push this functionality into it.  Let it do one thing well.

"alesj" wrote : "david.lloyd at jboss.com" wrote : 
  |   | The specifications for many of our components (like EJB 3.1) tell us that we can't rely on this, or at least that's my understanding from the developer meeting when we decided we had to do it this way.
  | Then I would say this is their problem.
  | Who ever doesn't have automated build, has either just started programming or is moro....
  | The first one's don't need this feature yet, the 2nd one's don't deserve it. ;-)
  | 

That's a valid opinion, but it doesn't help us meet the requirements that we have spelled out for us, which include (but are not limited to) performance improvement and complete support for these specs.

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

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