Hi,

Detailed answers inline, but broadly.

Doing 1) is a good idea.

I don't think that 2) is a good idea, but might be convinced by a large 
cross-cutting problem.

3) is worth a discussion if you think you really need it.

Regards,

Tim 

----------------------------------------
> From: [email protected]
> Subject: too much weaving
> Date: Sun, 12 Jun 2011 14:24:49 -0700
> To: [email protected]
>
> In a compliant ee container the spec classes can't have added interfaces or 
> methods. The weaving code is adding them.
>
> Would it be appropriate to exclude all javax.* classes from weaving?

I have no problem with that, we already avoid everything from the base VM 
(because of the way WeavingHooks work) and "javax" is already a bit of a 
special case in Java. 


> Also, would it be practical and/or appropriate to exclude throwables from 
> weaving? I haven't thought of a reason why you'd want to do aop or proxy an 
> exception.

This could be done without much difficulty but I'm not sure why we would 
special case it. People do some strange stuff sometimes and I'd rather not 
block an entire
class of object from proxying. My view is that things should be woven unless 
there is a good reason not to, rather than the other way around.


> Otherwise, would it be appropriate to make the list of packages excluded from 
> weaving configurable?

We did wonder about this initially when implementing. It would be practical to 
add a "Censor" interface that could be added via a fragment (much like 
extending the JPA container is possible). This would get an opportunity to 
respond through a call to:

public boolean shouldWeave(Bundle b, String className)

The main thing that held us back was that a poorly written implementation could 
break proxying in unpleasant ways (for example by only letting us weave half 
way up a hierarchy). The code also needs to be highly performant and 
threadsafe. Given that we had no requirement for extensible filtering at the 
time it seemed best to avoid it. I'm happy to have a discussion on the list if 
you want.

> thanks
> david jencks
>
                                          

Reply via email to