Davanum Srinivas wrote:

> Costin,
> 
> Am +1 on fewer dependencies...Yes, i am writing a small program for
> "register the mbeans, introspection it and write the descriptor". That's
> when i found the missing constructor info.

I don't know if you noticed the small ant task that writes the .ser
descriptors ? It may help.

> #1 - Can you please review the fixes that i checked in yesterday? (one for
> #constructors and
> another for javabeans/additional-java-types).

I'm extremely busy - hopefully in few weeks I'll have more time and I can
help more. The fixes seemed ok.

> #2 - Currently MbeansDescriptorsIntrospectionSource does not do anything
> #for notifications. Does
> it need to? Is there some standard pattern to look for - for
> notifications?

I don't know any good pattern - I was thinking at some point to use the 
java bean event/listener patterns ( addXXXListener() -> XXX notification )
and do some conversion between the 2 event models. But it seems too
complicated and I'm not sure people should use the old event model with
JMX.

If you have any idea - it would be great to add some support. 

> #3 - Should we mark digester as optional in build/docs?

+1

I think we can even remove the dependency completely - the main reason to
keep it was a backup, in case something doesn't work with the new code.

Again - digester is a great tool, but for modeler I think it is better to 
use DOM. 

Cotin

> 
> Thanks,
> dims
> 
> --- Costin Manolache <[EMAIL PROTECTED]> wrote:
>> Craig R. McClanahan wrote:
>> 
>> >> If i hear you right...If the Java class is a well behaved JavaBean
>> >> then we should not need a mbeans-descriptor.xml. Right?
>> > 
>> > Not exactly.  I think you still want a place define the metadata
>> > information about your managed bean -- in the same way that BeanInfo
>> > lets
>> > you supply that externally about a standard JavaBean.  We can probably
>> > figure out ways to synthesize default metadata if there is no
>> > descriptor.
>> > 
>> > My comment was really directed at why the class you are proposing a
>> > patch
>> > for exists in the first place.  The original version of Modeler used
>> > Commons Digester to parse the descriptor file, and Digester can already
>> > deal with the sorts of conversions you are patching to achieve -- plus
>> > a
>> > whole bunch more.  But Costin decided he didn't like it, so he
>> > abstracted out a mini-Digester (with fewer features, but probably a
>> > little faster and smaller), which you're now left with having to patch
>> > to get back to where we already were.
>> 
>> I made a proposal, nobody -1 - so I did it :-)
>> 
>> Faster wasn't the only goal - but also fewer dependencies, so modeler can
>> be placed in the parent loader and it's smaller.
>> Also ability to use different sources for metadata - like introspection (
>> to allow modeler to be used without a mbeans-desriptors.xml for the
>> simple use cases ), or .ser files which seem much faster than parsing
>> xml.
>>  
>> 
>> >> That was exactly my point :) I want to use modeler in axis and was
>> >> wondering if i really needed the mbeans-descriptor.xml files.
>> 
>> IMO - no, you don't need it.
>> 
>> But it's good to use it to associate descriptions with
>> attributes/operation or to support more complex types and operations.
>> 
>> 
>> >> Of course if the tool can generate a sample mbeans-descriptor.xml
>> >> given a set of java classes then folks can edit it to their hearts
>> >> content.
>> 
>> I think that should be easy to do, just register the mbeans,
>> introspection will be automatically used to extract metadata and all you
>> have to do is write the descriptor.
>> 
>> Costin
>> 
>> >>
>> >> BTW, can someone commit my patch? or shall i go ahead and commit them?
>> >> (fixes for both JavaBean params and extend the list of supported types
>> >> to include everything mentioned in the "open mbeans" spec)
>> >>
>> >> -- dims
>> >>
>> > 
>> > Craig
>> > 
>> > 
>> >> --- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
>> >> >
>> >> >
>> >> > On Mon, 21 Jul 2003, Costin Manolache wrote:
>> >> >
>> >> > > Date: Mon, 21 Jul 2003 22:28:45 -0700 (PDT)
>> >> > > From: Costin Manolache <[EMAIL PROTECTED]>
>> >> > > Reply-To: Jakarta Commons Developers List
>> >> > > <[EMAIL PROTECTED]> To: Davanum Srinivas
>> >> > > <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED]
>> >> > > Subject: Re: [modeler] Introspection only for primitives?
>> >> > >
>> >> > > On Mon, 21 Jul 2003, Davanum Srinivas wrote:
>> >> > >
>> >> > > > Costin,
>> >> > > >
>> >> > > > Right now modeler just allows parameters that are listed in the
>> >> > > > supportedType method when we
>> >> > use
>> >> > > > introspection.
>> >> > > >
>> >> > > > #1 - How difficult/easy is it to allow other data types? (Why is
>> >> > > > #this list of items
>> >> > limited?)
>> >> > >
>> >> > > It's not difficult to add more data types. We added mostly commont
>> >> > > types - I think we should cover at least the types in "open
>> >> > > mbeans" part of the spec.
>> >> > >
>> >> > > We could also add a generic mechanism to allow pluggable types (
>> >> > > i.e. to add more types to the list of supportedTypes ).
>> >> > >
>> >> > >
>> >> > > > #2 - How about other beans as parameters? (if you look at
>> >> > > > test\org\apache\commons\modeler\demo\mbeans-descriptors.xml,
>> >> > > > StandardServer has addService, removeService etc that take in a
>> >> > > > service as parameter)
>> >> > >
>> >> > > Sure - if it doesn't complicates things too much.
>> >> > >
>> >> > > BTW, one of the reason we have the "supportedTypes" is to avoid
>> >> > > introspection extracting too much stuff.
>> >> > >
>> >> >
>> >> > If you're using tools that rely on standard JavaBeans introspection,
>> >> > the classic mechanism to hide things you don't want seen is
>> >> > BeanInfo.
>> >> >
>> >> > Of course, the ultimate end of this whole line of "I have to parse
>> >> > my own configuration files" is that you are going to basically
>> >> > re-invent what Digester already does, and does well, but do it in a
>> >> > context that is local
>> >> > to commons-modeler.  Tell me again why depending on something that
>> >> > already works is such a bad thing :-).
>> >> >
>> >> > >
>> >> > > Costin
>> >> >
>> >> > Craig
>> >> >
>> >> >
---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >> >
>> >>
>> >>
>> >> =====
>> >> Davanum Srinivas - http://webservices.apache.org/~dims/
>> >>
>> >> __________________________________
>> >> Do you Yahoo!?
>> >> The New Yahoo! Search - Faster. Easier. Bingo.
>> >> http://search.yahoo.com
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >>
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
> 
> 
> =====
> Davanum Srinivas - http://webservices.apache.org/~dims/
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to