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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development