beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xibin Zeng" <>
Subject Re: Controls "the next generation"
Date Wed, 21 Jun 2006 02:58:54 GMT
Ken -

Excellent points!

Adding my 2 cents here:

I vote for "replacing compile-time code-gen with runtime bytecode gen(asm or
cglib style)". The generated artifacts create problems ranging from
name-clashing (generated PropertySet API, field names) to unexpected
compiler warnings/errors. The control interceptors are wired through
code-gen; perhaps that functionality can also be delegated. (The control
interceptors throw an internal exception to allow the flow to short-circuit
the target call; that seems inefficient.)

I totally agree with "remove or refactor dependency on JavaBeans Runtime
Containment and
Services Protocol specification". The JavaBeans runtime containment
mechanism makes it harder to understand controls. On the positive note, I
think the concept of ServiceProvider and querying/getting a service through
the control bean context is a good one. I hope future versions retain the
ability for control code to dynamically determine its running environment
and services that it can access.

One suggestion is that we could make the control containment requirements a
little more concrete. At a first glance, it is not obvious what needs to be
implemented; the pieces are spread out (ControlContainerContext,
Controls.initializeClient, Controls.instantiate, and PropertyMap).

The control (annotation) properties have a well-defined resolution model and
precedence rule. A future version should maintain the same principle.

Xibin Zeng

On 6/20/06, Kenneth Tam <> wrote:
> I've had a few conversations recently about what kinds of
> changes/improvements might make sense for Beehive controls to make
> them more accessible and usable in light of all the changes that have
> gone on in the Java development world since controls were originally
> designed.  Here are some rough thoughts/ideas I've had; I'll probably
> start exploring some of these ideas in the coming weeks via
> prototyping in a sandbox and post more detailed explanations of what
> I'm thinking.
> Goal:
> Rearchitecture to incorporate support for various contemporary
> container and ease-of-development technologies, and strea
> mline/modularize feature-set based on developer feedback.
> Support strong separation of service provider/consumer concerns
> - continue to expect control implementation authors (service
> providers) to be more highly skilled Java developers than
> consumers.
> - focus more on adding value to consumers, less on making it easier
> for the provider (plenty of other technologies in t
> hat space).
>    - controls _usage_ should continue to be highly toolable
> Key use case is consumers authoring interface extensions for extensible
> controls
> - rich support for provider-defined annotation grammars & associated
> semantics
> - think of controls as making Java dynamic proxies easy &
> annotation/metadata driven.
>   - focus on resource access / smart proxy problem
> De-emphasize nested controls case
> - controls no longer positioned as generic logic containers
> - just write pojos, use other containers and their features
> - limit or refactor eventset support (how important has this been in
> actual usage)?
> Make it easier to use controls from anywhere by reducing/refactoring
> container requirements
> - remove or refactor dependency on JavaBeans Runtime Containment and
> Services Protocol specification (unclear that valu
> e of that framework justifies cost/complexity)
> - consider interop and co-existence with other annotation sets as an
> important use case
>   - JAX-WS
>   - EJB 3
>   - JSR-250
> - consider replacing compile-time code-gen with runtime bytecode gen
> (asm or cglib style)
> - delegate dependency injection/IoC responsibilities; replace
> @Control and @Context
>   - expect developers to use injection container of their choice
>    - Spring
>    - EJB3/JSR-250 (@Resource)
>   - refactor declarative property configuration (usage of @Property
> annotations on fields marked w/ @Control) to make it
> optional (just another source of injection)
>   - pluggable lifecycle support (can we replace ResourceContext?)
>    - JSR-250 (@PostConstruct, @PreDestroy)
> ---
> Would love to hear some comments/feedback, especially about other
> ideas of how controls might be more useful in conjunction with all the
> other Java technologies that have proliferated in the past few years.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message