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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCgQhPaCoPKRow/gARAg3eAJ0Yt2S3vT5FT98K7kefNX0EkSovhwCeMtYT Y/bYxNVsQYMjP3uT+aiB8jk= =zbHL -----END PGP SIGNATURE----- --------------------------------------------------------------------- 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]
