hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian K. Wallace" <>
Subject Re: Non-interface beans
Date Tue, 10 May 2005 19:52:35 GMT
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 []
| Sent: Tuesday, May 10, 2005 12:15 PM
| To:
| 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 []
| | Sent: Tuesday, May 10, 2005 11:25 AM
| | To:
| | 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:
| For additional commands, e-mail:
| ---------------------------------------------------------------------
| To unsubscribe, e-mail:
| For additional commands, e-mail:

- ---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:

- ---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:

Version: GnuPG v1.2.5 (MingW32)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message