Something of a personal belief for me, that HiveMind should just work
through public APIs and not side-step things. Yes, HiveMind could
pretty easily jump in an fiddle with instance variables, it could even
guess the naming convention you use ... but the cost of adding one or
two accessors per class is not what I'd call painful.
On Wed, 03 Nov 2004 21:41:37 +0100, David J. M. Karlsen
<[EMAIL PROTECTED]> wrote:
> James Carman wrote:
>
>
>
> >There may not. We ran into this problem before with the java.lang.String
> >type within a Java Web Start client. There's a bug out there in JIRA for it
> >and I provided the patch which fixed it. My suggestion was to use the
> >commons beanutils classes rather than the property editors, but we want to
> >minimize the dependencies HiveMind has (aside from Javassist, obviously), so
> >we're sticking with the core JDK classes. We basically short-circuited the
> >property editor lookup if the target property type was String (as converting
> >String to String is somewhat trivial). Are you running within a webstart
> >client?
> >
> >
> No - it's running inside a EJB-container.
> Not a big problem as I can do a
>
> public void setSomeprop(int valueProvidedFromHiveMindFW){
> theClassIntegerProp = new Integer(valueProvidedFromHiveMindFW);
> }
>
> BTW: For the automatic-setting to be done - I have to provide
> setPropertyname methods? Do they absolutely have to be public void and
> not not private and/or static?
> HiveMind cannot locate the variables of itself and initialize them?
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
