Mailing-List: contact hivemind-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hivemind-user@jakarta.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <42811144.70701@transmorphix.com>
Date: Tue, 10 May 2005 14:53:40 -0500
From: "Brian K. Wallace" <brian@transmorphix.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: hivemind-user@jakarta.apache.org
Subject: Re: Non-interface beans
References: <001a01c55596$dfd300d0$6601a8c0@carmani600m>
In-Reply-To: <001a01c55596$dfd300d0$6601a8c0@carmani600m>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

-----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:Richard.Hensley@McKesson.com]
| Sent: Tuesday, May 10, 2005 3:24 PM
| To: hivemind-user@jakarta.apache.org
| 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:brian@transmorphix.com]
| Sent: Tuesday, May 10, 2005 12:15 PM
| To: hivemind-user@jakarta.apache.org
| 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:brian@transmorphix.com]
| | Sent: Tuesday, May 10, 2005 11:25 AM
| | To: hivemind-user@jakarta.apache.org
| | 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: hivemind-user-unsubscribe@jakarta.apache.org
| For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
|
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
| For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
|
|
|

- ---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org


- ---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org


- ---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCgRFEaCoPKRow/gARAhmQAJ9JDwLLsStw601o7TA/i2/VMxH2LQCfcbqb
OOqAgYr6qETanQBxr06YblA=
=TN6v
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org