hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian K. Wallace" <br...@transmorphix.com>
Subject Bean Services with a twist
Date Sun, 08 May 2005 21:50:41 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As I'm finding it easier and easier to utilize Hivemind at the core of
my applications, I decided I'd try it in an alternate setting -
Utilizing a pre-existing core configured with Hivemind, develop a Swing
client as its UI interface. Right off the bat I found an issue that sent
me back into the archives of this list (and onto the wiki,
documentation, etc).

While I'll admit I didn't see Hivemind used in such a circumstance
previously, I had been looking at Spring's "RCP" to fill the role of
allowing me to configure my clients. Here we are so many months later
and no update on that project except to say "no update". And with my
current usage of Hivemind in so many other circumstances, I figured I'd
see what issues arose from its use in configuring my UI.

Aside from a) creating a new object factory and b) manually configuring
- - is there implement the following configuration in Hivemind?

~  <service-point id="MenuBar" interface="javax.swing.JMenuBar">
~    <create-instance class="menu.CustomMenuBar"/>
~  </service-point>

~  <service-point id="ClientWindow" interface="ClientWindow">
~    <invoke-factory>
~      <construct class="ClientFrame">
~        <int>800</int>
~        <int>600</int>
~        <set property="titlePrefix" value="%client.title.prefix"/>
~        <set property="frameTitle" value="%client.title.default"/>
~      </construct>
~    </invoke-factory>
~    <interceptor service-id="hivemind.LoggingInterceptor"/>
~  </service-point>

Keep in mind "ClientFrame" is a subclass of JFrame with a constructor
taking two ints and JFrames have a method "setJMenuBar(JMenuBar
menubar)". Autowiring of the menubar does attempt, but fails as the
SingletonProxy attempts to override final methods.

Note:  In looking back to January/February messages on "why would you
ever need a 'non-interface'?", my views were "you wouldn't". I think now
that has changed as the amount of work outside the core classes to
either a) access the menu bar prior to it being set or b) creating
object factories simply to return a single object thereby negating ease
of autowire would be negated if a concrete implementation were allowed.

And forgive me if I'm overlooking something simplistic (even if it's
"can't do it").
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCfomxaCoPKRow/gARAi3CAJ9ri2XK9qdM24qr4EMmS0MJSNc0iACfQpwA
O+aH5iBAUq9cDt8eUzvXpSE=
=FncZ
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org


Mime
View raw message