8:40 p.m.
I was talking to Gavin about this, and he suggested that the discovery
should be more flexible and allow selectors/restrictions to be applied
to the classes discovered (for example, only abstract classes).
I can only speak about JBoss5, but I suspect this approach is common -
JBoss allows you to attach a visitor to the deployer and allows you to
do something with classes it finds (e.g. store them in some data
structure). This happens before web apps (from the Servlet listener)
starts.
The current approach is to discover the resources needed (as defined
by the spec) and store them in a datastructure, which is available
later for querying when we boot the Web Beans RI through the
ServletListener. So, the only way I can see to be more flexible is to
add the ability to apply selectors to the WebBeanDiscovery interface,
and index the classes discovered based on selectors in the jboss-
webbeans integration library. This requires us to define the selectors
we can use. We already have:
* Modifier (for discovering abstract classes)
* TYPE annotations
are there any others we are likely to need - it is better to define
these upfront before we do a release of the WebBeanDiscovery API...
3:29 a.m.
This is trivial to do in JBoss5. ;-)
http://anonsvn.jboss.org/repos/jbossas/projects/webbeans-ri-int/trunk/mic...
module.visit(visitor, ClassFilter.INSTANCE, null, urls.toArray(new
URL[urls.size()]));
You only need to replace this ClassFilter parameter.
e.g. some Javassist based filter --> no need to load the class to inspect it
You could then organize your 'store' accordingly to the filter.
e.g. CombinedFilter(modifier, type, ...) --> push to sub-store
Pete Muir wrote:
7:09 a.m.
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. ;-)
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?
7:14 a.m.
On 26 Nov 2008, at 22:09, Ales Justin wrote:
Ok, I'll try to get some idea e.g. for GF.
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?
11:42 a.m.
Right, it is important that any jboss-specific functionality is abstracted.
On Wed, Nov 26, 2008 at 7:45 AM, Pete Muir <pmuir(a)redhat.com> wrote:
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
10:11 a.m.
Gavin,
I need to better understand the use-cases we are trying to address
here - I've been over this again, and there is no way I can see to
build a flexible class discovery system that performs well without
understanding what sort of conditions/restrictions we want to impose.
So far, I have:
* abstract classes
* non-abstract classes (simple/enterprise beans)
* annotations annotated with the some meta-annotations (e.g.
stereotypes)
What else?
Pete
On 26 Nov 2008, at 17:42, Gavin King wrote:
10:50 a.m.
Let's chat on the phone about it.
On Thu, Dec 4, 2008 at 10:11 AM, Pete Muir <pmuir(a)redhat.com> wrote:
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
5942
days inactive
5951
days old
8 comments
3 participants
participants (3)
-
Ales Justin -
Gavin King -
Pete Muir