You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by robert burrell donkin <ro...@blueyonder.co.uk> on 2004/03/04 23:43:42 UTC
[jelly] basic JAXB/jaxme tag library
i now have a basic but working JaxMe tag library. this will generate,
marshall and unmarshal. JaxMe is the apache JAXB implementation. there
are a few issues remaining:
1. i can either submit this as a patch or just go ahead and commit.
2. the marshaling and unmarshalling tags only depend on the JaxMe
clean-room JAXB API implementation and so could (potentially) be used
with any other implementation. the generation tag is JaxMe specific. i
could factor into two separate tag libraries JAXB and jaxme or just
one.
3. i need to sort out the uploading of the last jaxme release into the
apache repository.
any opinions about the right solutions?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] basic JAXB/jaxme tag library
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
there are a few little wrinkles with the repository (and there's a
storm about to hit the java community at apache concerning future
releases) but once things are in place, i'll commit into the directory
you suggest.
BTW i'm getting a failure when building the site documentation down in
the beanshell tag library. is this a known issue or should i try to
look into it?
- robert
On 11 Mar 2004, at 09:34, Paul Libbrecht wrote:
> OK, so you are comitting right away a directory jaxme in
> jelly/jelly-tags, right?
>
> thanks
>
> paul
>
>
> On 10-Mar-04, at 22:14 Uhr, robert burrell donkin wrote:
>
>> dims and the web services pmc arranged the implementation and i think
>> they probably know what they're doing.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] basic JAXB/jaxme tag library
Posted by Paul Libbrecht <pa...@activemath.org>.
OK, so you are comitting right away a directory jaxme in
jelly/jelly-tags, right?
thanks
paul
On 10-Mar-04, at 22:14 Uhr, robert burrell donkin wrote:
> dims and the web services pmc arranged the implementation and i think
> they probably know what they're doing.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] basic JAXB/jaxme tag library
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 9 Mar 2004, at 23:08, Paul Libbrecht wrote:
> On 9-Mar-04, at 23:54 Uhr, robert burrell donkin wrote:
>> the specification download grants a limited license to implement the
>> specification (including classes with the javax package space) from
>> the specification but it's easy and safer for an organization like
>> apache to do this than an individual. dims (as web services chair)
>> has access to legal resources and experience of clean room
>> implementations.
>
> But I'm not talking about releasing an implementation, just about
> releasing a .java and its compilation with package-name javax.
AIUI jaxme is an implementation of that specification and includes
clean room implementation classes in the javax package. that's
specifically allowed by the specification (you can download the
specification and create a clean room implementation). of course,
particular people may be prevented from creating clean room
implementations (by previous license agreements) but providing you're
haven't signed anything like that, you can create an implementation in
the javax package space working from that specification.
i'm not an expert and you've now reached the end of my knowledge :)
dims and the web services pmc arranged the implementation and i think
they probably know what they're doing.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [id] use of commons-logging
Posted by Phil Steitz <ph...@steitz.com>.
Stephen Colebourne wrote:
> I'll admit to being surprised that [id] has any dependencies. When it was
> created I was assuing that none would be needed.
> Stephen
>
Currently, we depend on [discovery], essentially to make implementation
decisions pluggable / configurable. This brings [logging]. We also
depend on [codec] (for part of the uuid impl). If you have ideas about
how these dependencies could be removed without (significant) loss, and
you see them as a problem / limitation, please feel free to jump with
suggestions or changes at any time ;-)
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [id] use of commons-logging
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I'll admit to being surprised that [id] has any dependencies. When it was
created I was assuing that none would be needed.
Stephen
----- Original Message -----
From: "Tim Reilly" <ti...@consultant.com>
> Since there is a dependency on commons-logging; any issues with using it?
>
> For example in IdentifierGeneratorFactory.java line 53
>
> - } catch (Exception ex) {
> - // ignore as default implementation will be used.
> + }
> + catch (Exception ex) {
> + if (log.isInfoEnabled()) {
> + log.info(ex);
> + }
>
> There are two other similar places in the uuid packages I was think it
might
> be useful to log what's happening in the recoverable exceptions.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [id] use of commons-logging
Posted by Phil Steitz <ph...@steitz.com>.
Tim Reilly wrote:
> Since there is a dependency on commons-logging; any issues with using it?
>
> For example in IdentifierGeneratorFactory.java line 53
>
> - } catch (Exception ex) {
> - // ignore as default implementation will be used.
> + }
> + catch (Exception ex) {
> + if (log.isInfoEnabled()) {
> + log.info(ex);
> + }
>
> There are two other similar places in the uuid packages I was think it might
> be useful to log what's happening in the recoverable exceptions.
>
I would be -1 to the change above, since the "no configuration present, so
use default" situation is not really exceptional. I would be careful
adding logging elsewhere if there is any chance that it will end up
generating a large volume of log messages under normal circumstances.
Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [id] use of commons-logging
Posted by Tim Reilly <ti...@consultant.com>.
Since there is a dependency on commons-logging; any issues with using it?
For example in IdentifierGeneratorFactory.java line 53
- } catch (Exception ex) {
- // ignore as default implementation will be used.
+ }
+ catch (Exception ex) {
+ if (log.isInfoEnabled()) {
+ log.info(ex);
+ }
There are two other similar places in the uuid packages I was think it might
be useful to log what's happening in the recoverable exceptions.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [id] hooking up UUID generation
Posted by Phil Steitz <ph...@steitz.com>.
Tim,
Sorry for the latency. My inclination would be to go with the different
names / classes for different versions. These look like different
identifiers to me.
Phil
Tim Reilly wrote:
> Any thoughts on "hooking-up" the UUID generation like the other id
> generators?
>
> I was thinking something along these lines:
> either:
> IdentifierUtils.nextUUID([UUID.VERSION_ONE | UUID.VERSION_FOUR]);
> -or-
> IdentifierUtils.nextVersionOneUUID();
> IdentifierUtils.nextVersionFourUUID([void | boolean:secure]);
>
> And same thought on the factory:
> either:
> IdentifierGeneratorFactory factory =
> IdentifierGeneratorFactory.newInstance();
> UUIDGenerator generator = factory.uuidGenerator(UUID.VERSION_ONE |
> UUID.VERSION_FOUR);
> -or-
> VersionOneGenerator generator = factory.uuidVersionOneGenerator();
> VersionFourGenerator generator = factory.uuidVersionFourGenerator();
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[id] hooking up UUID generation
Posted by Tim Reilly <ti...@consultant.com>.
Any thoughts on "hooking-up" the UUID generation like the other id
generators?
I was thinking something along these lines:
either:
IdentifierUtils.nextUUID([UUID.VERSION_ONE | UUID.VERSION_FOUR]);
-or-
IdentifierUtils.nextVersionOneUUID();
IdentifierUtils.nextVersionFourUUID([void | boolean:secure]);
And same thought on the factory:
either:
IdentifierGeneratorFactory factory =
IdentifierGeneratorFactory.newInstance();
UUIDGenerator generator = factory.uuidGenerator(UUID.VERSION_ONE |
UUID.VERSION_FOUR);
-or-
VersionOneGenerator generator = factory.uuidVersionOneGenerator();
VersionFourGenerator generator = factory.uuidVersionFourGenerator();
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] basic JAXB/jaxme tag library
Posted by Paul Libbrecht <pa...@activemath.org>.
On 9-Mar-04, at 23:54 Uhr, robert burrell donkin wrote:
> the specification download grants a limited license to implement the
> specification (including classes with the javax package space) from
> the specification but it's easy and safer for an organization like
> apache to do this than an individual. dims (as web services chair) has
> access to legal resources and experience of clean room
> implementations.
But I'm not talking about releasing an implementation, just about
releasing a .java and its compilation with package-name javax.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] basic JAXB/jaxme tag library
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 9 Mar 2004, at 20:38, Paul Libbrecht wrote:
> On 9-Mar-04, at 20:55 Uhr, robert burrell donkin wrote:
>
>> On 9 Mar 2004, at 08:43, Paul Libbrecht wrote:
>>
>>> OK, so that doesn't solve the distribution of namespace.jar then
>>> which is one or two interfaces just like was jaxp.jar... or do I
>>> misunderstand ?
>>
>> these ship as part of the jaxmeapi. (again, these classes are clean
>> room implementations from the relevant specifications.) so it's just
>> one jar :)
>
> OK, I've finally downloaded and everything.
>
> Well, there seems to be the same magic between jaxbapi and xml-apis...
> namely, Apache licensed javax packages... I have no real problem with
> this but I remember explicitly reading just about everywhere in JDK
> licenses that I was not allowed to write things in packages java or
> javax...
>
> So Apache foundation maybe never did download JDK so does it for me
> and everyone is happy (I am, with such a license!), correct ?
that's the general idea.
the specification download grants a limited license to implement the
specification (including classes with the javax package space) from the
specification but it's easy and safer for an organization like apache
to do this than an individual. dims (as web services chair) has access
to legal resources and experience of clean room implementations.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] basic JAXB/jaxme tag library
Posted by Paul Libbrecht <pa...@activemath.org>.
On 9-Mar-04, at 20:55 Uhr, robert burrell donkin wrote:
> On 9 Mar 2004, at 08:43, Paul Libbrecht wrote:
>
>> OK, so that doesn't solve the distribution of namespace.jar then
>> which is one or two interfaces just like was jaxp.jar... or do I
>> misunderstand ?
>
> these ship as part of the jaxmeapi. (again, these classes are clean
> room implementations from the relevant specifications.) so it's just
> one jar :)
OK, I've finally downloaded and everything.
Well, there seems to be the same magic between jaxbapi and xml-apis...
namely, Apache licensed javax packages... I have no real problem with
this but I remember explicitly reading just about everywhere in JDK
licenses that I was not allowed to write things in packages java or
javax...
So Apache foundation maybe never did download JDK so does it for me and
everyone is happy (I am, with such a license!), correct ?
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] basic JAXB/jaxme tag library
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 9 Mar 2004, at 08:43, Paul Libbrecht wrote:
> OK, so that doesn't solve the distribution of namespace.jar then which
> is one or two interfaces just like was jaxp.jar... or do I
> misunderstand ?
these ship as part of the jaxmeapi. (again, these classes are clean
room implementations from the relevant specifications.) so it's just
one jar :)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] basic JAXB/jaxme tag library
Posted by Paul Libbrecht <pa...@activemath.org>.
OK, so that doesn't solve the distribution of namespace.jar then which
is one or two interfaces just like was jaxp.jar... or do I
misunderstand ?
paul
On 8-Mar-04, at 22:54 Uhr, robert burrell donkin wrote:
> On 7 Mar 2004, at 23:18, Paul Libbrecht wrote:
>
>> On 6-Mar-04, at 11:43 Uhr, robert burrell donkin wrote:
>>> he organized an apache licensed, clean room implementation of the
>>> required API (it's distributed as the JaxMeAPI).
>>
>> That sounds great (I presume it's already into the ibliblio
>> repository) but... does this mean that such an API is something that
>> sort of replaces the javax.xxx packages ?
>> If yes I fear this would be blatant violation of quite an amoount of
>> Sun licenses (as far as I've understood them), otherwise, how can
>> there be an interface with the interesting name ??
>
> (it's the jar that has an interesting name, not the classes. sorry for
> being a bit unclear.)
>
> AIUI the sun license (for the JAXB specification) allows the creation
> of API implementations (in the javax.xxx package space) from the
> specification providing that they are pure (no extensions) and
> compliant, clean room implementations of the specification. what isn't
> allowed are works derived from the JAXB standard implementation (used
> to be called the reference implementation).
>
> (IIRC the tomcat did something similar for one of the earlier servlet
> specifications.)
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] basic JAXB/jaxme tag library
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 7 Mar 2004, at 23:18, Paul Libbrecht wrote:
> On 6-Mar-04, at 11:43 Uhr, robert burrell donkin wrote:
>> he organized an apache licensed, clean room implementation of the
>> required API (it's distributed as the JaxMeAPI).
>
> That sounds great (I presume it's already into the ibliblio
> repository) but... does this mean that such an API is something that
> sort of replaces the javax.xxx packages ?
> If yes I fear this would be blatant violation of quite an amoount of
> Sun licenses (as far as I've understood them), otherwise, how can
> there be an interface with the interesting name ??
(it's the jar that has an interesting name, not the classes. sorry for
being a bit unclear.)
AIUI the sun license (for the JAXB specification) allows the creation
of API implementations (in the javax.xxx package space) from the
specification providing that they are pure (no extensions) and
compliant, clean room implementations of the specification. what isn't
allowed are works derived from the JAXB standard implementation (used
to be called the reference implementation).
(IIRC the tomcat did something similar for one of the earlier servlet
specifications.)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] basic JAXB/jaxme tag library
Posted by Paul Libbrecht <pa...@activemath.org>.
On 6-Mar-04, at 11:43 Uhr, robert burrell donkin wrote:
> he organized an apache licensed, clean room implementation of the
> required API (it's distributed as the JaxMeAPI).
That sounds great (I presume it's already into the ibliblio repository)
but... does this mean that such an API is something that sort of
replaces the javax.xxx packages ?
If yes I fear this would be blatant violation of quite an amoount of
Sun licenses (as far as I've understood them), otherwise, how can there
be an interface with the interesting name ??
I'm a bit surprised to this solution!
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] basic JAXB/jaxme tag library
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 5 Mar 2004, at 09:56, Paul Libbrecht wrote:
> On 4-Mar-04, at 23:43 Uhr, robert burrell donkin wrote:
<snip>
>> 2. the marshaling and unmarshalling tags only depend on the JaxMe
>> clean-room JAXB API implementation and so could (potentially) be used
>> with any other implementation.
>
> How about the jaxb API license ? Is it distributable ? I fear it's
> probably the worst in terms of the dependencies, just like JAXP...
> (plus you probably need the jaxp extensions like QName or namespace,
> or ?). Parts of this might be there if you managed to install the
> dependencies for messenger...
> These kind of horrible non-downloadable dependencies should be quite
> cared about, I think!
dims really is the man :)
he organized an apache licensed, clean room implementation of the
required API (it's distributed as the JaxMeAPI).
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] basic JAXB/jaxme tag library
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 5 Mar 2004, at 09:56, Paul Libbrecht wrote:
> On 4-Mar-04, at 23:43 Uhr, robert burrell donkin wrote:
<snip>
>> the generation tag is JaxMe specific. i could factor into two
>> separate tag libraries JAXB and jaxme or just one.
>
> Isn't JAXMe Apache ?
yep
> Then I don't think it's a problem... do it in one taglib...
ok
my thought was that users might want to be able to use the pure JAXB
(using the apache licensed clean room distribution of the API classes)
tags with different JAXB implementations. including the JaxMe specific
generator tag would probably limit the tag library just to the JaxMe
implementation.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] basic JAXB/jaxme tag library
Posted by Paul Libbrecht <pa...@activemath.org>.
On 4-Mar-04, at 23:43 Uhr, robert burrell donkin wrote:
> 1. i can either submit this as a patch or just go ahead and commit.
I'd go ahead and commit...
> 2. the marshaling and unmarshalling tags only depend on the JaxMe
> clean-room JAXB API implementation and so could (potentially) be used
> with any other implementation.
How about the jaxb API license ? Is it distributable ? I fear it's
probably the worst in terms of the dependencies, just like JAXP...
(plus you probably need the jaxp extensions like QName or namespace, or
?). Parts of this might be there if you managed to install the
dependencies for messenger...
These kind of horrible non-downloadable dependencies should be quite
cared about, I think!
> the generation tag is JaxMe specific. i could factor into two separate
> tag libraries JAXB and jaxme or just one.
Isn't JAXMe Apache ? Then I don't think it's a problem... do it in one
taglib...
> 3. i need to sort out the uploading of the last jaxme release into the
> apache repository.
> any opinions about the right solutions?
And if you even can manage a "tour-de-force" like the famous "xml-apis"
to include jaxb and related, that would even be greater!
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org