I agree with pretty much everything you have spelled out. #2 in your con list is an item has been a pain point for me as well. #1 and #3 look like real concerns, but I don't have as much experience in those areas.
As far as a proposed solution, I hope we can do this without tying the API too closely to xbean-finder. I think there are some general EE server issues when too many different components are trying to do their own scans. We should make sure the interface is as pluggable as possible. I'm also not sure what you are proposing with C, is that just package and code cleanup, or a refactoring of the modules as well? Sincerely, Joe On Thu, Jul 21, 2011 at 4:00 PM, Mark Struberg <[email protected]> wrote: > Hi! > > While fixing OWB-593 and readong through OWB-569, I came around a few issues > in the way we do our AnnotatedType handling. It is not basically wrong what > we are currently doing, but it is not perfect neither. > > Historically all of the information needed to be scanned from the classes. > There have been no interface which holds some meta information in the > specification. The AnnotatedType stuff only got introduced with the Extension > mechanism. > > We added this part by introducing a 2nd set of 'MetaData' (see > MetaDataProvider#THIRDPARTY) and switch between those 2 when creation our > Bean<T> instances. > > > PROPOSAL: > > Imo we should get rid of the legacy manual scanning of the metadata directly > from the classes since this has a few cons: > > 1.) with every Class.getDeclaredXxxx we blow up the PermGenSpace since this > space cannot get freed in the ClassLoader. Not in Java <= 1.6 and also not in > JDK-1.7. So this should get reduced. > > 2.) we have 2 completely independent ways to configure beans. This blows up > the code and makes the internal flow unclear. > > 3.) We have problems with 'manually' (per Extensions) registered > Interceptors, Decorators, etc because those can invote addAnnotatedType which > partly gets ignored later. There are still a few issues hidden in the source > which are hard to track down. Thankfully those kind of things get used very > seldom. > > > INSTEAD we should do the following: > > A.) Extend our ClassScanner SPI to deliver the filled AnnotatedType tree. By > moving to xbean-finder (there is currently some work going on to improve this > further) we can get all the infos from there instead of needing to get any > info directly from Class. > > B.) Create the Beans solely based on the AnnotatedType and ditch the > 'default' bean creation (see AbstractBeanCreator#isDefaultMetaDataProvider()) > > C.) cleanup sources. We could reorganize the packages from our historically > grown (non-)structure to a clean separation into the infrastructure and steps > necessary in the container e.g. > utils > scanner > events > deployment > definition > beans > interceptor > decorator > proxy > ... > > and remove unused classes and utilities like the AnnotationUtils. > > Any ideas are highly welcome! > > LieGrue, > strub > > PS: yea, that's a lot of work and we need to do some homework upfront. So > this is more like a 'vision' than a quick issue. We don't need to hurry, but > we should have the same view on our goals. > >
