[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor
by alesj
"jesper.pedersen" wrote :
| 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).
|
Sure, but why re-invent the wheel?
* your Reflection vs. Javassist abstraction == JBoss Reflect
* your split between jar or directory == JBoss VFS
e.g. if you wanna add a restriction check (e.g. exclude any non-exported class by OSGi manifest),
you have to do it in 4 diff places:
* Reflect + jar
* Reflect + directory
* Javassist + jar
* Javassist + directory
With VFS this is a simple filter; recursion or plain resource.
Reflection abstraction is a single TypeInfoFactory change; via setter.
"jesper.pedersen" wrote :
| 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.
Yup, that's what I think I'll do.
But I'm still confused by where your version of Papaki really can be used.
As it clearly lacks proper integration layer with existing environments,
be it MC, JBossAS, WebsFear, ...
While building repo, either from existing papaki.ser or runtime, you should be able to hook into existing restriction mechanisms.
Otherwise you can potentially load a bunch of code user restricted at runtime;
jboss-clasloading.xml, jboss-scanning.xml, ...
(and its matching metadata instances)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261288#4261288
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261288
16 years, 5 months
[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor
by jesper.pedersen
anonymous wrote :
| Papaki should actually be more minimal than it is. The indexes should be built by directly examining the file. Think about it - possibly every class in every JAR that is ever deployed may end up being read by this. There is absolutely no way that reflection is going to cut it performance-wise, nor do I think Javassist will suffice.
|
The indexer in Papaki builds an index over where annotations are located within the .class or .jar file. If the indexer is present, but is empty the framework will skip the entire annotation parsing stage. If an index is present, but contains annotation metadata only the part of the .class file where the annotation is located is scanned.
The annotations themself can't be located in the metadata as they are not serializable, but the all the metadata about them can.
Furthermore the scanner can be configured to only scan the part of the classes you are interested in - f.ex. if an annotation only can be located on a public class - at class level - then all non-public classes, all fields, all constructor, all methods and all parameters are skipped.
HTH
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261275#4261275
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261275
16 years, 5 months
[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor
by david.lloyd@jboss.com
So - we are taking a small project, adding dependencies and making it more complex?
Papaki should actually be more minimal than it is. The indexes should be built by directly examining the file. Think about it - possibly every class in every JAR that is ever deployed may end up being read by this. There is absolutely no way that reflection is going to cut it performance-wise, nor do I think Javassist will suffice.
The two key requirements for Papaki are: speed of execution and compactness/efficiency of indexing. If it doesn't hit both of these out of the park, we're going to be taking a step backwards in terms of performance. I don't see why it's anything more than a highly string-optimized map implementation (patricia trie perhaps) plus a tuned byte scanner.
Adding dependencies is a bad idea. Projects should as a rule have the minimum number of runtime dependencies possible. Having lots of dependencies just makes it harder to refactor later. If you have a large web of dependencies between a set of projects, that's a big indicator that they ought to be one big project anyway, or at least split up differently.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261273#4261273
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261273
16 years, 5 months
[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor
by 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
16 years, 5 months