-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
No correction here. You are most definitely correct. My issue was in failing to see I had removed that from my configuration. Issues abound with auto-wiring from that point, but again I believe that to be my issue.
Thanks for pointing that out (again).
Hensley, Richard wrote: | 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]
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32)
iD8DBQFCgREDaCoPKRow/gARAudqAJ448WI7lvRLgT+AmNBAAZxREzhbPQCgtgbr rfqHqJN+v5zMVZu1YWRIZRo= =Rs1l -----END PGP SIGNATURE-----
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
