-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
This is most definitely true in any situation - but final is an issue one way or another (just not my issue any longer).
James Carman wrote: | If we silently ignore final methods, couldn't that cause a problem if there | are interceptors added to the service? The final methods would not be able | to be intercepted. | | -----Original Message----- | From: Hensley, Richard [mailto:[EMAIL PROTECTED] | Sent: Tuesday, May 10, 2005 3:24 PM | To: [email protected] | Subject: RE: Non-interface beans | | | Brian, | | Correct me if I'm wrong, it sounds like your patch does a "fallback" to | primitive when singleton does not work? Seems the feature you need is | already in Hivemind in the form of the primitive model. | | Richard | | -----Original Message----- | From: Brian K. Wallace [mailto:[EMAIL PROTECTED] | Sent: Tuesday, May 10, 2005 12:15 PM | To: [email protected] | Subject: Re: Non-interface beans | | I remember the 'implementation vs. interface' discussion well and at the | time I was opposed to anything that dealt with implementations only. This | was living in a world where I was able to define - or at least use | - interfaces for pretty much everything I did. In stepping outside that | arena, I've found one of the idiosyncracies that I just love about Sun - | "use interfaces. and do as we say, not as we do". Not quite sure how hard it | would have been to have base components in the Swing/AWT library implement | *something*, but they don't. So here I am. | | My first foray into this dealt with simply configuring a GUI in Hivemind. | That failed with the problem mentioned in this thread. I wanted to fix it, | but decided to go another way and base my configuration on builders and | factories - it leap frogged my initial reason in trying it (more rapid | prototyping) but if it worked I'd do it. Problem became the number of | 'beans' I had to code inside my class basically negating any configuration | provided outside the code (save implementing everything in code and | utilizing the configuration to switch components on and off - even more | nightmarish). | | I acknowledge this is outside the original intent of Hivemind - but I'm | unable to see why it shouldn't "just work". Ideally, yes - everything would | implement an interface and code massaging wouldn't be a problem. However... | If we're to say we deal in "POJOs" then we must acknowledge that some POJOs | have final methods. I don't have as big a problem with a no-args | constructor, but that's not to say it isn't for the same reason I had no | issue with interfaces - that I just haven't hit that yet. | | All that said... :-/ | | If we're willing to let beans that can't be under Hivemind's influence be | created and used, I've modified a version of SingletonProxyFactory that adds | a try/catch around the classFab.createClass() - failing that returns the | 'declaredInterface', then a try/catch around creating the innerProxy and | then skips the additional steps involved with proxy manipulation if creation | of the innerProxy fails. This allows the test I wrote against this problem | to pass as well as passing all other tests currently in Hivemind's | inventory. | | Perhaps I'm being overly blind to the necessity of this 'special' | circumstance, or perhaps I'm trying to get a square peg to fit in a round | hole. Feel free to tell me which if either. But - aside from losing the | 'lightweight' proxy (perhaps log it so I'd know if needed), I don't see what | allowing this would harm. | | Any thoughts? Anyone? | | Hensley, Richard wrote: | | 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 | reluctant | | 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 [mailto:[EMAIL PROTECTED] | | Sent: Tuesday, May 10, 2005 11:25 AM | | To: [email protected] | | 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: [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)
iD8DBQFCgRFEaCoPKRow/gARAhmQAJ9JDwLLsStw601o7TA/i2/VMxH2LQCfcbqb OOqAgYr6qETanQBxr06YblA= =TN6v -----END PGP SIGNATURE-----
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
