On 26 Nov 2008, at 22:09, Ales Justin wrote:
> Any idea how portable such an approach will be to other app
servers?
No idea, never looked into details of anything else than ours
truly. ;-)
Ok, I'll try to get some idea e.g. for GF.
So, you're thinking of something like this:
WebBeansDiscovery wbd = ...;
ClassFilter cf = new ModifierClassFilter(ABSTRACT);
Set<Class<?>> abstractClasses = wbd.search(cf)
In the worst case this would be implemented on top of all classes:
WBD impl detail:
public Set<Class<?>> search(ClassFilter cf)
{
Set<Class<?>> result = new HashSet<Class<?>>();
for (Class<?> clazz : allClasses)
{
if (cf.accepts(clazz))
result.add(clazz);
}
// TODO - some cache here
return result;
}
Where we could already easily prepare this info when we do visitor
pattern - performance optimization.
Or what exactly are you trying to do?
Basically, make the discovery of classes more flexible (visitor
pattern is perfect for this) but WB cannot depend on any MC api so we
need to copy the relevant MC API into WB, and then write some
delegation from WB API -> MC API I guess.
I'm pretty knackered so I'm not thinking straight - this is actually a
pretty obvious way to do it. I'll ping you on Monday or Tuesday to
discuss?