You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Craig R. McClanahan" <cr...@apache.org> on 2001/12/15 22:26:05 UTC
[Design Discussion] DynaBean - JavaBeans with dynamic properties
There's been a lot of interest, both here (COMMONS-DEV), on the Struts
mailing lists, and elsewhere in the idea of a JavaBean-like thing where
the set of properties can be dynamically defined. If support for this was
integrated into the BeanUtils package in Commons, we could also make the
methods in BeanUtils and PropertyUtils treat the properties of these beans
like they do for regular JavaBeans, and thus be able to leverage them in
environments based on BeanUtils (such as Struts).
The purpose of this email is to summarize a set of design requirements for
discussion purposes, so we can coalesce on a design and then get it
implemented. For extra fun, I've thrown in a very-raw idea of what the
APIs might look like -- but I'd like to have the group's agreement before
turning that into code.
Before embarking on the actual development of dynamic beans support, we
should also do a release of BeanUtils with the current enhancements, to
provide a stable starting point.
Please let me know what you think!
BACKGROUND:
The purpose of the DynaBean design (I'm not firmly attached to the name,
but kinda like it :-) is to support application programming designs based
on JavaBeans design patterns, but where the static nature of JavaBeans
themselves (i.e. the fact that the set of properties is fixed at compile
time) is too restrictive. Some typical use cases for such a capability:
* A bean object that represents a Row from a JDBC ResultSet
(the names and types of the column properties cannot be known
in advance because they are based on the SELECT statement).
* A way to construct and use "value objects" that extract the
properties of an EJB into a structure that can be utilized by a
presentation tier technology such as JSP pages, without having
to hand code the value object.
* A way to capture *all* of the request parameters from a servlet
request as a single object.
* A way to dynamically represnt XML input data as a tree of Java objects.
DESIGN REQUIREMENTS:
* Support a completely arbitrary set of properties and corresponding
values, with the ability to add and remove properties dynamically.
* Support the ability to dynamically register the set of property
names that are allowed, and then enforce storing only those
property names.
* Support the ability to register data types (Java classes) for each
property, along with the names, with automatic type checking.
* Support for properties with scalar types, array types, and
"mapped" types (as currently supported in Beanutils).
* Support "simple" and "indexed" property getters and setters
in a style similar to standard JavaBeans.
* Support registration of property change listeners and broadcast
of property change events
* Provide the basic DynaBean API as a Java interface, as well as a
convenience base class, so that applications can adopt it however
they wish.
* Base implementation class should implement Serializable so that
DynaBeans can be serialized and deserialized (assuming that the
actual property values can be).
* Transparently support DynaBean objects in the existing BeanUtils
and PropertyUtils classes of the Bean Utilities package.
* To the maximum extent feasible, provide JavaBeans-like introspection
capabilities of the available properties. May require an
IntrospectionUtils addition to the Beanutils package.
CONCEPTUAL API:
public interface DynaBean {
// ----------------------------------------------------------------
// Dynamic property configuration
// ----------------------------------------------------------------
void addDynamic(String name); // Unrestricted type
void addDynamic(String name, Class type); // Restricted type
void removeDyanamic(String name); // Remove property & value
void restrictDynamic(boolean restrict); // Are property names
// restricted to registered
// ones? (default=false)
// (can be changed)
// ----------------------------------------------------------------
// Property getters and setters. Behavior on previously
// unknown property names depends on the restrict setting
// ----------------------------------------------------------------
// Does this bean have a property of the specified name?
boolean contains(String name);
// Getters return null on unknown property names
Object get(String name); // Simple
Object get(String name, int index); // Indexed
Object get(String name, String key); // Mapped
// Setters are allowed to set null unless property is native.
// Optionally throw IllegalArgumentException if type is restricted
// and the value argument is not assignment-compatible
void set(String name, Object value); // Simple
void set(String name, int index, // Indexed
Object value);
void set(String name, String key, // Mapped
}
Craig McClanahan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Posted by Incze Lajos <in...@mail.matav.hu>.
On Mon, Dec 17, 2001 at 08:38:36AM -0700, Bryan Field-Elliot wrote:
> My main point, Craig, is that it seems a bummer that we continue to
> develop frameworks in Java which steer the developer further and further
> away from the benefits of compile-time checking, and more and more
> towards activities which take a String as a runtime parameter in order
> to describe the intended behavior. My opinion is that there's a
> messiness and error-proneness that it introduces, which wouldn't be
> there with old-fashioned, fully compliation-time checked code. But
> perhaps this isn't the place to discuss it, as everyone here has too
> much vested in what's been built.
>
> Bryan
>
This is unavoidable whenever your system interfaces with other type
systems - be it a user interface or a sql database or whatsoever.
Servlet environment was not designed from the ground up and had to
be interfaced to a working world. http parameters come in as strings
database result sets com in as sql datatypes, etc.: you have to feed them
and transform to java types. However, your application model cab fully
enjoy the advances of compile time type checking.
incze
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Posted by Bryan Field-Elliot <br...@netmeme.org>.
My main point, Craig, is that it seems a bummer that we continue to
develop frameworks in Java which steer the developer further and further
away from the benefits of compile-time checking, and more and more
towards activities which take a String as a runtime parameter in order
to describe the intended behavior. My opinion is that there's a
messiness and error-proneness that it introduces, which wouldn't be
there with old-fashioned, fully compliation-time checked code. But
perhaps this isn't the place to discuss it, as everyone here has too
much vested in what's been built.
Bryan
Re: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On 15 Dec 2001, Bryan Field-Elliot wrote:
> Date: 15 Dec 2001 15:21:05 -0700
> From: Bryan Field-Elliot <br...@netmeme.org>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [Design Discussion] DynaBean - JavaBeans with dynamic
> properties
>
> It seems to me that Java was built from the start to be strongly-typed
> and compilation-centered. This follows in the strong tradition of C++
> and C.
>
> In contrast, languages such as Python (over which I am admittedly
> intruiged, but definitely no expert) are weakly-typed, and
> scripting-centered.
>
> Recently, the Java community has taken steps to move away from those
> core principles of Java -- in terms of moving away from being
> compilation centered, we have mechanisms like JSP, whichs seems to be an
> extremely complex layer on top of classical Java just to achieve that
> "dynamicness" (can anyone say that the Catalina JSP effort was trivial
> or obvious)?
>
It's somewhat amusing to note that the reflection APIs in Java (which IMHO
is just as much a distringuishing factor as anything else) have been
around just as long as the JavaBeans design patterns have. It's hardly
"revolutionary" to leverage such capabilities in web apps, when it has
been used to very good effect in GUI apps and tools for a *long* time.
I'm not quite sure I understand your point about the "Catalina JSP
effort", but (being one of the core Tomcat developers) I'm interested in
hearing more about how you think it's applicable to this discussion.
> Now we are groping with limitations in strongly-typed development,
> coming up with things like the DynaBean. Again, we are introducing
> layers on top of classical Java in order to achieve development patterns
> not compatible with Java's original design principles (strong typing).
>
> It seems to me that if good patterns in web app design require these
> language traits, then perhaps the choice of language itself needs to be
> re-evaluated?
>
> Or, on the other hand, perhaps these design patterns need to be
> re-evaluated (e.g. do we really need a Dynamic Bean?), and instead, come
> up with new design patterns for web app development which are not only
> compatible with, but greatly benefit from, the language being
> strongly-typed.
>
Seems to me we already have that. What I want to support, and what Struts
(I'm also the primary author of Struts <http://jakarta.apache.org/struts>)
have wanted for a long time, is the abillity to go beyond static typing
for certain use cases *without* having to throw away everything they
already have learned and built. Fortunately, Java accomodates that for us
quite nicely.
> Perhaps I'm over the top here. I'm really just trying to stir up a
> little discussion. But it seems to me that JSP, and now the DynaBean,
> represent a whole lot of work to try to hammer a square peg through a
> round hole.
>
> Thoughts and discussion appreciated,
>
The discussion ought to be interesting!
> Bryan
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Posted by Bryan Field-Elliot <br...@netmeme.org>.
It seems to me that Java was built from the start to be strongly-typed
and compilation-centered. This follows in the strong tradition of C++
and C.
In contrast, languages such as Python (over which I am admittedly
intruiged, but definitely no expert) are weakly-typed, and
scripting-centered.
Recently, the Java community has taken steps to move away from those
core principles of Java -- in terms of moving away from being
compilation centered, we have mechanisms like JSP, whichs seems to be an
extremely complex layer on top of classical Java just to achieve that
"dynamicness" (can anyone say that the Catalina JSP effort was trivial
or obvious)?
Now we are groping with limitations in strongly-typed development,
coming up with things like the DynaBean. Again, we are introducing
layers on top of classical Java in order to achieve development patterns
not compatible with Java's original design principles (strong typing).
It seems to me that if good patterns in web app design require these
language traits, then perhaps the choice of language itself needs to be
re-evaluated?
Or, on the other hand, perhaps these design patterns need to be
re-evaluated (e.g. do we really need a Dynamic Bean?), and instead, come
up with new design patterns for web app development which are not only
compatible with, but greatly benefit from, the language being
strongly-typed.
Perhaps I'm over the top here. I'm really just trying to stir up a
little discussion. But it seems to me that JSP, and now the DynaBean,
represent a whole lot of work to try to hammer a square peg through a
round hole.
Thoughts and discussion appreciated,
Bryan
Re: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On 15 Dec 2001, Bryan Field-Elliot wrote:
> Date: 15 Dec 2001 14:49:30 -0700
> From: Bryan Field-Elliot <br...@netmeme.org>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [Design Discussion] DynaBean - JavaBeans with dynamic
> properties
>
> This is good stuff, and definitely needed in Java.
>
> One question I have is, (and I don't believe you address it in your
> overview), will the resulting DynaBean be a real Java class, or will it
> instead be something like a property set or hashmap (albeit a more
> intelligent one than those provided by the JDK)?
>
> I assume you are leaning towards a generic class which acts as a "super
> smart property set", and not the "real Java class generation" approach.
> However it would make sense to point this out explicitly in your
> functional overview, given that the "real class" is what people expect
> when they think "JavaBeans".
>
> Bryan
>
>
I anticipate that many people will simply use the provided base class
(DynaBeanBase) that implements all of the specified functionality in a
generic way). It is also straightforward to subclass DynaBeanBase if you
wanted to add some additional functionality -- such as a way to configure
the default set of properties that the bean supports), or to facilitate
existing logic that is used to using "instanceof" checks to tell if two
arbitrary beans are assignment-compatible or not.
A smaller number of advanced users will add DynaBean functionality to
their existing classes. This is the reason for proposing DynaBean itself
as an interface.
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Posted by Bryan Field-Elliot <br...@netmeme.org>.
This is good stuff, and definitely needed in Java.
One question I have is, (and I don't believe you address it in your
overview), will the resulting DynaBean be a real Java class, or will it
instead be something like a property set or hashmap (albeit a more
intelligent one than those provided by the JDK)?
I assume you are leaning towards a generic class which acts as a "super
smart property set", and not the "real Java class generation" approach.
However it would make sense to point this out explicitly in your
functional overview, given that the "real class" is what people expect
when they think "JavaBeans".
Bryan
Re: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Posted by Incze Lajos <in...@mail.matav.hu>.
On Sat, Dec 15, 2001 at 01:26:05PM -0800, Craig R. McClanahan wrote:
> There's been a lot of interest, both here (COMMONS-DEV), on the Struts
> mailing lists, and elsewhere in the idea of a JavaBean-like thing where
> the set of properties can be dynamically defined. If support for this was
> integrated into the BeanUtils package in Commons, we could also make the
> methods in BeanUtils and PropertyUtils treat the properties of these beans
> like they do for regular JavaBeans, and thus be able to leverage them in
> environments based on BeanUtils (such as Struts).
>
> The purpose of this email is to summarize a set of design requirements for
> discussion purposes, so we can coalesce on a design and then get it
> implemented. For extra fun, I've thrown in a very-raw idea of what the
> APIs might look like -- but I'd like to have the group's agreement before
> turning that into code.
>
> Before embarking on the actual development of dynamic beans support, we
> should also do a release of BeanUtils with the current enhancements, to
> provide a stable starting point.
>
> Please let me know what you think!
>
>
> BACKGROUND:
>
> The purpose of the DynaBean design (I'm not firmly attached to the name,
> but kinda like it :-) is to support application programming designs based
> on JavaBeans design patterns, but where the static nature of JavaBeans
> themselves (i.e. the fact that the set of properties is fixed at compile
> time) is too restrictive. Some typical use cases for such a capability:
>
> * A bean object that represents a Row from a JDBC ResultSet
> (the names and types of the column properties cannot be known
> in advance because they are based on the SELECT statement).
>
> * A way to construct and use "value objects" that extract the
> properties of an EJB into a structure that can be utilized by a
> presentation tier technology such as JSP pages, without having
> to hand code the value object.
>
> * A way to capture *all* of the request parameters from a servlet
> request as a single object.
>
> * A way to dynamically represnt XML input data as a tree of Java objects.
>
>
> DESIGN REQUIREMENTS:
>
> * Support a completely arbitrary set of properties and corresponding
> values, with the ability to add and remove properties dynamically.
>
> * Support the ability to dynamically register the set of property
> names that are allowed, and then enforce storing only those
> property names.
>
> * Support the ability to register data types (Java classes) for each
> property, along with the names, with automatic type checking.
>
> CONCEPTUAL API:
>
> public interface DynaBean {
>
There is a very interesting article on "transparent data piplines"
(http://www.onjava.com/pub/a/onjava/2001/12/12/tdp.html). Neither
the intent nor the solution is exactly the same, but rather similar.
The similarity is that both of them wants to give a data structure
that can encapsulate dynamic data but can be accessed in a uniform way.
The author's solution is to map the W3C's infoset to a java object tree.
The data structures are more or less interchangeable (Dynabean seems
to be a bit more scriptable), but the article raises some interesting
usage environments, where the inherently hierarchical nature of it's
design can be convenient.
incze
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: StringUtils.rightPad and StringUtils.leftPad fail to pad correctly
Posted by Bernard D'Have <bd...@wanadoo.be>.
Hi,
I created some JUnit test for this.
They succeed!
But a lot of test with chomp functions are broken.
Also the native-Unicode test is broken but I think taht because the input
string is NOT right!
Please find it in attachment because I have made a lot of modifications to
follow JUnit "best practices".
Happy new year,
Bernard
PS: the two other testcases use the deprecated API assert in place of
assertTrue
-----Original Message-----
From: bayard@generationjava.com [mailto:bayard@generationjava.com]
Sent: Saturday, December 29, 2001 0:23
To: Jakarta Commons Developers List
Subject: Re: StringUtils.rightPad and StringUtils.leftPad fail to pad
correctly
Will do. Got a deadline of next Wednesday to work to, so will have to
focus on that first.
On Fri, 28 Dec 2001, Daniel Rall wrote:
> Janek Bogucki <ja...@yahoo.co.uk> writes:
>
> > StringUtils.rightPad and StringUtils.leftPad fail to
> > pad correctly with certain
> > categories of input. Some samples follow.
>
> Would you mind adding a JUnit test case for this?
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
Re: StringUtils.rightPad and StringUtils.leftPad fail to pad correctly
Posted by ba...@generationjava.com.
Will do. Got a deadline of next Wednesday to work to, so will have to
focus on that first.
On Fri, 28 Dec 2001, Daniel Rall wrote:
> Janek Bogucki <ja...@yahoo.co.uk> writes:
>
> > StringUtils.rightPad and StringUtils.leftPad fail to
> > pad correctly with certain
> > categories of input. Some samples follow.
>
> Would you mind adding a JUnit test case for this?
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: StringUtils.rightPad and StringUtils.leftPad fail to pad correctly
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Janek Bogucki <ja...@yahoo.co.uk> writes:
> StringUtils.rightPad and StringUtils.leftPad fail to
> pad correctly with certain
> categories of input. Some samples follow.
Would you mind adding a JUnit test case for this?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
StringUtils.isLine throws ArrayIndexOutOfBoundsException and fails to check index sz - 2
Posted by Janek Bogucki <ja...@yahoo.co.uk>.
There are a couple of bugs in
org.apache.commons.util.StringUtils.isLine. (If there
is a more suitable way for me to go about reporting
stuff about the sandbox please educate me - thanks,
janek)
1.
--
org.apache.commons.util.StringUtils.isLine ( String
str ) throws a ArrayIndexOutOfBoundsException in this
case:
String testString = "abc-\r" ;
if ( StringUtils.isLine ( testString ) )
System.out.println("It was a line");
else
System.out.println("It was not a line");
Exception in thread "main"
java.lang.ArrayIndexOutOfBoundsException
at
org.apache.commons.util.StringUtils.isLine(StringUtils.java:1574)
at
brandram.debug.TestPad.main(TestPad.java:47)
2.
--
The hyphen in "abc-x" is never examined in
StringUtils.isLine. In fact the character at index sz
- 2 is always skipped.
Current version of the method from StringUtils 1.18
---------------------------------------------------
/**
* Is a String a line, containing only letters,
digits or
* whitespace, and ending with an optional
newline.
* NB: Punctuation not allowed.
*/
static public boolean isLine(String str) {
char ch = 0;
char[] chrs = str.toCharArray();
int sz = chrs.length;
for(int i=0; i<sz-2; i++) {
if(!Character.isLetterOrDigit(chrs[i])) {
if(!Character.isWhitespace(chrs[i])) {
return false;
}
}
}
if(!Character.isLetterOrDigit(chrs[sz-1])) {
if(!Character.isWhitespace(chrs[sz-1])) {
if(chrs[sz-1] != '\r') {
return false;
} else
if(chrs[sz] != '\n') {
return false;
}
}
}
if(!Character.isLetterOrDigit(chrs[sz])) {
if(!Character.isWhitespace(chrs[sz])) {
if(chrs[sz] != '\n') {
return false;
}
}
}
return true;
}
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
StringUtils.rightPad and StringUtils.leftPad fail to pad correctly
Posted by Janek Bogucki <ja...@yahoo.co.uk>.
(I tried reporting this via the Apache Bug Database
but sandbox code isn't listed as a Commons component
so I hope this eventually finds the right person...)
-janek
StringUtils.rightPad and StringUtils.leftPad fail to
pad correctly with certain
categories of input. Some samples follow.
rightPad ( "1234", 8, "-+" ) = "1234" (Expected:
"1234-+-+")
rightPad ( "123456", 9, "-+~" ) = "123456" (Expected:
"123456-+~" )
leftPad ( "1234", 8, "-+" ) = "1234" (Expected:
"-+-+1234")
leftPad ( "123456", 9, "-+~" ) = "123456" (Expected:
"-+~123456" )
For convenience, some code to recreate these results:
System.out.println ("rightPad ( 1234, 8, -+ )
= " +
StringUtils.rightPad ( "1234", 8, "-+" )
);
System.out.println ("rightPad ( 123456, 9, -+~
) = " +
StringUtils.rightPad ( "123456", 9, "-+~" )
);
System.out.println ("leftPad ( 1234, 8, -+ ) =
" +
StringUtils.leftPad ( "1234", 8, "-+" )
);
System.out.println ("leftPad ( 123456, 9, -+~
) = " +
StringUtils.leftPad ( "123456", 9, "-+~" )
);
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Posted by Nicholas Lesiecki <ni...@eblox.com>.
<<<
Cases (2) and (3) are the highest on my priority list. Case (3) is what
Struts users are concerned about -- right now, Struts requires you to
program a separate bean for every form, and it would be nice not to have
to do that.
>>>
AHHHH! Noooooo on case 3! It would be "nice" not to have to do code a form,
but how would I get the values out of the form?
Currently:
MyForm myForm = (MyForm)form;
String value = myForm.getValue();
With DynaBean:
DynaForm dForm = (DynaForm)form;
String value = (String)dForm.get("value");
How is this more desirable than:
String value = (String)request.getParameter("value");
?
One of the things I loved about Struts was that I could rely on Struts to
provide strongly typed inputs to my action classes, with Dynamic form input
I might as well go right to the request. Of course I probably don't have to
use DynaForm, but I'm saying it should not be a use case which drives the
development of DynaBean.
Cheers,
nick
-----Original Message-----
From: craigmcc@neo.austinite.com [mailto:craigmcc@neo.austinite.com]On
Behalf Of Craig R. McClanahan
Sent: Saturday, December 15, 2001 5:50 PM
To: Jakarta Commons Developers List
Subject: Re: [Design Discussion] DynaBean - JavaBeans with dynamic
properties
On Sat, 15 Dec 2001, Jason van Zyl wrote:
> Date: Sat, 15 Dec 2001 17:59:58 -0500
> From: Jason van Zyl <jv...@zenplex.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [Design Discussion] DynaBean - JavaBeans with dynamic
> properties
>
> On 12/15/01 4:26 PM, "Craig R. McClanahan" <cr...@apache.org> wrote:
>
>
> (2)
> > * A way to construct and use "value objects" that extract the
> > properties of an EJB into a structure that can be utilized by a
> > presentation tier technology such as JSP pages, without having
> > to hand code the value object.
>
> (3)
> > * A way to capture *all* of the request parameters from a servlet
> > request as a single object.
>
(Thanks for the numbering ... that helps clarify references :-).
> [snip]
>
> For (3) that would be excellent. So you could match up the dynamic
> properties produced by the request with an object? That would be very
cool!
>
> For (2) I'm not sure I understand what you mean. I don't use JSP or EJB's
so
> I'm not clear on how using a DynaBean in a JSP would differ from using the
> EJB directly in the JSP?
>
Cases (2) and (3) are the highest on my priority list. Case (3) is what
Struts users are concerned about -- right now, Struts requires you to
program a separate bean for every form, and it would be nice not to have
to do that.
Case (2) is based on a similar design principle when using EJBs.
Conceptually, an entity EJB (representing persistent data from the
underlying persistent store) can be used directly like a JavaBean --
however, it is possible (or likely, depending on your deployment scenario)
that every property getter call will be remote because the EJB itself is
on a different server. That has unacceptable performance impacts in most
scenarios. A value object is retrieved from the EJB with one (remote)
call, and then its just a JavaBean for your presentation technology (such
as a JSP page or a Velocity template) to use.
A second reason for using value objects is separation of the presentation
layer state of a transaction (i.e. the changes to the property values that
are being made as the result of form submits) and the state of the
underlying persistent data. There are at least three important
considerations:
* You don't want to immediately write the input values from
the user into the persistent object, until the input has all
been validated AND until you know that the user isn't going
to undo the transaction.
* Just as with getters, property setters are potentially a bunch of
individual remote calls (RMI or CORBA or whatever), so you'd be better
off to do them all in one call.
* Aside from the remote call issue, starting to call property setters
on an EJB may (depending on how you manage your database transactions
and container-managed or bean-managed persistence) start a database
transaction, and therefore lock resources, until the last one is done.
Good database practice says you want to minimize the amount of time
that happens, which could be a long while if you're using a multipage
input form.
The recommended solution, then, is to collect all the updated stuff in a
value bean (or a set of individual properties somewhere) and do the actual
updates with a minimal number of calls (ideally just one).
Traditionally, value objects are painful to develop in the same way that
Struts ActionForms are -- you have to write each one individually, and a
more tedious and boring kind of programming you won't find anywhere.
Using a DynaBean for this purpose means you can reuse one general purpose
class for most or all of these requirements, rather than having to code
one for each different value bean (and maintain them later as the set of
properties evolves over time).
Value objects are useful in non-EJB environments as well, for pretty much
the same design reasons. One useful source of info about them:
Alur, Crupi, Malks, CORE J2EE PATTERNS: BEST PRACTICES
AND DESIGN STRATEGIES, Prentice Hall, 2001.
The J2EE Blueprints guidelines also recommend using value objects, for the
same sorts of reasons.
> Just a quick set of comments :-)
>
> --
>
> jvz.
>
> Jason van Zyl
>
Craig
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 15 Dec 2001, Jason van Zyl wrote:
> Date: Sat, 15 Dec 2001 17:59:58 -0500
> From: Jason van Zyl <jv...@zenplex.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [Design Discussion] DynaBean - JavaBeans with dynamic
> properties
>
> On 12/15/01 4:26 PM, "Craig R. McClanahan" <cr...@apache.org> wrote:
>
>
> (2)
> > * A way to construct and use "value objects" that extract the
> > properties of an EJB into a structure that can be utilized by a
> > presentation tier technology such as JSP pages, without having
> > to hand code the value object.
>
> (3)
> > * A way to capture *all* of the request parameters from a servlet
> > request as a single object.
>
(Thanks for the numbering ... that helps clarify references :-).
> [snip]
>
> For (3) that would be excellent. So you could match up the dynamic
> properties produced by the request with an object? That would be very cool!
>
> For (2) I'm not sure I understand what you mean. I don't use JSP or EJB's so
> I'm not clear on how using a DynaBean in a JSP would differ from using the
> EJB directly in the JSP?
>
Cases (2) and (3) are the highest on my priority list. Case (3) is what
Struts users are concerned about -- right now, Struts requires you to
program a separate bean for every form, and it would be nice not to have
to do that.
Case (2) is based on a similar design principle when using EJBs.
Conceptually, an entity EJB (representing persistent data from the
underlying persistent store) can be used directly like a JavaBean --
however, it is possible (or likely, depending on your deployment scenario)
that every property getter call will be remote because the EJB itself is
on a different server. That has unacceptable performance impacts in most
scenarios. A value object is retrieved from the EJB with one (remote)
call, and then its just a JavaBean for your presentation technology (such
as a JSP page or a Velocity template) to use.
A second reason for using value objects is separation of the presentation
layer state of a transaction (i.e. the changes to the property values that
are being made as the result of form submits) and the state of the
underlying persistent data. There are at least three important
considerations:
* You don't want to immediately write the input values from
the user into the persistent object, until the input has all
been validated AND until you know that the user isn't going
to undo the transaction.
* Just as with getters, property setters are potentially a bunch of
individual remote calls (RMI or CORBA or whatever), so you'd be better
off to do them all in one call.
* Aside from the remote call issue, starting to call property setters
on an EJB may (depending on how you manage your database transactions
and container-managed or bean-managed persistence) start a database
transaction, and therefore lock resources, until the last one is done.
Good database practice says you want to minimize the amount of time
that happens, which could be a long while if you're using a multipage
input form.
The recommended solution, then, is to collect all the updated stuff in a
value bean (or a set of individual properties somewhere) and do the actual
updates with a minimal number of calls (ideally just one).
Traditionally, value objects are painful to develop in the same way that
Struts ActionForms are -- you have to write each one individually, and a
more tedious and boring kind of programming you won't find anywhere.
Using a DynaBean for this purpose means you can reuse one general purpose
class for most or all of these requirements, rather than having to code
one for each different value bean (and maintain them later as the set of
properties evolves over time).
Value objects are useful in non-EJB environments as well, for pretty much
the same design reasons. One useful source of info about them:
Alur, Crupi, Malks, CORE J2EE PATTERNS: BEST PRACTICES
AND DESIGN STRATEGIES, Prentice Hall, 2001.
The J2EE Blueprints guidelines also recommend using value objects, for the
same sorts of reasons.
> Just a quick set of comments :-)
>
> --
>
> jvz.
>
> Jason van Zyl
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Design Discussion] DynaBean - JavaBeans with dynamic
properties
Posted by Jason van Zyl <jv...@zenplex.com>.
On 12/15/01 4:26 PM, "Craig R. McClanahan" <cr...@apache.org> wrote:
[snip]
(1)
> * A bean object that represents a Row from a JDBC ResultSet
> (the names and types of the column properties cannot be known
> in advance because they are based on the SELECT statement).
(2)
> * A way to construct and use "value objects" that extract the
> properties of an EJB into a structure that can be utilized by a
> presentation tier technology such as JSP pages, without having
> to hand code the value object.
(3)
> * A way to capture *all* of the request parameters from a servlet
> request as a single object.
(4)
> * A way to dynamically represnt XML input data as a tree of Java objects.
To me (1) and (4) seem like like anti patterns where objects are created
from the structure of the data instead of starting with the object model and
letting a persistence layer retrieve/save to whatever particular format
you've decided upon. I just feel that the object model is the expression of
an application or process.
I'm playing the devil's advocate here but in the case of (1) what happens to
the objects application programmers are using when the DBA decides to change
a schema? In something like a persistence layer where the mappings between
the object model and data are stored in a data dictionary the application
programmer is not affected by underlying changes in the data structure. I
suppose you could protect the application programmer if you were using views
in conjunction with ResultSets. I may be off the mark here as I never use
ResultSets directly.
Maybe you have designed a way to allow a particular model to remain the same
even when the underlying data structure changes. Like I said, just playing
the devil's advocate.
For (3) that would be excellent. So you could match up the dynamic
properties produced by the request with an object? That would be very cool!
For (2) I'm not sure I understand what you mean. I don't use JSP or EJB's so
I'm not clear on how using a DynaBean in a JSP would differ from using the
EJB directly in the JSP?
Just a quick set of comments :-)
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Posted by bob mcwhirter <bo...@werken.com>.
> * A bean object that represents a Row from a JDBC ResultSet
> (the names and types of the column properties cannot be known
> in advance because they are based on the SELECT statement).
>
> * A way to construct and use "value objects" that extract the
> properties of an EJB into a structure that can be utilized by a
> presentation tier technology such as JSP pages, without having
> to hand code the value object.
>
> * Support a completely arbitrary set of properties and corresponding
> values, with the ability to add and remove properties dynamically.
This sounds somewhat akin to the Java Connector Architecture, kinda,
as far as 'row' types of things.
-bob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Posted by Paulo Gaspar <pa...@krankikom.de>.
Craig and other "DynaBeaners",
I implemented a class that is very similar to what you describe several
months ago and it completely changed the way I do things, for the MUCH
better.
I am just going to describe a bit of my experience hoping that some of
you find it useful.
<!-- Section for those that don't understand "why DynaBeans": -->
<unbeliever-section>
I was in the process of turning a framework I have been working on from
prototype into a production version. One of the lessons learned from the
prototype was that we spend a lot of energy moving values with names in
web applications. Values it names are things like:
- Servlet request parameters;
- ResultSet columns;
- Bean properties;
- XML element attributes;
- and a big ETC.
A typical silly situation is the simple HTML data entry over a database
table, where everything (all HTML Form fields and bean properties)
follows the column names of the table and you end up making a load of
assignments by hand.
It is crazy. It should be simple to say "move the servlet request
parameters to the bean properties with the same name (ignoring case)
using this set of conversion rules". Same thing to move the data from
the bean into the database and all the way back too.
For the bits of the circuit where there is no name match, a name to
name map takes care of it.
The first obvious step is to get a common interface you can use to
represent (and wrap) things with names. Something like this:
public interface INameMapper
{
public Object get(String name);
public void set(String name, Object value);
public int count();
public String[] names();
public boolean hasField(String name);
}
(Keep in mind that this is not exactly what I use. I am just
describing the idea.)
Then you find out that in a lot of simple cases your beans are not
doing more than work as temporary storage and you dream of having a
DynaBean (which I call Record).
</unbeliever-section>
<!-- Now, this is for believers too... -->
And then you find out that you can do a lot more with DynaBeans.
For me it turned useless most of the stuff in utility classes like the
BeanUtils and PropertyUtils.
Consider a conversion class like this:
public interface Converter
{
public Object convert(Class destType, Object srcValue)
throws ConversionException;
}
Now, this idea is not original. You end up building an object that
implements it by aggregating many simple conversion rules. New needs
for a new conversion type, new simple rule.
You can even use such a thing for data formatting and to parse data
of different formats.
The interesting bit is when you combine the above converter with a
DynaBean.
Most projects I see at Jakarta work with introspection from the
outside, asking which is the type of each property or asking for each
property to be converted to a given type. And then you end up with
dreadful utility classes that look like this:
interface SomeBeanWrapper
{
int getAsString(String propName);
...
int getAsInt(String propName);
...
double getAsDouble(String propName);
...
}
But inside a DynaBean, you can make the "set()" method like this:
public void set(String propName, Object value)
// throws ConversionException but this is a "RunTimeException"
{
final Class fieldType = fieldType(propName);
final Object newValue = m_myConverter.convert(fieldType, value);
internalSet(propName, newValue); // set the property
}
(Again, this is a gross simplification.)
So, for a DynaBean with a converter you never have to care about the
type of the values you are assigning to it - you just have to care that
its converter is appropriate. The DynaBean knows its field types and
makes the correct calls to the converter.
Now, maybe you will ask:
- And what if I want to move the values stored in a DynaBean into
something else?
And what if you never have to?
For a really dynamic DynaBean the method "internalSet()" of the last
code snippet would place the value into some HashTable (actually I use
something different). But what if there is an implementation of the
same DynaBeanInterface that is a wrapper?
I use a RecordWrapper (my "DynaBean" is called "Record") to wrap
beans, ResultSets and other typical sets-of-typed-named-values.
In most cases it is even the same RecordWrapper class - the
implementation change occurs in an associated class which name
includes the word "Introspector". There just is a different
introspector for beans than for Resultsets.
Now, there is a case I do not use DynaBeans for:
> * A way to dynamically represent XML input data as a tree of Java
> objects.
If this is for configuration stuff, I think it is overkill. But then
maybe it is not for configuration, since you have the Digester.
I must say I find the Digester a bit too hard to use and I build a
derivative of the very-nice-and-simple configuration from Avalon.
The alteration has all to do with Ant. I like the way it is so simple
to build Ant targets and the way Ant uses introspection and knows so
many "property" types in my target "bean".
I use the same light data structure that the Avalon stuff builds to
represent XML configuration files (via SAX) but I put a Configurator
in between to introspect and assign the values to my components a la
Ant - with introspection + data conversion work via the above
mentioned "RecordWrapper".
The Configurator and Converter ideas come from Peter Donald's work
on Ant's "Myrmidon" proposal (the Configurator is calls "Configurer"
there).
I would love to get some feedback on this stuff.
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
> -----Original Message-----
> From: craigmcc@krankikom.de [mailto:craigmcc@krankikom.de]On Behalf Of
> Craig R. McClanahan
> Sent: Saturday, December 15, 2001 10:26 PM
> To: commons-dev@jakarta.apache.org
> Subject: [Design Discussion] DynaBean - JavaBeans with dynamic
> properties
>
>
> There's been a lot of interest, both here (COMMONS-DEV), on the Struts
> mailing lists, and elsewhere in the idea of a JavaBean-like thing where
> the set of properties can be dynamically defined. If support for this was
> integrated into the BeanUtils package in Commons, we could also make the
> methods in BeanUtils and PropertyUtils treat the properties of these beans
> like they do for regular JavaBeans, and thus be able to leverage them in
> environments based on BeanUtils (such as Struts).
>
> The purpose of this email is to summarize a set of design requirements for
> discussion purposes, so we can coalesce on a design and then get it
> implemented. For extra fun, I've thrown in a very-raw idea of what the
> APIs might look like -- but I'd like to have the group's agreement before
> turning that into code.
>
> Before embarking on the actual development of dynamic beans support, we
> should also do a release of BeanUtils with the current enhancements, to
> provide a stable starting point.
>
> Please let me know what you think!
>
>
> BACKGROUND:
>
> The purpose of the DynaBean design (I'm not firmly attached to the name,
> but kinda like it :-) is to support application programming designs based
> on JavaBeans design patterns, but where the static nature of JavaBeans
> themselves (i.e. the fact that the set of properties is fixed at compile
> time) is too restrictive. Some typical use cases for such a capability:
>
> * A bean object that represents a Row from a JDBC ResultSet
> (the names and types of the column properties cannot be known
> in advance because they are based on the SELECT statement).
>
> * A way to construct and use "value objects" that extract the
> properties of an EJB into a structure that can be utilized by a
> presentation tier technology such as JSP pages, without having
> to hand code the value object.
>
> * A way to capture *all* of the request parameters from a servlet
> request as a single object.
>
> * A way to dynamically represnt XML input data as a tree of Java objects.
>
>
> DESIGN REQUIREMENTS:
>
> * Support a completely arbitrary set of properties and corresponding
> values, with the ability to add and remove properties dynamically.
>
> * Support the ability to dynamically register the set of property
> names that are allowed, and then enforce storing only those
> property names.
>
> * Support the ability to register data types (Java classes) for each
> property, along with the names, with automatic type checking.
>
> * Support for properties with scalar types, array types, and
> "mapped" types (as currently supported in Beanutils).
>
> * Support "simple" and "indexed" property getters and setters
> in a style similar to standard JavaBeans.
>
> * Support registration of property change listeners and broadcast
> of property change events
>
> * Provide the basic DynaBean API as a Java interface, as well as a
> convenience base class, so that applications can adopt it however
> they wish.
>
> * Base implementation class should implement Serializable so that
> DynaBeans can be serialized and deserialized (assuming that the
> actual property values can be).
>
> * Transparently support DynaBean objects in the existing BeanUtils
> and PropertyUtils classes of the Bean Utilities package.
>
> * To the maximum extent feasible, provide JavaBeans-like introspection
> capabilities of the available properties. May require an
> IntrospectionUtils addition to the Beanutils package.
>
>
> CONCEPTUAL API:
>
> public interface DynaBean {
>
>
> // ----------------------------------------------------------------
> // Dynamic property configuration
> // ----------------------------------------------------------------
>
> void addDynamic(String name); // Unrestricted type
> void addDynamic(String name, Class type); // Restricted type
> void removeDyanamic(String name); // Remove property & value
> void restrictDynamic(boolean restrict); // Are property names
> // restricted to registered
> // ones? (default=false)
> // (can be changed)
>
> // ----------------------------------------------------------------
> // Property getters and setters. Behavior on previously
> // unknown property names depends on the restrict setting
> // ----------------------------------------------------------------
>
> // Does this bean have a property of the specified name?
> boolean contains(String name);
>
> // Getters return null on unknown property names
> Object get(String name); // Simple
> Object get(String name, int index); // Indexed
> Object get(String name, String key); // Mapped
>
> // Setters are allowed to set null unless property is native.
> // Optionally throw IllegalArgumentException if type is restricted
> // and the value argument is not assignment-compatible
> void set(String name, Object value); // Simple
> void set(String name, int index, // Indexed
> Object value);
> void set(String name, String key, // Mapped
>
> }
>
>
> Craig McClanahan
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Posted by Michael Smith <mi...@iammichael.org>.
> -----Original Message-----
> The purpose of the DynaBean design (I'm not firmly attached
> to the name,
> but kinda like it :-) is to support application programming
> designs based
> on JavaBeans design patterns, but where the static nature of JavaBeans
> themselves (i.e. the fact that the set of properties is fixed
> at compile
> time) is too restrictive. Some typical use cases for such a
> capability:
>
> * A bean object that represents a Row from a JDBC ResultSet
> (the names and types of the column properties cannot be known
> in advance because they are based on the SELECT statement).
>
> * A way to construct and use "value objects" that extract the
> properties of an EJB into a structure that can be utilized by a
> presentation tier technology such as JSP pages, without having
> to hand code the value object.
>
> * A way to capture *all* of the request parameters from a servlet
> request as a single object.
>
> * A way to dynamically represnt XML input data as a tree of
> Java objects.
>From this, it sounds like you're trying to build a "generic" object that
can be used to get the equivalent functionality of JDBC ResultSet (which
is already column agnostic), HttpServletRequest (encapsulates request
parameters, request headers, etc.), DOM (represents XML as a tree of
Java objects), etc. In other words, rather than use an application
specific method for expressing dynamic data, you're looking to create a
generic, application-agnostic specific method for expressing data
unknown at compile time. Does that summarize things?
If so, I would say that the APIs for the WBEM CIM (JSR 48) stuff aims to
do something similar. For their current API, see:
http://wbemservices.sourceforge.net/javadoc/api/javax/wbem/cim/package-s
ummary.html
That API isn't final yet, pending JCP approval and all that.
The API uses a CIMClass to hold the definition of a "class" and a
CIMInstance to hold an object instance. An object instance has
properties which are retrieved using the getProperty method. The
property (a CIMProperty object) has the property name, its type, and its
value, along with various qualifiers. The type is represented as a
CIMType, and the value is represented as a CIMValue. The CIMValue has
the ability to determine whether the value is null, is an array, what
its type is, and what the underlying value is.
The CIMInstance is very similar to a "value" object as you describe in a
later email. You can make whatever modifications to it before passing
it back to the instance store for persistence or something like that.
One thing CIM also supports are methods. Although you seem more
interested in storing values, so this probably isn't as relevant.
I work with the CIM apis at my day job, and I can't say they're the
designed the best (the use of Vector everywhere makes me cringe), so I'm
not advocating the direct application of the APIs for the projet you are
proposing. There just might be a couple of things to learn from their
work so far. Anyway....
> DESIGN REQUIREMENTS:
>
> * Support a completely arbitrary set of properties and corresponding
> values, with the ability to add and remove properties dynamically.
>
> * Support the ability to dynamically register the set of property
> names that are allowed, and then enforce storing only those
> property names.
>
> * Support the ability to register data types (Java classes) for each
> property, along with the names, with automatic type checking.
>
> * Support for properties with scalar types, array types, and
> "mapped" types (as currently supported in Beanutils).
>
> * Support "simple" and "indexed" property getters and setters
> in a style similar to standard JavaBeans.
>
> * Support registration of property change listeners and broadcast
> of property change events
This is something I don't think CIM has, and I think is sorely needed.
Does this design requirement include vetoable change capability as well?
> * Provide the basic DynaBean API as a Java interface, as well as a
> convenience base class, so that applications can adopt it however
> they wish.
>
> * Base implementation class should implement Serializable so that
> DynaBeans can be serialized and deserialized (assuming that the
> actual property values can be).
>
> * Transparently support DynaBean objects in the existing BeanUtils
> and PropertyUtils classes of the Bean Utilities package.
>
> * To the maximum extent feasible, provide JavaBeans-like introspection
> capabilities of the available properties. May require an
> IntrospectionUtils addition to the Beanutils package.
>
>
> CONCEPTUAL API:
>
> public interface DynaBean {
>
>
> //
> ----------------------------------------------------------------
> // Dynamic property configuration
> //
> ----------------------------------------------------------------
>
> void addDynamic(String name); // Unrestricted type
> void addDynamic(String name, Class type); // Restricted type
> void removeDyanamic(String name); // Remove
> property & value
> void restrictDynamic(boolean restrict); // Are property names
> // restricted
> to registered
> // ones?
> (default=false)
> // (can be changed)
>
> //
> ----------------------------------------------------------------
> // Property getters and setters. Behavior on previously
> // unknown property names depends on the restrict setting
> //
> ----------------------------------------------------------------
>
> // Does this bean have a property of the specified name?
> boolean contains(String name);
>
> // Getters return null on unknown property names
> Object get(String name); // Simple
> Object get(String name, int index); // Indexed
> Object get(String name, String key); // Mapped
>
> // Setters are allowed to set null unless property is native.
> // Optionally throw IllegalArgumentException if type is restricted
> // and the value argument is not assignment-compatible
> void set(String name, Object value); // Simple
>
> void set(String name, int index, // Indexed
> Object value);
> void set(String name, String key, // Mapped
>
> }
I think you missed an "Object value);" after the set for mapped
properties. :)
I'm not sure that having the typing information (i.e. the *Dynamic
methods) in the same class is going to give you the best runtime typing
information. You can verify the properties are the proper types, but
there's no way to verify the bean conforms to a particular set of
properties without checking for the existance and type of each of the
properties. Plus, the typing information would be duplicated for each
DynaBean instance.
Consider moving the property definition stuff out to a separate
interface, say "DynaClass". Then, you can create a DynaClass, specify
the properties on the class, use the class to create any number
instances where values are assigned to the properties, keeping the
typing information in the DynaClass rather than the DynaBean. The
DynaBean doesn't necessarily need to conform strictly to the DynaClass
(you could add properties that aren't defined in the DynaClass), and you
could modify the DynaClass dynamically as well.
This way, you get the ability to reduce the memory footprint by keeping
typing information in the class that's reused rather than in each
instance. Plus, it also gives you the ability to define validation
methods or something like that which can be used to ensure all the
defined values have been set appropriately or whatnot. Although I'm not
all that familiar with Struts, I can see how the DynaClass would be
anologous to the ActionForm class definition, and the DynaBean would
actually hold the actual form data. One form definition (DynaClass),
multiple users providing data (DynaBeans).
You mention restricting setting properties to null if the property is
native, but I think there's a little bit more that can be done with
that, especially since you only have support for "Object" (in which
case, there's no easy way to distinguish between primitive and other
objects).
Consider accepting "qualifiers" when the dynamic property is added. One
qualifier could be the java Class that the value must be an instance of.
Another would be whether a "null" value is acceptable. You could also
extend this to an "enumeration" qualifier (e.g. property "Status" can
only have the values "Stopped", "Starting", "Running", and "Stopping").
A generic qualifier API could be created such that more complicated type
validation could be added (e.g. a regular expression qualifier to ensure
a string property value has an appropriate form). Such a generic
mechanism may lead to someone building "logic" into the qualifiers
rather than "type" information.
I'd be more than happy to put these thoughts into an API if it might
help explain the ideas I've expressed.
> Craig McClanahan
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: (Logging)[Proposal] A little refactoring
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 20 Dec 2001, robert burrell donkin wrote:
> Date: Thu, 20 Dec 2001 22:19:33 +0000
> From: robert burrell donkin <ro...@mac.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: (Logging)[Proposal] A little refactoring
>
> i've been adding logging (using commons-logging) into betwixt and found
> that commons-logging is a little bit broken. rather than fix the symptom -
> that the log level constants were altered a little and that broke a lot of
> code - i'd prefer to refactor by introducing an abstract implementation
> Log that handles the log level logic (ie. stops calls going to the
> implementation implementation) and make the existing implementations
> inherit. hopefully this would stop logging breaking like that again.
>
> i'm willing to code these changes if this plan's acceptable.
>
+1
> - robert
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: (Logging)[Proposal] A little refactoring
Posted by Donnie Hale <do...@haleonline.net>.
I've seen a lot of logging discussions going on recently. I'm a little late
to the game here, but can I ask where it is that log4j falls short to just
use directly? We have a very large web/ejb app that uses log4j's native API,
and it's been working perfectly for us for the better part of a year.
Just curious...
Donnie
> -----Original Message-----
> From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> Sent: Thursday, December 20, 2001 6:24 PM
> To: Jakarta Commons Developers List
> Subject: RE: (Logging)[Proposal] A little refactoring
>
>
> That was THE reason why I adopted Avalon new wrappers instead. I ported
> them out of Avalon and they work just fine. There are NO dependencies
> from the rest of the framework except for a formatter that can be
> dropped.
>
> I also improved (IMHO) an existing AbstractLoggable class and I am now
> porting an XML based configurator for LogKit from Avalon Excalibur. This
> one has more dependencies but it is ok.
>
> Next I will adapt the simple property configuration code for LogKit and
> Log4J used at Velocity, (will looking at Turbine too).
>
> So, this set includes:
> - Wrappers for Log4J, LogKit and the JDK 1.4 Logging API;
> - Really simple internal logger + NoOp logger;
> - Log4J has its own XML configuration and LogKit gets one;
> - Ability to use a hierarchy of loggers in an API independent way.
> Only the configuration is API dependent.
>
> Will soon (next week) include simple property configuration.
>
> Still no plans on evolving the JDK 1.4 Logging API.
>
>
> This is the best logging code I found around Jakarta. It just picked
> it from several projects and would like to see it together in the
> Commons where it would have a wider use. And it is working fine
> across a 500 class and 75 Kloc piece of code.
>
> My interest is to keep the functionality I have now without being
> alone taking care of it. (Trying to cut on the above numbers.)
> =:o)
>
>
> If there is interest I can put it a "commons" package and post it
> tomorrow.
>
>
> Have fun,
> Paulo Gaspar
>
>
> > -----Original Message-----
> > From: robert burrell donkin [mailto:robertdonkin@mac.com]
> > Sent: Thursday, December 20, 2001 11:20 PM
> > To: Jakarta Commons Developers List
> > Subject: (Logging)[Proposal] A little refactoring
> >
> >
> > i've been adding logging (using commons-logging) into betwixt and found
> > that commons-logging is a little bit broken. rather than fix the
> > symptom -
> > that the log level constants were altered a little and that broke
> > a lot of
> > code - i'd prefer to refactor by introducing an abstract implementation
> > Log that handles the log level logic (ie. stops calls going to the
> > implementation implementation) and make the existing implementations
> > inherit. hopefully this would stop logging breaking like that again.
> >
> > i'm willing to code these changes if this plan's acceptable.
> >
> > - robert
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: (Logging)[Proposal] A little refactoring
Posted by Paulo Gaspar <pa...@krankikom.de>.
> Is commons-logging actually done? If I recall, it just showed up? Paulo,
> any chance we can see what you are thinking about?
Sorry, I was trying to finish the configuration stuff and add some samples
to make its use clear, but my "other" project and Christmas got in the way.
(Suddenly I realized that today was the last chance to buy my girlfriend's
presents and how it would be such a bad idea to skip it.)
I am attaching what I have, still in my current internal packaging
(krankikom.log). I will change the package name it this goes further in the
commons.
The packages I have at the moment are:
- krankikom.log
Common interface and other common use classes;
- krankikom.log.wrappers
The wrappers for Log4J, LogKit and the JDK 1.4 Logging API;
- krankikom.log.simple
A very simple logger I use. It is still here because of the "Primordial
Logger" idea that Geir implemented at Velocity.
*** Status on the other "features" I promised:
> >> - Log4J has its own XML configuration and LogKit gets one;
I am not sure I should include LogKit XML configuration here. This is
what
I will do for my company work but I think this should an extra package
for
LogKit instead of part of Avalon's Excalibur project. So, after I finish
taking it out of Excalibur (already started) I will try to talk with the
Avalon guys about this idea (could use some help).
> >> - Ability to use a hierarchy of loggers in an API independent way.
> >> Only the configuration is API dependent.
This is what I am working on. It is a very simple properties based
configuration scheme with which you can configure in a simple way some
common features of each logging API (and maybe some specific ones).
All the logging APIs allow you at least to define a hierarchy, to log
to a file with a rotating scheme, etc.
It is a little step further of what you can find at Velocity: you give
an ordered list of Logger factories (one for each Logging API supported)
and the system will try (following the list's order) to get one of them
working. The first factory to successfully load its API will then try to
build the given configuration.
> >> Will soon (next week) include simple property configuration.
As stated above I already started it and wanted to have it ready before
delivering this... before Christmas took over. =;o)
> >> Still no plans on evolving the JDK 1.4 Logging API.
It is a piece of crap (I was reading the Javadocs yesterday) but I
think I can include it in the property based configuration thing.
<rant>
Man, according to the Javadocs that Logger is bloated with crap! Loads
of helper methods. A mess! And then, after bloating the logger they
had no time to provide more logging targets and formatting. Formatting
documentation looks rather incomplete.
I sure hope that the final stuff is better than what I saw in the online
Javadocs.
</rant>
Should I look at the specs? Do those promise anything a bit better?
*** The krankikom.simple package and the primordial logger:
The idea is to log whatever happens before the logger is initialized to an
in memory log event list that will than be dumped on whatever logger is
loaded. There is something like this in Velocity and I find it useful.
I use the rest of the SimpleLogger stuff to perform simple logging if no
other logger is there. For me it works fine (for a large framework it is a
small addition) but I am not sure this makes sense for the commons.
I can cut it to the essential for the Primordial Logger to work.
*** Other Logging stuff I have:
- AbstractLoggable with i18n:
I have an "AbstractLoggable" (see the code to understand what this is)
with simple i18n support using the older (property based) i18n stuff
at Avalon. It is interesting but it is connected to the i18n stuff.
- AbstractLoggable with further information on the "logged Object":
This one prefixes each message with the logged object class name and
an integer identifier. I added it to check if my database connection
pool and other related classes were not "forgetting" any database
Connection.
Any interest in things like this?
*** Conclusion
As you will see, most of it is Avalon code. The Commons-Avalon-Turbine
synergy is obvious (I will go to that thread too).
IMHO, Avalon can still improve on separating components from some
framework dependencies. Notice however that there is already a trend
in that direction and that MANY components are really easy to "extract".
What I see is that with a bit of wrapping here and better separation of
concerns there it can still improve. However, they should not have to
change their priorities and, as Peter says, we can always do it
ourselves when convenient.
It may sound like having duplicate work, but it might be the only way
to check if the Commons evolution of some components is compatible with
the Avalon evolution. If it is, I am sure we will find a way to reduce
this duplication, otherwise it will have to evolve separately.
I hope this is useful to you.
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Saturday, December 22, 2001 3:17 PM
> To: Jakarta Commons Developers List
> Subject: Re: (Logging)[Proposal] A little refactoring
>
>
> On 12/21/01 12:48 PM, "robert burrell donkin"
> <ro...@mac.com> wrote:
>
> > commons-logging is currently broken. i think that it shound be fixed.
> >
> > maybe paulo's suggestion would make more sense as a competing branch -
> > commons-logging 2.0? that way, people can take a look at the actual code
> > but we don't have to stop development on other components until it's
> > finished.
> >
>
>
> Is commons-logging actually done? If I recall, it just showed up? Paulo,
> any chance we can see what you are thinking about?
>
>
> > - robert
> >
> >
> > On Thursday, December 20, 2001, at 11:23 PM, Paulo Gaspar wrote:
> >
> >> That was THE reason why I adopted Avalon new wrappers instead. I ported
> >> them out of Avalon and they work just fine. There are NO dependencies
> >> from the rest of the framework except for a formatter that can be
> >> dropped.
> >>
> >> I also improved (IMHO) an existing AbstractLoggable class and I am now
> >> porting an XML based configurator for LogKit from Avalon
> Excalibur. This
> >> one has more dependencies but it is ok.
> >>
> >> Next I will adapt the simple property configuration code for LogKit and
> >> Log4J used at Velocity, (will looking at Turbine too).
> >>
> >> So, this set includes:
> >> - Wrappers for Log4J, LogKit and the JDK 1.4 Logging API;
> >> - Really simple internal logger + NoOp logger;
> >> - Log4J has its own XML configuration and LogKit gets one;
> >> - Ability to use a hierarchy of loggers in an API independent way.
> >> Only the configuration is API dependent.
> >>
> >> Will soon (next week) include simple property configuration.
> >>
> >> Still no plans on evolving the JDK 1.4 Logging API.
> >>
> >>
> >> This is the best logging code I found around Jakarta. It just picked
> >> it from several projects and would like to see it together in the
> >> Commons where it would have a wider use. And it is working fine
> >> across a 500 class and 75 Kloc piece of code.
.........
RE: (Logging)[Proposal] A little refactoring
Posted by Paulo Gaspar <pa...@krankikom.de>.
> Is commons-logging actually done? If I recall, it just showed up? Paulo,
> any chance we can see what you are thinking about?
Sorry, I was trying to finish the configuration stuff and add some samples
to make its use clear, but my "other" project and Christmas got in the way.
(Suddenly I realized that today was the last chance to buy my girlfriend's
presents and how it would be such a bad idea to skip it.)
I am attaching what I have, still in my current internal packaging
(krankikom.log). I will change the package name it this goes further in the
commons.
The packages I have at the moment are:
- krankikom.log
Common interface and other common use classes;
- krankikom.log.wrappers
The wrappers for Log4J, LogKit and the JDK 1.4 Logging API;
- krankikom.log.simple
A very simple logger I use. It is still here because of the "Primordial
Logger" idea that Geir implemented at Velocity.
*** Status on the other "features" I promised:
> >> - Log4J has its own XML configuration and LogKit gets one;
I am not sure I should include LogKit XML configuration here. This is
what
I will do for my company work but I think this should an extra package
for
LogKit instead of part of Avalon's Excalibur project. So, after I finish
taking it out of Excalibur (already started) I will try to talk with the
Avalon guys about this idea (could use some help).
> >> - Ability to use a hierarchy of loggers in an API independent way.
> >> Only the configuration is API dependent.
This is what I am working on. It is a very simple properties based
configuration scheme with which you can configure in a simple way some
common features of each logging API (and maybe some specific ones).
All the logging APIs allow you at least to define a hierarchy, to log
to a file with a rotating scheme, etc.
It is a little step further of what you can find at Velocity: you give
an ordered list of Logger factories (one for each Logging API supported)
and the system will try (following the list's order) to get one of them
working. The first factory to successfully load its API will then try to
build the given configuration.
> >> Will soon (next week) include simple property configuration.
As stated above I already started it and wanted to have it ready before
delivering this... before Christmas took over. =;o)
> >> Still no plans on evolving the JDK 1.4 Logging API.
It is a piece of crap (I was reading the Javadocs yesterday) but I
think I can include it in the property based configuration thing.
<rant>
Man, according to the Javadocs that Logger is bloated with crap! Loads
of helper methods. A mess! And then, after bloating the logger they
had no time to provide more logging targets and formatting. Formatting
documentation looks rather incomplete.
I sure hope that the final stuff is better than what I saw in the online
Javadocs.
</rant>
Should I look at the specs? Do those promise anything a bit better?
*** The krankikom.simple package and the primordial logger:
The idea is to log whatever happens before the logger is initialized to an
in memory log event list that will than be dumped on whatever logger is
loaded. There is something like this in Velocity and I find it useful.
I use the rest of the SimpleLogger stuff to perform simple logging if no
other logger is there. For me it works fine (for a large framework it is a
small addition) but I am not sure this makes sense for the commons.
I can cut it to the essential for the Primordial Logger to work.
*** Other Logging stuff I have:
- AbstractLoggable with i18n:
I have an "AbstractLoggable" (see the code to understand what this is)
with simple i18n support using the older (property based) i18n stuff
at Avalon. It is interesting but it is connected to the i18n stuff.
- AbstractLoggable with further information on the "logged Object":
This one prefixes each message with the logged object class name and
an integer identifier. I added it to check if my database connection
pool and other related classes were not "forgetting" any database
Connection.
Any interest in things like this?
*** Conclusion
As you will see, most of it is Avalon code. The Commons-Avalon-Turbine
synergy is obvious (I will go to that thread too).
IMHO, Avalon can still improve on separating components from some
framework dependencies. Notice however that there is already a trend
in that direction and that MANY components are really easy to "extract".
What I see is that with a bit of wrapping here and better separation of
concerns there it can still improve. However, they should not have to
change their priorities and, as Peter says, we can always do it
ourselves when convenient.
It may sound like having duplicate work, but it might be the only way
to check if the Commons evolution of some components is compatible with
the Avalon evolution. If it is, I am sure we will find a way to reduce
this duplication, otherwise it will have to evolve separately.
I hope this is useful to you.
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Saturday, December 22, 2001 3:17 PM
> To: Jakarta Commons Developers List
> Subject: Re: (Logging)[Proposal] A little refactoring
>
>
> On 12/21/01 12:48 PM, "robert burrell donkin"
> <ro...@mac.com> wrote:
>
> > commons-logging is currently broken. i think that it shound be fixed.
> >
> > maybe paulo's suggestion would make more sense as a competing branch -
> > commons-logging 2.0? that way, people can take a look at the actual code
> > but we don't have to stop development on other components until it's
> > finished.
> >
>
>
> Is commons-logging actually done? If I recall, it just showed up? Paulo,
> any chance we can see what you are thinking about?
>
>
> > - robert
> >
> >
> > On Thursday, December 20, 2001, at 11:23 PM, Paulo Gaspar wrote:
> >
> >> That was THE reason why I adopted Avalon new wrappers instead. I ported
> >> them out of Avalon and they work just fine. There are NO dependencies
> >> from the rest of the framework except for a formatter that can be
> >> dropped.
> >>
> >> I also improved (IMHO) an existing AbstractLoggable class and I am now
> >> porting an XML based configurator for LogKit from Avalon
> Excalibur. This
> >> one has more dependencies but it is ok.
> >>
> >> Next I will adapt the simple property configuration code for LogKit and
> >> Log4J used at Velocity, (will looking at Turbine too).
> >>
> >> So, this set includes:
> >> - Wrappers for Log4J, LogKit and the JDK 1.4 Logging API;
> >> - Really simple internal logger + NoOp logger;
> >> - Log4J has its own XML configuration and LogKit gets one;
> >> - Ability to use a hierarchy of loggers in an API independent way.
> >> Only the configuration is API dependent.
> >>
> >> Will soon (next week) include simple property configuration.
> >>
> >> Still no plans on evolving the JDK 1.4 Logging API.
> >>
> >>
> >> This is the best logging code I found around Jakarta. It just picked
> >> it from several projects and would like to see it together in the
> >> Commons where it would have a wider use. And it is working fine
> >> across a 500 class and 75 Kloc piece of code.
.........
Re: (Logging)[Proposal] A little refactoring
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 12/21/01 12:48 PM, "robert burrell donkin" <ro...@mac.com> wrote:
> commons-logging is currently broken. i think that it shound be fixed.
>
> maybe paulo's suggestion would make more sense as a competing branch -
> commons-logging 2.0? that way, people can take a look at the actual code
> but we don't have to stop development on other components until it's
> finished.
>
Is commons-logging actually done? If I recall, it just showed up? Paulo,
any chance we can see what you are thinking about?
> - robert
>
>
> On Thursday, December 20, 2001, at 11:23 PM, Paulo Gaspar wrote:
>
>> That was THE reason why I adopted Avalon new wrappers instead. I ported
>> them out of Avalon and they work just fine. There are NO dependencies
>> from the rest of the framework except for a formatter that can be
>> dropped.
>>
>> I also improved (IMHO) an existing AbstractLoggable class and I am now
>> porting an XML based configurator for LogKit from Avalon Excalibur. This
>> one has more dependencies but it is ok.
>>
>> Next I will adapt the simple property configuration code for LogKit and
>> Log4J used at Velocity, (will looking at Turbine too).
>>
>> So, this set includes:
>> - Wrappers for Log4J, LogKit and the JDK 1.4 Logging API;
>> - Really simple internal logger + NoOp logger;
>> - Log4J has its own XML configuration and LogKit gets one;
>> - Ability to use a hierarchy of loggers in an API independent way.
>> Only the configuration is API dependent.
>>
>> Will soon (next week) include simple property configuration.
>>
>> Still no plans on evolving the JDK 1.4 Logging API.
>>
>>
>> This is the best logging code I found around Jakarta. It just picked
>> it from several projects and would like to see it together in the
>> Commons where it would have a wider use. And it is working fine
>> across a 500 class and 75 Kloc piece of code.
>>
>> My interest is to keep the functionality I have now without being
>> alone taking care of it. (Trying to cut on the above numbers.)
>> =:o)
>>
>>
>> If there is interest I can put it a "commons" package and post it
>> tomorrow.
>>
>>
>> Have fun,
>> Paulo Gaspar
>>
>>
>>> -----Original Message-----
>>> From: robert burrell donkin [mailto:robertdonkin@mac.com]
>>> Sent: Thursday, December 20, 2001 11:20 PM
>>> To: Jakarta Commons Developers List
>>> Subject: (Logging)[Proposal] A little refactoring
>>>
>>>
>>> i've been adding logging (using commons-logging) into betwixt and found
>>> that commons-logging is a little bit broken. rather than fix the
>>> symptom -
>>> that the log level constants were altered a little and that broke
>>> a lot of
>>> code - i'd prefer to refactor by introducing an abstract implementation
>>> Log that handles the log level logic (ie. stops calls going to the
>>> implementation implementation) and make the existing implementations
>>> inherit. hopefully this would stop logging breaking like that again.
>>>
>>> i'm willing to code these changes if this plan's acceptable.
>>>
>>> - robert
>>>
>>>
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>>
>>
>> --
>> To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.
>> org>
>> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.
>> org>
>>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: (Logging)[Proposal] A little refactoring
Posted by robert burrell donkin <ro...@mac.com>.
commons-logging is currently broken. i think that it shound be fixed.
maybe paulo's suggestion would make more sense as a competing branch -
commons-logging 2.0? that way, people can take a look at the actual code
but we don't have to stop development on other components until it's
finished.
- robert
On Thursday, December 20, 2001, at 11:23 PM, Paulo Gaspar wrote:
> That was THE reason why I adopted Avalon new wrappers instead. I ported
> them out of Avalon and they work just fine. There are NO dependencies
> from the rest of the framework except for a formatter that can be
> dropped.
>
> I also improved (IMHO) an existing AbstractLoggable class and I am now
> porting an XML based configurator for LogKit from Avalon Excalibur. This
> one has more dependencies but it is ok.
>
> Next I will adapt the simple property configuration code for LogKit and
> Log4J used at Velocity, (will looking at Turbine too).
>
> So, this set includes:
> - Wrappers for Log4J, LogKit and the JDK 1.4 Logging API;
> - Really simple internal logger + NoOp logger;
> - Log4J has its own XML configuration and LogKit gets one;
> - Ability to use a hierarchy of loggers in an API independent way.
> Only the configuration is API dependent.
>
> Will soon (next week) include simple property configuration.
>
> Still no plans on evolving the JDK 1.4 Logging API.
>
>
> This is the best logging code I found around Jakarta. It just picked
> it from several projects and would like to see it together in the
> Commons where it would have a wider use. And it is working fine
> across a 500 class and 75 Kloc piece of code.
>
> My interest is to keep the functionality I have now without being
> alone taking care of it. (Trying to cut on the above numbers.)
> =:o)
>
>
> If there is interest I can put it a "commons" package and post it
> tomorrow.
>
>
> Have fun,
> Paulo Gaspar
>
>
>> -----Original Message-----
>> From: robert burrell donkin [mailto:robertdonkin@mac.com]
>> Sent: Thursday, December 20, 2001 11:20 PM
>> To: Jakarta Commons Developers List
>> Subject: (Logging)[Proposal] A little refactoring
>>
>>
>> i've been adding logging (using commons-logging) into betwixt and found
>> that commons-logging is a little bit broken. rather than fix the
>> symptom -
>> that the log level constants were altered a little and that broke
>> a lot of
>> code - i'd prefer to refactor by introducing an abstract implementation
>> Log that handles the log level logic (ie. stops calls going to the
>> implementation implementation) and make the existing implementations
>> inherit. hopefully this would stop logging breaking like that again.
>>
>> i'm willing to code these changes if this plan's acceptable.
>>
>> - robert
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>
> --
> To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.
> org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.
> org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: (Logging)[Proposal] A little refactoring
Posted by Paulo Gaspar <pa...@krankikom.de>.
That was THE reason why I adopted Avalon new wrappers instead. I ported
them out of Avalon and they work just fine. There are NO dependencies
from the rest of the framework except for a formatter that can be
dropped.
I also improved (IMHO) an existing AbstractLoggable class and I am now
porting an XML based configurator for LogKit from Avalon Excalibur. This
one has more dependencies but it is ok.
Next I will adapt the simple property configuration code for LogKit and
Log4J used at Velocity, (will looking at Turbine too).
So, this set includes:
- Wrappers for Log4J, LogKit and the JDK 1.4 Logging API;
- Really simple internal logger + NoOp logger;
- Log4J has its own XML configuration and LogKit gets one;
- Ability to use a hierarchy of loggers in an API independent way.
Only the configuration is API dependent.
Will soon (next week) include simple property configuration.
Still no plans on evolving the JDK 1.4 Logging API.
This is the best logging code I found around Jakarta. It just picked
it from several projects and would like to see it together in the
Commons where it would have a wider use. And it is working fine
across a 500 class and 75 Kloc piece of code.
My interest is to keep the functionality I have now without being
alone taking care of it. (Trying to cut on the above numbers.)
=:o)
If there is interest I can put it a "commons" package and post it
tomorrow.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: robert burrell donkin [mailto:robertdonkin@mac.com]
> Sent: Thursday, December 20, 2001 11:20 PM
> To: Jakarta Commons Developers List
> Subject: (Logging)[Proposal] A little refactoring
>
>
> i've been adding logging (using commons-logging) into betwixt and found
> that commons-logging is a little bit broken. rather than fix the
> symptom -
> that the log level constants were altered a little and that broke
> a lot of
> code - i'd prefer to refactor by introducing an abstract implementation
> Log that handles the log level logic (ie. stops calls going to the
> implementation implementation) and make the existing implementations
> inherit. hopefully this would stop logging breaking like that again.
>
> i'm willing to code these changes if this plan's acceptable.
>
> - robert
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
(Logging)[Proposal] A little refactoring
Posted by robert burrell donkin <ro...@mac.com>.
i've been adding logging (using commons-logging) into betwixt and found
that commons-logging is a little bit broken. rather than fix the symptom -
that the log level constants were altered a little and that broke a lot of
code - i'd prefer to refactor by introducing an abstract implementation
Log that handles the log level logic (ie. stops calls going to the
implementation implementation) and make the existing implementations
inherit. hopefully this would stop logging breaking like that again.
i'm willing to code these changes if this plan's acceptable.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Posted by James Strachan <ja...@yahoo.co.uk>.
+1 I agree also.
In the past I've found myself making the decision to go 'typesafe' or
'dynamic' when building systems - especially when user interfaces or
databases are involved.
Sometimes it makes perfect sense to hand craft write lots of JavaBeans for
domain objects like Customer, AccountSummary, Order and so forth. Sometimes,
particularly in user interface intensive applications, its easier to work
with 'DynaBeans' (I've often called them 'Records' in the past). A third
approach is to code generate the domain objects, like Torque does.
In many ways the decision to go 'typesafe' or 'generic' often depends on the
type of code you're developing.
If you are building a user interface, then a table doesn't really care
whether a row is a Customer or a DetailedCustomer or a Supplier type. Just
something that could (say) implement a swing TableModel will do. Wtih
DynaBeans you can implement a single TableModel implementation that displays
a list of DynaBeans in a Swing UI. However if you're developing some
domain-specific business logic, you probably want your code to be typesafe.
A couple more thoughts on the DynaBean idea.
BeanInfo
======
You could write a single BeanInfo class for DynaBean such that the default
java bean introspector would behave as if the dynabean were actually a real
bean. i.e. from the introspectors point of view, a DynaBean would look no
different from a hand-crafted bean. This would mean that any existing bean
code, such as BeanUtils, would work nicely with DynaBeans
If this were the case then developers could choose when to hand-craft these
beans or when to stay dynamic. This would lead to a nice XP style of working
with beans; use dynabeans to get things going, then when you need to write
business logic you could start refactoring DynaBeans into real, hand crafted
bean.
James
----- Original Message -----
From: "Scott Sanders" <ss...@nextance.com>
To: "'Jakarta Commons Developers List'" <co...@jakarta.apache.org>
Sent: Monday, December 17, 2001 6:27 PM
Subject: RE: [Design Discussion] DynaBean - JavaBeans with dynamic
properties
> Craig, +1 from me.
>
> Although I do believe in stringly typed systems, I also find a need for
> something 'Pythonesque' in my web applications. This would fit the bill
> excellently. We could also get these things to be compilable for
> performance, no?
>
> If you then have a framework that uses DynaBean as the value object, the
> back end could be raw JDBC, EJB, XML, or ??? Without even knowing it...
>
> I think it is an excellent idea, let's get started.
>
> Scott Sanders
>
> > -----Original Message-----
> > From: craigmcc@localhost [mailto:craigmcc@localhost] On
> > Behalf Of Craig R. McClanahan
> > Sent: Saturday, December 15, 2001 1:26 PM
> > To: commons-dev@jakarta.apache.org
> > Subject: [Design Discussion] DynaBean - JavaBeans with
> > dynamic properties
> >
> >
> > There's been a lot of interest, both here (COMMONS-DEV), on
> > the Struts mailing lists, and elsewhere in the idea of a
> > JavaBean-like thing where the set of properties can be
> > dynamically defined. If support for this was integrated into
> > the BeanUtils package in Commons, we could also make the
> > methods in BeanUtils and PropertyUtils treat the properties
> > of these beans like they do for regular JavaBeans, and thus
> > be able to leverage them in environments based on BeanUtils
> > (such as Struts).
> >
> > The purpose of this email is to summarize a set of design
> > requirements for discussion purposes, so we can coalesce on a
> > design and then get it implemented. For extra fun, I've
> > thrown in a very-raw idea of what the APIs might look like --
> > but I'd like to have the group's agreement before turning
> > that into code.
> >
> > Before embarking on the actual development of dynamic beans
> > support, we should also do a release of BeanUtils with the
> > current enhancements, to provide a stable starting point.
> >
> > Please let me know what you think!
> >
> >
> > BACKGROUND:
> >
> > The purpose of the DynaBean design (I'm not firmly attached
> > to the name, but kinda like it :-) is to support application
> > programming designs based on JavaBeans design patterns, but
> > where the static nature of JavaBeans themselves (i.e. the
> > fact that the set of properties is fixed at compile
> > time) is too restrictive. Some typical use cases for such a
> > capability:
> >
> > * A bean object that represents a Row from a JDBC ResultSet
> > (the names and types of the column properties cannot be known
> > in advance because they are based on the SELECT statement).
> >
> > * A way to construct and use "value objects" that extract the
> > properties of an EJB into a structure that can be utilized by a
> > presentation tier technology such as JSP pages, without having
> > to hand code the value object.
> >
> > * A way to capture *all* of the request parameters from a servlet
> > request as a single object.
> >
> > * A way to dynamically represnt XML input data as a tree of
> > Java objects.
> >
> >
> > DESIGN REQUIREMENTS:
> >
> > * Support a completely arbitrary set of properties and corresponding
> > values, with the ability to add and remove properties dynamically.
> >
> > * Support the ability to dynamically register the set of property
> > names that are allowed, and then enforce storing only those
> > property names.
> >
> > * Support the ability to register data types (Java classes) for each
> > property, along with the names, with automatic type checking.
> >
> > * Support for properties with scalar types, array types, and
> > "mapped" types (as currently supported in Beanutils).
> >
> > * Support "simple" and "indexed" property getters and setters
> > in a style similar to standard JavaBeans.
> >
> > * Support registration of property change listeners and broadcast
> > of property change events
> >
> > * Provide the basic DynaBean API as a Java interface, as well as a
> > convenience base class, so that applications can adopt it however
> > they wish.
> >
> > * Base implementation class should implement Serializable so that
> > DynaBeans can be serialized and deserialized (assuming that the
> > actual property values can be).
> >
> > * Transparently support DynaBean objects in the existing BeanUtils
> > and PropertyUtils classes of the Bean Utilities package.
> >
> > * To the maximum extent feasible, provide JavaBeans-like introspection
> > capabilities of the available properties. May require an
> > IntrospectionUtils addition to the Beanutils package.
> >
> >
> > CONCEPTUAL API:
> >
> > public interface DynaBean {
> >
> >
> > //
> > ----------------------------------------------------------------
> > // Dynamic property configuration
> > //
> > ----------------------------------------------------------------
> >
> > void addDynamic(String name); // Unrestricted type
> > void addDynamic(String name, Class type); // Restricted type
> > void removeDyanamic(String name); // Remove
> > property & value
> > void restrictDynamic(boolean restrict); // Are property names
> > // restricted
> > to registered
> > // ones?
> > (default=false)
> > // (can be changed)
> >
> > //
> > ----------------------------------------------------------------
> > // Property getters and setters. Behavior on previously
> > // unknown property names depends on the restrict setting
> > //
> > ----------------------------------------------------------------
> >
> > // Does this bean have a property of the specified name?
> > boolean contains(String name);
> >
> > // Getters return null on unknown property names
> > Object get(String name); // Simple
> > Object get(String name, int index); // Indexed
> > Object get(String name, String key); // Mapped
> >
> > // Setters are allowed to set null unless property is native.
> > // Optionally throw IllegalArgumentException if type is restricted
> > // and the value argument is not assignment-compatible
> > void set(String name, Object value); // Simple
> > void set(String name, int index, // Indexed
> > Object value);
> > void set(String name, String key, // Mapped
> >
> > }
> >
> >
> > Craig McClanahan
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 17 Dec 2001, Scott Sanders wrote:
> Date: Mon, 17 Dec 2001 10:27:24 -0800
> From: Scott Sanders <ss...@nextance.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>,
> ssanders@nextance.com
> To: 'Jakarta Commons Developers List' <co...@jakarta.apache.org>
> Subject: RE: [Design Discussion] DynaBean - JavaBeans with dynamic
> properties
>
> Craig, +1 from me.
>
> Although I do believe in stringly typed systems, I also find a need for
> something 'Pythonesque' in my web applications. This would fit the bill
> excellently.
I agree ... I will be incorporating the excellent feedback over the
weekend into an updated proposal in the next couple of days.
> We could also get these things to be compilable for
> performance, no?
Well, you could conceive of generating a JavaBean class that has all the
right properties, but then you give up the ability to dynamically adjust
them on the fly ...
In 1.4, the performance gap between direct and reflected calls has been
reduced significantly if you cache the actual Method instances (BeanUtils
doesn't do this yet, but will soon). It's getting to the point where
performance shouldn't have to dominate the decision making process any
more -- we can base it on what makes for the most maintainable and
reliable code instead.
>
> If you then have a framework that uses DynaBean as the value object, the
> back end could be raw JDBC, EJB, XML, or ??? Without even knowing it...
>
Only the conversion layer between the value object and the underlying bean
would have to know.
> I think it is an excellent idea, let's get started.
>
> Scott Sanders
>
Craig
> > -----Original Message-----
> > From: craigmcc@localhost [mailto:craigmcc@localhost] On
> > Behalf Of Craig R. McClanahan
> > Sent: Saturday, December 15, 2001 1:26 PM
> > To: commons-dev@jakarta.apache.org
> > Subject: [Design Discussion] DynaBean - JavaBeans with
> > dynamic properties
> >
> >
> > There's been a lot of interest, both here (COMMONS-DEV), on
> > the Struts mailing lists, and elsewhere in the idea of a
> > JavaBean-like thing where the set of properties can be
> > dynamically defined. If support for this was integrated into
> > the BeanUtils package in Commons, we could also make the
> > methods in BeanUtils and PropertyUtils treat the properties
> > of these beans like they do for regular JavaBeans, and thus
> > be able to leverage them in environments based on BeanUtils
> > (such as Struts).
> >
> > The purpose of this email is to summarize a set of design
> > requirements for discussion purposes, so we can coalesce on a
> > design and then get it implemented. For extra fun, I've
> > thrown in a very-raw idea of what the APIs might look like --
> > but I'd like to have the group's agreement before turning
> > that into code.
> >
> > Before embarking on the actual development of dynamic beans
> > support, we should also do a release of BeanUtils with the
> > current enhancements, to provide a stable starting point.
> >
> > Please let me know what you think!
> >
> >
> > BACKGROUND:
> >
> > The purpose of the DynaBean design (I'm not firmly attached
> > to the name, but kinda like it :-) is to support application
> > programming designs based on JavaBeans design patterns, but
> > where the static nature of JavaBeans themselves (i.e. the
> > fact that the set of properties is fixed at compile
> > time) is too restrictive. Some typical use cases for such a
> > capability:
> >
> > * A bean object that represents a Row from a JDBC ResultSet
> > (the names and types of the column properties cannot be known
> > in advance because they are based on the SELECT statement).
> >
> > * A way to construct and use "value objects" that extract the
> > properties of an EJB into a structure that can be utilized by a
> > presentation tier technology such as JSP pages, without having
> > to hand code the value object.
> >
> > * A way to capture *all* of the request parameters from a servlet
> > request as a single object.
> >
> > * A way to dynamically represnt XML input data as a tree of
> > Java objects.
> >
> >
> > DESIGN REQUIREMENTS:
> >
> > * Support a completely arbitrary set of properties and corresponding
> > values, with the ability to add and remove properties dynamically.
> >
> > * Support the ability to dynamically register the set of property
> > names that are allowed, and then enforce storing only those
> > property names.
> >
> > * Support the ability to register data types (Java classes) for each
> > property, along with the names, with automatic type checking.
> >
> > * Support for properties with scalar types, array types, and
> > "mapped" types (as currently supported in Beanutils).
> >
> > * Support "simple" and "indexed" property getters and setters
> > in a style similar to standard JavaBeans.
> >
> > * Support registration of property change listeners and broadcast
> > of property change events
> >
> > * Provide the basic DynaBean API as a Java interface, as well as a
> > convenience base class, so that applications can adopt it however
> > they wish.
> >
> > * Base implementation class should implement Serializable so that
> > DynaBeans can be serialized and deserialized (assuming that the
> > actual property values can be).
> >
> > * Transparently support DynaBean objects in the existing BeanUtils
> > and PropertyUtils classes of the Bean Utilities package.
> >
> > * To the maximum extent feasible, provide JavaBeans-like introspection
> > capabilities of the available properties. May require an
> > IntrospectionUtils addition to the Beanutils package.
> >
> >
> > CONCEPTUAL API:
> >
> > public interface DynaBean {
> >
> >
> > //
> > ----------------------------------------------------------------
> > // Dynamic property configuration
> > //
> > ----------------------------------------------------------------
> >
> > void addDynamic(String name); // Unrestricted type
> > void addDynamic(String name, Class type); // Restricted type
> > void removeDyanamic(String name); // Remove
> > property & value
> > void restrictDynamic(boolean restrict); // Are property names
> > // restricted
> > to registered
> > // ones?
> > (default=false)
> > // (can be changed)
> >
> > //
> > ----------------------------------------------------------------
> > // Property getters and setters. Behavior on previously
> > // unknown property names depends on the restrict setting
> > //
> > ----------------------------------------------------------------
> >
> > // Does this bean have a property of the specified name?
> > boolean contains(String name);
> >
> > // Getters return null on unknown property names
> > Object get(String name); // Simple
> > Object get(String name, int index); // Indexed
> > Object get(String name, String key); // Mapped
> >
> > // Setters are allowed to set null unless property is native.
> > // Optionally throw IllegalArgumentException if type is restricted
> > // and the value argument is not assignment-compatible
> > void set(String name, Object value); // Simple
> > void set(String name, int index, // Indexed
> > Object value);
> > void set(String name, String key, // Mapped
> >
> > }
> >
> >
> > Craig McClanahan
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Posted by Scott Sanders <ss...@nextance.com>.
Craig, +1 from me.
Although I do believe in stringly typed systems, I also find a need for
something 'Pythonesque' in my web applications. This would fit the bill
excellently. We could also get these things to be compilable for
performance, no?
If you then have a framework that uses DynaBean as the value object, the
back end could be raw JDBC, EJB, XML, or ??? Without even knowing it...
I think it is an excellent idea, let's get started.
Scott Sanders
> -----Original Message-----
> From: craigmcc@localhost [mailto:craigmcc@localhost] On
> Behalf Of Craig R. McClanahan
> Sent: Saturday, December 15, 2001 1:26 PM
> To: commons-dev@jakarta.apache.org
> Subject: [Design Discussion] DynaBean - JavaBeans with
> dynamic properties
>
>
> There's been a lot of interest, both here (COMMONS-DEV), on
> the Struts mailing lists, and elsewhere in the idea of a
> JavaBean-like thing where the set of properties can be
> dynamically defined. If support for this was integrated into
> the BeanUtils package in Commons, we could also make the
> methods in BeanUtils and PropertyUtils treat the properties
> of these beans like they do for regular JavaBeans, and thus
> be able to leverage them in environments based on BeanUtils
> (such as Struts).
>
> The purpose of this email is to summarize a set of design
> requirements for discussion purposes, so we can coalesce on a
> design and then get it implemented. For extra fun, I've
> thrown in a very-raw idea of what the APIs might look like --
> but I'd like to have the group's agreement before turning
> that into code.
>
> Before embarking on the actual development of dynamic beans
> support, we should also do a release of BeanUtils with the
> current enhancements, to provide a stable starting point.
>
> Please let me know what you think!
>
>
> BACKGROUND:
>
> The purpose of the DynaBean design (I'm not firmly attached
> to the name, but kinda like it :-) is to support application
> programming designs based on JavaBeans design patterns, but
> where the static nature of JavaBeans themselves (i.e. the
> fact that the set of properties is fixed at compile
> time) is too restrictive. Some typical use cases for such a
> capability:
>
> * A bean object that represents a Row from a JDBC ResultSet
> (the names and types of the column properties cannot be known
> in advance because they are based on the SELECT statement).
>
> * A way to construct and use "value objects" that extract the
> properties of an EJB into a structure that can be utilized by a
> presentation tier technology such as JSP pages, without having
> to hand code the value object.
>
> * A way to capture *all* of the request parameters from a servlet
> request as a single object.
>
> * A way to dynamically represnt XML input data as a tree of
> Java objects.
>
>
> DESIGN REQUIREMENTS:
>
> * Support a completely arbitrary set of properties and corresponding
> values, with the ability to add and remove properties dynamically.
>
> * Support the ability to dynamically register the set of property
> names that are allowed, and then enforce storing only those
> property names.
>
> * Support the ability to register data types (Java classes) for each
> property, along with the names, with automatic type checking.
>
> * Support for properties with scalar types, array types, and
> "mapped" types (as currently supported in Beanutils).
>
> * Support "simple" and "indexed" property getters and setters
> in a style similar to standard JavaBeans.
>
> * Support registration of property change listeners and broadcast
> of property change events
>
> * Provide the basic DynaBean API as a Java interface, as well as a
> convenience base class, so that applications can adopt it however
> they wish.
>
> * Base implementation class should implement Serializable so that
> DynaBeans can be serialized and deserialized (assuming that the
> actual property values can be).
>
> * Transparently support DynaBean objects in the existing BeanUtils
> and PropertyUtils classes of the Bean Utilities package.
>
> * To the maximum extent feasible, provide JavaBeans-like introspection
> capabilities of the available properties. May require an
> IntrospectionUtils addition to the Beanutils package.
>
>
> CONCEPTUAL API:
>
> public interface DynaBean {
>
>
> //
> ----------------------------------------------------------------
> // Dynamic property configuration
> //
> ----------------------------------------------------------------
>
> void addDynamic(String name); // Unrestricted type
> void addDynamic(String name, Class type); // Restricted type
> void removeDyanamic(String name); // Remove
> property & value
> void restrictDynamic(boolean restrict); // Are property names
> // restricted
> to registered
> // ones?
> (default=false)
> // (can be changed)
>
> //
> ----------------------------------------------------------------
> // Property getters and setters. Behavior on previously
> // unknown property names depends on the restrict setting
> //
> ----------------------------------------------------------------
>
> // Does this bean have a property of the specified name?
> boolean contains(String name);
>
> // Getters return null on unknown property names
> Object get(String name); // Simple
> Object get(String name, int index); // Indexed
> Object get(String name, String key); // Mapped
>
> // Setters are allowed to set null unless property is native.
> // Optionally throw IllegalArgumentException if type is restricted
> // and the value argument is not assignment-compatible
> void set(String name, Object value); // Simple
> void set(String name, int index, // Indexed
> Object value);
> void set(String name, String key, // Mapped
>
> }
>
>
> Craig McClanahan
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Posted by Vincent Massol <vm...@octo.com>.
+1 for all :-)
> -----Original Message-----
> From: craigmcc@localhost [mailto:craigmcc@localhost] On Behalf Of
Craig R.
> McClanahan
> Sent: 15 December 2001 21:26
> To: commons-dev@jakarta.apache.org
> Subject: [Design Discussion] DynaBean - JavaBeans with dynamic
properties
>
> There's been a lot of interest, both here (COMMONS-DEV), on the Struts
> mailing lists, and elsewhere in the idea of a JavaBean-like thing
where
> the set of properties can be dynamically defined. If support for this
was
> integrated into the BeanUtils package in Commons, we could also make
the
> methods in BeanUtils and PropertyUtils treat the properties of these
beans
> like they do for regular JavaBeans, and thus be able to leverage them
in
> environments based on BeanUtils (such as Struts).
>
> The purpose of this email is to summarize a set of design requirements
for
> discussion purposes, so we can coalesce on a design and then get it
> implemented. For extra fun, I've thrown in a very-raw idea of what
the
> APIs might look like -- but I'd like to have the group's agreement
before
> turning that into code.
>
> Before embarking on the actual development of dynamic beans support,
we
> should also do a release of BeanUtils with the current enhancements,
to
> provide a stable starting point.
>
> Please let me know what you think!
>
>
> BACKGROUND:
>
> The purpose of the DynaBean design (I'm not firmly attached to the
name,
> but kinda like it :-) is to support application programming designs
based
> on JavaBeans design patterns, but where the static nature of JavaBeans
> themselves (i.e. the fact that the set of properties is fixed at
compile
> time) is too restrictive. Some typical use cases for such a
capability:
>
> * A bean object that represents a Row from a JDBC ResultSet
> (the names and types of the column properties cannot be known
> in advance because they are based on the SELECT statement).
>
> * A way to construct and use "value objects" that extract the
> properties of an EJB into a structure that can be utilized by a
> presentation tier technology such as JSP pages, without having
> to hand code the value object.
>
> * A way to capture *all* of the request parameters from a servlet
> request as a single object.
>
> * A way to dynamically represnt XML input data as a tree of Java
objects.
>
>
> DESIGN REQUIREMENTS:
>
> * Support a completely arbitrary set of properties and corresponding
> values, with the ability to add and remove properties dynamically.
>
> * Support the ability to dynamically register the set of property
> names that are allowed, and then enforce storing only those
> property names.
>
> * Support the ability to register data types (Java classes) for each
> property, along with the names, with automatic type checking.
>
> * Support for properties with scalar types, array types, and
> "mapped" types (as currently supported in Beanutils).
>
> * Support "simple" and "indexed" property getters and setters
> in a style similar to standard JavaBeans.
>
> * Support registration of property change listeners and broadcast
> of property change events
>
> * Provide the basic DynaBean API as a Java interface, as well as a
> convenience base class, so that applications can adopt it however
> they wish.
>
> * Base implementation class should implement Serializable so that
> DynaBeans can be serialized and deserialized (assuming that the
> actual property values can be).
>
> * Transparently support DynaBean objects in the existing BeanUtils
> and PropertyUtils classes of the Bean Utilities package.
>
> * To the maximum extent feasible, provide JavaBeans-like introspection
> capabilities of the available properties. May require an
> IntrospectionUtils addition to the Beanutils package.
>
>
> CONCEPTUAL API:
>
> public interface DynaBean {
>
>
> //
----------------------------------------------------------------
> // Dynamic property configuration
> //
----------------------------------------------------------------
>
> void addDynamic(String name); // Unrestricted type
> void addDynamic(String name, Class type); // Restricted type
> void removeDyanamic(String name); // Remove property &
value
> void restrictDynamic(boolean restrict); // Are property names
> // restricted to
registered
> // ones?
(default=false)
> // (can be changed)
>
> //
----------------------------------------------------------------
> // Property getters and setters. Behavior on previously
> // unknown property names depends on the restrict setting
> //
----------------------------------------------------------------
>
> // Does this bean have a property of the specified name?
> boolean contains(String name);
>
> // Getters return null on unknown property names
> Object get(String name); // Simple
> Object get(String name, int index); // Indexed
> Object get(String name, String key); // Mapped
>
> // Setters are allowed to set null unless property is native.
> // Optionally throw IllegalArgumentException if type is restricted
> // and the value argument is not assignment-compatible
> void set(String name, Object value); // Simple
> void set(String name, int index, // Indexed
> Object value);
> void set(String name, String key, // Mapped
>
> }
>
>
> Craig McClanahan
>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:commons-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-
> help@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>