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:
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...
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
6:45 a.m.
Ok - so we would need to wrap this ClassFilter in an equivalent Web
Beans API I think, and then use Javassist as you suggest. Any idea how
portable such an approach will be to other app servers?
On 26 Nov 2008, at 18:29, Ales Justin wrote:
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:
> 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...
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
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:
> 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?
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:
Ok - so we would need to wrap this ClassFilter in an equivalent Web
Beans
API I think, and then use Javassist as you suggest. Any idea how portable
such an approach will be to other app servers?
On 26 Nov 2008, at 18:29, Ales Justin wrote:
> 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:
>>
>> 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...
>> _______________________________________________
>> webbeans-dev mailing list
>> webbeans-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
--
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:
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:
> Ok - so we would need to wrap this ClassFilter in an equivalent Web
> Beans
> API I think, and then use Javassist as you suggest. Any idea how
> portable
> such an approach will be to other app servers?
>
> On 26 Nov 2008, at 18:29, Ales Justin wrote:
>
>> 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:
>>>
>>> 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...
>>> _______________________________________________
>>> webbeans-dev mailing list
>>> webbeans-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>
>> _______________________________________________
>> webbeans-dev mailing list
>> webbeans-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
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,
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:
> 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:
>>
>> Ok - so we would need to wrap this ClassFilter in an equivalent Web Beans
>> API I think, and then use Javassist as you suggest. Any idea how portable
>> such an approach will be to other app servers?
>>
>> On 26 Nov 2008, at 18:29, Ales Justin wrote:
>>
>>> 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:
>>>>
>>>> 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...
>>>> _______________________________________________
>>>> webbeans-dev mailing list
>>>> webbeans-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>>
>>> _______________________________________________
>>> webbeans-dev mailing list
>>> webbeans-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>
>> _______________________________________________
>> webbeans-dev mailing list
>> webbeans-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>
>
>
>
> --
> Gavin King
> gavin.king(a)gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
5891
days inactive
5900
days old
8 comments
3 participants
participants (3)
-
Ales Justin -
Gavin King -
Pete Muir