[jboss-dev] Plain Java IoC : Re: Small boottime improvement

Bill Burke bburke at redhat.com
Wed Feb 17 09:20:46 EST 2010


IoC can be done in plain Java.  Using the MC to manage every nut and 
bolt is just plain ridiculous.

IMO, you will only ever need this flexibility between releases.  You 
will never be asking a customer to change these things.  Therefore, IMO, 
plain Java IoC and delegation are good enough for the majority of the 
ridiculous amount of EJB and Web Services internals that are exposed 
currently within XML scripting.  Coarse grain "wrapper" components will 
both hide complexity from users and boost performance, without 
disrupting flexibility.

For example, when I did Embedded EJB the first time, I created a *very* 
coarse grain bean for datasources that manually created the JCA 
components I needed to deploy.  With this type of wrapper bean, 
configuration is just calling constructors and setter methods.  For 
start/stop you either delegate or manually register with the MC, 
although delegation, IMO, is better.

Carlo de Wolf wrote:
> Although I agree that we have user configuration and internal 
> configuration mixed up in a lot of places, I don't agree on using other 
> IoC constructs to resolve internal concerns. We want flexibility on 
> every level and I would need an IoC construct anyway. So we should be 
> able to use MC for all scenarios and fix the scalability issue where it 
> lies.
> 
> Carlo
> 
> On 02/12/2010 02:34 PM, Dimitris Andreadis wrote:
>> I had seen something similar long time ago when measuring the memory footprint of an MBean,
>> it was quite significant.
>>
>> It would be interesting to measure the memory overhead of a POJO (metadata and all), but as
>> Bill suggest, having more coarse grained POJOs is better than many fine grained ones.
>>
>> Bill Burke wrote:
>>    
>>> Brian Stansberry wrote:
>>>      
>>>>> * How about making our bean.xml files more coarse grain?  Meaning *A
>>>>> LOT* less implementation details exposed through XML.  You can do IoC in
>>>>> Java you know.  The vast majority of details within all our beans.xml
>>>>> files will never ever change, nor will we want to support users changing
>>>>> this stuff.  If our beans.xml file are reduced to a few bean definitions
>>>>> and classes, would make parsing and creating bean metadata much much faster.
>>>>>
>>>>>          
>>>> Semi-related, the ServiceBindingManager config needs a schema and a
>>>> parser. I create a lot of MC beans for SBM, most of which the MC has no
>>>> need to know anything about.
>>>>
>>>>        
>>> EJB and Webservices create an insane amount of beans that can probably
>>> be collapsed into a few beans.
>>>
>>>
>>>      
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>    
> 
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com



More information about the jboss-development mailing list