hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject RE: Bean Services with a twist
Date Mon, 09 May 2005 08:51:57 GMT
I saw that in there and meant to put in a test case for it to see what would
happen.  Can you create a JIRA issue for it and I'll fix it?

-----Original Message-----
From: Brian K. Wallace [mailto:brian@transmorphix.com] 
Sent: Monday, May 09, 2005 4:37 AM
To: hivemind-user@jakarta.apache.org
Subject: Re: Bean Services with a twist


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In tracing down this problem, I found two things:
~  1. I can't build head due to test failures
~  2. There's a comment in ProxyBuilder [lines 85 & 86] stating what I
believe to be the root of the issue:
~     // Not exactly certain this will work with non-interface beans that
~ already
~     // are serializable!
~  My guess is it won't.

~  These comments are right before adding 'implements Serializable' to the
outer proxy. Would it not be feasible to put the line
"_classFab.addInterface(Serializable.class);" inside a try/catch and fail
gracefully if there's an error? Without the ability to build I can only view
the code and I'm not a Javassist guru, but it appears as though addition of
the interface might be attempted only after looking to see if it's already
implemented or at least letting an exception pass in this type of case. Note
on my case - the implementation of Serializable is done couple of times on
parent classes up the chain - Component (abstract and Serializable) ->
Container (concrete and not Serializable other than its extension of
Component) -> JComponent (abstract and Serializable) -> JMenuBar (concrete
and not Serializable other than its extension of JComponent) -> My menu bar.
I've made changes to implement Serializable as well as remove and add
SerialVersionUIDs (which are also final) - none with any change in behavior.

Brian K. Wallace wrote:
| I'm guessing I need to keep more up to date. I saw your announcement 
| earlier this morning (lacked a URL so I put it on my back burner of 
| things to look at) but at last look it didn't have anything in the GUI 
| realm. I'll look at that now - however I still view the creation of a 
| bean that subclasses another class (in this instance CustomMenu 
| extends JMenuBar which extends JComponent - JComponent having the 
| final methods) with final methods will be a Hivemind specific problem 
| - I'd just like someone to either clarify or shoot me down on my 
| observation. In any event, you have me looking at HiveGUI now. ;-)  
| Thank you.
|
| Brian
|
| Jean-Francois Poilpret wrote:
| | Hello Brian,
| |
| | If you want to use HiveMind to build a GUI application, you might
| consider
| | taking a look at the HiveGUI module of the HiveMind Utilities 
| | project on SourceForge 
| | (http://sourceforge.net/projects/hivetranse/).
| |
| | Cheers
| |
| |     Jean-Francois
| |
| | -----Original Message-----
| | From: Brian K. Wallace [mailto:brian@transmorphix.com]
| | Sent: Monday, May 09, 2005 7:10 AM
| | To: hivemind-user@jakarta.apache.org
| | Subject: Re: Bean Services with a twist
| |
| | As an aside (or more likely, in direct support of this), I realized 
| | that the problem, while noted with a Swing component, isn't 
| | applicable only to those - trying to override a final method 
| | shouldn't be done in any instance. I haven't investigated further, 
| | but that seemed like a place where the bean creation should be more 
| | aware of 'final'.
| |
| | Brian K. Wallace wrote:
| | | 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").
| |
| | --------------------------------------------------------------------
| | -
| | To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
| | For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
| |
| |
| |
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
| For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
|
|
|
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
| For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
|
|
|

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



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCfyEpaCoPKRow/gARAqxeAJ9YXYEm+IoDObcLB/fTc42gvL/D8QCdFYp0
GI19lRAlHtjVjS9jBbdoER0=
=5ijz
-----END PGP SIGNATURE-----

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



---------------------------------------------------------------------
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