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:53:40 GMT
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
| are interceptors added to the service?  The final methods would not be
| to be intercepted.
| -----Original Message-----
| From: Hensley, Richard []
| Sent: Tuesday, May 10, 2005 3:24 PM
| To:
| 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 []
| 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
| implement an interface and code massaging wouldn't be a problem.
| If we're to say we deal in "POJOs" then we must acknowledge that some
| 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
| 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:

- ---------------------------------------------------------------------
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