"adrian(a)jboss.org" wrote : My question was, why do you need to do any complex
visiting/caching when
| the plain old classloading api does the job required.
| i.e. You know the resource path(s) up front so a lookup is more efficient
|
IIRC they have some mechanism to override things
depending on the file/classname.
e.g. FooBar.class --> FooBar.component.xml
Similar to what Hibernate did/does with .hbm.xml.
And since I'm already so 'close' to FooBar class (doing @Name inspection),
why don't I also read overriden xml part (if it exists)?
Instead of remembering which are Seam components,
and then doing CL:findResource lookup for possible override.
Eventually implementing some custom ResourceContext (RC) to generically
read that found resource.
Where I could simply use existing RC with all fancy hooks - getBytes, getInputStream, ...
And afaik they also have a need for other suffix / regexp matching resources,
e.g. -page.xml (or something similar).
This would allow to place resources anywhere in classpath,
making it possible for users to group some stuff.
But in general, thinking about the federated stuff,
I'm surprised it didn't pop-up before.
e.g. doing @annotation read + some other class inspection on the same Module,
while still keeping things separated by what they do, not what they match
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179833#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...