-----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:[EMAIL PROTECTED] | | Sent: Monday, May 09, 2005 7:10 AM | | To: [email protected] | | 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: [EMAIL PROTECTED] | | For additional commands, e-mail: [EMAIL PROTECTED] | | | | | | | | --------------------------------------------------------------------- | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | | | | --------------------------------------------------------------------- | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | |
- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32)
iD8DBQFCfyEpaCoPKRow/gARAqxeAJ9YXYEm+IoDObcLB/fTc42gvL/D8QCdFYp0 GI19lRAlHtjVjS9jBbdoER0= =5ijz -----END PGP SIGNATURE-----
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
