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)
From: "Hensley, Richard" <Richard.Hensley@McKesson.com>
To: hivemind-user@jakarta.apache.org
Message-ID: 
 <B1F6F2DA362BD2118EA30008C75618E30B113B4C@eugexc01ntms.eugalg.hboc.com>
Subject: RE: Non-interface beans
Date: Tue, 10 May 2005 15:23:39 -0400
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

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

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


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

iD8DBQFCgQhPaCoPKRow/gARAg3eAJ0Yt2S3vT5FT98K7kefNX0EkSovhwCeMtYT
Y/bYxNVsQYMjP3uT+aiB8jk=
=zbHL
-----END PGP SIGNATURE-----

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