hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian K. Wallace" <>
Subject Re: Non-interface beans
Date Wed, 11 May 2005 07:18:17 GMT
Hash: SHA1

As promised, I am looking at this - however my initial focus itself was
on doing this in 1.1 so my current view is tainted by that focus. A
little background on why I'm confused(?) (not really sure if I'm
confused or back to the square peg - round hold syndrome) about why this
is so... complicated out of the box.

I've been using a home-grown registry builder that didn't rely on
interfaces - matter of fact, it didn't care one way or another about
them. It dealt strictly with "newInstance" so constructors had to be
no-arg at a minimum. Syntax was pretty much:

Client {
~  ClientWindow {
~    @class=com.mypackage.MyClientWindow
~    JMenuBar=ClientMenuBar
~  }

~  ClientMenuBar {
~    @class=com.myotherpackage.MyClientMenuBar
~    Menus=FileMenu, EditMenu, HelpMenu
~  }

~  FileMenu {
~    ...snip
~  }

~  EditMenu {
~    ...snip
~  }

~  HelpMenu {
~    ...snip
~  }

This is pretty dumb registry code - no wrapping, no proxies, no
'auto-wire' - but it works. JMenuBar in the "ClientWindow" configuration
is massaged to be "setJMenuBar" and calls that method with what's
created by the "ClientMenuBar" configuration. Same with "setMenus".
(Obviously it would be more detailed, but that's the gist)  What I love
about it is it's _short_. What I hate is that there's no knowledge of
interfaces what so ever, and there's no concept of 'interceptors'
outside of what the implementations themselves provide.

That's the background I'm running with in wondering why even with
model=primitive (thanks again Richard) it's necessary to cast everything
to an interface [in putting back my 'model=primitive' I realized why I
initially had a problem with it... "client.MenuBar does not implement
javax.swing.JMenuBar" - extends? yes. implements? no. Tried every
variation on a theme for that one and it was always a ClassCast - either
against a parent class (not interface) or a proxy
(java.lang.ClassCastException: $$SimpleMenuBar_103ca990c92_103ca990c93)]
I appreciate the work in writing a component that will "be able to
instantiate any kind of Swing object" and I'm going to keep looking at
it - I'm just at a loss as to why (in my mind) "simple" objects require
a component.

My .01. Saving the other .01 for something other than "Non-interface
beans" :-)

Jean-Francois Poilpret wrote:
| Hello Brian,
| If you need to create beans without interceptors, then the
| hiveutils.ObjectBuilder service that I created in the HiveMind Utilities
| project ( could be useful to you.
| ObjectBuilder allows you to:
| - configure objects to be created (in a quite straightforward xml syntax)
| - declare DI (constructor or setter or mixed) for your objects (you can
| inject anything that can already be injected in HiveMind through the
| "object" translator, ie almost everything you may want)
| - cache objects if you need (configuration attribute)
| - inject such defined objects into other objects, services or
| (thanks to a new ObjectProvider "object:<name>"
| - to pass additional runtime arguments to the constructor at object
| instantiation time
| I have used this stuff a lot in HiveGUI where it is important to:
| - be able to instantiate any kind of Swing objects
| - make it easy to declare lots of objects
| Please note that in its current version (0.4.0) the HiveMind Utilities
| modules only work with HiveMind 1.0.
| Cheers
| 	Jean-Francois
| -----Original Message-----
| From: Hensley, Richard []
| Sent: Wednesday, May 11, 2005 1:46 AM
| To:
| Subject: RE: Non-interface beans
| Brian,
| I ran into a similar problem with the fact that Bean Services must have a
| public no argument constructor. I worked around my issue by using the
| "primitive" model, which just creates the bean. Maybe this could work for
| you and avoid this whole issue. As I recall, bean services were a
| feature added by Howard. I believe the reason he was reluctant is
because of
| all the issues surrounding figuring out a good interface so that
Hivemind is
| happy. I really do not think that hivemind should be changing the model on
| the user, I think it should error out so the user can make a proper
| determination and configuration.
| Richard
| -----Original Message-----
| From: Brian K. Wallace []
| Sent: Tuesday, May 10, 2005 11:25 AM
| To:
| Subject: Non-interface beans
| ~  I've documented this in HIVEMIND-120, but wanted to post this here as
| it appears it is a more fundamental problem than I first saw. At
| present, Hivemind allows me to declare a class as the interface. It then
| proceeds to create the proxies around it and I can use it normally both
| in configuration and code.
| ~  The problem arises when the class (or any of its superclasses)
| implements a "public final" method. The proxy creation fails due to the
| attempt to override a final method, and a quick look at returning simply
| the class, thereby avoiding the proxy issue, causes problems elsewhere
| that expect it to have proxy methods. It would be ideal for the proxy to
| be attempted (unless it were possible to declare it in the configuration
| to be 'real' all the time), but failing that for the reason above just
| create the bean. I'm just not sure where this change would impact to
| avoid problems with missing methods expected to be in the proxy.
| ~  If there is another methodology for doing the same thing with all
| beans (to include those that have final methods), I'd love to hear it.

- ---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:

- ---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:

- ---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:

Version: GnuPG v1.2.5 (MingW32)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message