Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <20021119093723.13555.qmail@web40609.mail.yahoo.com>
Date: Tue, 19 Nov 2002 10:37:23 +0100 (CET)
From: =?iso-8859-1?q?Jon=20Tirs=E9n?= <jon_tirsen@yahoo.com>
Reply-To: jon@tirsen.com
Subject: RE: [attributes] Jakarta Commons Attributes, Nanning & XRAI
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <00cd01c28f4e$61e65020$7c29d9d5@e2>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

 --- Ara Abrahamian <ara_e_w@yahoo.com> skrev: > > Ok,
so maybe we just have to change our mind. What
> you are proposing
> is
> > that commons-attributes is the de facto
> runtime-implementation of
> > attributes. It could still be pluggable but we
> have a very rich
> default
> > implementation derived from the XRAI effort. Did I
> understand this
> > correctly?
> 
> Yes.

Ok, does everybody agree on this? James? Aslak?

> > My opinion on this: Sure, I could do that. One
> very important thing on
> > my agenda is timing. I think we need to focus on
> having a 1.0 with the
> > least possible functionality that is usable out
> during this year. Then
> > we would have time experimenting with the other
> cool features you've
> > been talking about. If we could agree on this I'm
> all for it.
> 
> I proposed a timeline like this:
> 
> v0.1 = abstract serialization api (like xrai) with
> default serialization
> of .ser object stream files,
> Attribute+DefaultAttribute classes with the
> simple implementation,
> ClassMetaData/DefaultClassMetaData, a smart ant
> task

Okay, I propose this to be 1.0. For several reasons.
One being that there will be a bunch of issues we need
to resolve after moving beyond this step. One of the
must difficult one being how to map attribute-names to
attribute-classes, and wheather these
attribute-classes will need to be available at
runtime. By nature this will be experimental and we
should try different approaches before we settle on
something. Another reason is that this is actually
quite useful.

This is almost what's in the CVS right now. We just
need to do the ClassMetaData-refactoring and it's
exactly what you're proposing (API-wise). Maybe some
more work on the Ant-task too.

Also we really need to discuss serialization. I think
we can do without that in all cases. Serialization is
(very, very) not recommended for long-term storage.
And for good reasons, almost every time I've tried
this it's blown up in my face. There's also major
performance issues.

The attributes are being created from strings in the
first place (all attributes are strings in the
source-code) so there's no reason we can't store these
strings and recreate the attribute at runtime. This
way we would also gracefully handle issues where
attribute-classes has been changed since the last
compile. They will be reparsed and revalidated. (For
example if you've upgraded a library in the
classpath.) Another thing is that you can edit these
strings without needing to recompile.

Serialization on the other hand is not very change
resilient. If the attribute changes after you've
serialized them it's simply gonna break. It's good for
short-term marshalling, like RMI for example. Long
term storage on the other hand, there are plenty of
other technologies that's better to use for this.

> v0.2 = Attribute metadata:
> isClassLevel/getLevel/etc, hence a simple
> form of validation of what user entered
> 
> v0.3 = CustomAttribute
> 
> v0.4 = XmlAttribute
> 
> v0.5 = BCEL attributes

I think all these can go after 1.0. I subscribe to the
release-early release-often style of process. We need
to get this out on the streets and see what the users
want, get them used to the technology. Also promoting
runtime attributes with real examples is what's
highest on my agenda, there's just so many libraries
I'm using that would be so better if they supported
runtime attriubtes. Then we'll see what kind of
technology the community needs.

> v0.1 can be out in 2 weeks, it's mostly xrai stuff
> refactored a bit.

Sure.

> > > There are other methods in Attribute too,
> metadata of the
> > > attribute: int getLevel() -> a bitset of the
> levels the
> > > attribute is applicable to,
> method/class/field/constructor/package
> > > some convenience methods like:
> isClassLevel/isMethodLevel/etc
> > >
> > > These methods help us do validation on user's
> input.
> > 
> > Ok, seems nice. Do we really need a bitset thingy?
> Doesn't just the
> > predicates do? Bitsets are ugly and seems so old
> and outdated.
> 
> I had something like Class.getModifiers() in my
> mind.

Yeah, I'm not very fond of that. Is there any other
example of using a bitset in the JDK? Any other
well-designed library? But sure if that's the easiest
way to do it, what the heck.

> > Hmm... ClassMetaData but PackageAttribute? Then
> let's name that
> > PackageMetaData too.
> 
> Typo, I meant PackageMetaData.

Ok.

> > One more thing. Don't we need to add a
> validate()-method to Attribute
> so
> > attributes can hook in and check wheather they've
> got all the
> parameters
> > they require and so on? This will be called
> runtime (when
> demarshalling
> > attributes, attribute-implementation may have
> changed since
> > compile-time) and compile-time (before marshalling
> attributes).
> 
> Yup! A validate() method to validate the attribute
> after all the
> parameters are set. An EjbAttribute will check
> whether the class is a
> subclass of EJBObject for example. So we need to
> pass in some context
> data. I'm afraid we have to pass xdoclet's XClass or
> qdox' SourceClass.
> And if we're going to validate in runtime too then
> it's trickier! Let's
> see what we come up with in v0.2.

Yeah, you're right, it needs some context. Don't you
think it's enough that we pass in the
Field/Method/Class it's bound too, and the actual text
of the attribute?
We needs some different examples and see what support
they need for validation. But it might be better to do
this later on, true.

Once again I'm gonna throw in a plug for just storing
the attribute-strings. If commons-attributes changes
to use another validation-scheme it could still use
the compiled attribute-strings and validation would at
runtime be using the new validation-scheme.

_____________________________________________________
Gratis e-mail resten av livet p� www.yahoo.se/mail
Busenkelt!

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>