-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Created HIVEMIND-120 and attached the simplest test case I could come up with that still utilizes the same (Swing) classes I was using when I noticed the problem. Not to say it won't work with more basic (bean) classes, but...
Hope that helps.
James Carman wrote: | 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:[EMAIL PROTECTED] | Sent: Monday, May 09, 2005 4:37 AM | To: [email protected] | Subject: Re: Bean Services with a twist | | | 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] | | |
- --------------------------------------------------------------------- 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)
iD8DBQFCf64saCoPKRow/gARAkTVAKDVElduvMe0O67I0UW5fnXfp0yOngCgyQ45 Bips4J+rM0miQnn9wpCDhLc= =Y4Ay -----END PGP SIGNATURE-----
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
