[modeler] removing deps ?

[Costin Manolache <cm...@yahoo.com>]

It would be reasonably easy to remove the deps of modeler on
digester ( use DOM or SAX directly instead ) and beanutils (
 we use only a a very small piece ). 
Our use of introspection will not be exposed to the user and 
we have some very specific requirements ( as mandated by the spec ),
so there's little benefit of using the general purpose beanutils - 
quite the contrary. 

Modeler is a very critical piece - it needs to be in the parent
loader ( if we want to control tomcat or other apps via JMX and 
modeler ), and it'll be critical for security. The fewer public
APIs it exposes ( besides JMX ) and the fewer classes it drags into
the same protection domain - the better it is.

We'll not "duplicate" anything - the code to do what we need 
already exists ( in several forms ), we'll just use it ( adapted
to the specific needs ). I don't think it'll be a problem with
the duplicated maintainance either - the code we need has been
quite stable for a long time and I think people working and using
the modeler have enough experience to do maintain this code.

Craig ? Remy ? Other people who are interested in modeler ? 

Costin





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [modeler] removing deps ?

[robert burrell donkin <ro...@AlmostHuman.com>]

On Monday, December 9, 2002, at 10:38 PM, Costin Manolache wrote:

> robert burrell donkin wrote:

<snip>

>> the reflection code - on the other hand - has proved buggy and unstable.
>> (the problem is that the reflection code in java 1.3 doesn't work very
>> well.)
>
> I'm not sure what exactly you have in mind ( as problems with reflection 
> ).

getMethod (for example) doesn't work properly in java 1.3 JVMs (and 
possible others). this is (said to be) pretty much fixed in java 1.4.

> I'm familiar with the code in ant and tomcat - and I don't remeber any
> serious problem that would affect modeler. I plan to use one of those 2 -
> and most of the "leg work" is already done.

the problems seem to arise when people start wanting to do slightly 
unusual things which are ok in compiled code. for example, public methods 
in a public subclass of a default access superclass can't be accessed when 
found by getMethod. (i can probably look up some more examples, if you 
like.)

- robert


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [modeler] removing deps ?

[Costin Manolache <cm...@yahoo.com>]

robert burrell donkin wrote:

>> We'll not "duplicate" anything - the code to do what we need
>> already exists ( in several forms ), we'll just use it ( adapted
>> to the specific needs ). I don't think it'll be a problem with
>> the duplicated maintainance either - the code we need has been
>> quite stable for a long time and I think people working and using
>> the modeler have enough experience to do maintain this code.
> 
> since when has it been a question of experience? it's just the amount of
> leg work required.
> 
> FYI
> 
> the introspection code has been stable for some time.
> 
> the reflection code - on the other hand - has proved buggy and unstable.
> (the problem is that the reflection code in java 1.3 doesn't work very
> well.)

I'm not sure what exactly you have in mind ( as problems with reflection ).

I'm familiar with the code in ant and tomcat - and I don't remeber any 
serious problem that would affect modeler. I plan to use one of those 2 - 
and most of the "leg work" is already done.


Costin



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [modeler] removing deps ?

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Sunday, December 8, 2002, at 07:09 AM, Costin Manolache wrote:

<snip>

> We'll not "duplicate" anything - the code to do what we need
> already exists ( in several forms ), we'll just use it ( adapted
> to the specific needs ). I don't think it'll be a problem with
> the duplicated maintainance either - the code we need has been
> quite stable for a long time and I think people working and using
> the modeler have enough experience to do maintain this code.

since when has it been a question of experience? it's just the amount of 
leg work required.

FYI

the introspection code has been stable for some time.

the reflection code - on the other hand - has proved buggy and unstable. 
(the problem is that the reflection code in java 1.3 doesn't work very 
well.)

- robert


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>