Nabble - Graffito - Dev

RE: confirm subscribe to graffito-dev@incubator.apache.org

2008-05-27T00:37:27Z

Hy I need to know how to uses graffito framework to development
application .

-----Original Message-----
From: graffito-dev-help@...
[mailto:graffito-dev-help@...]
Sent: Martes, 27 de Mayo de 2008 03:10 a.m.
To: Evelio Maikel Medina Manrique
Subject: confirm subscribe to graffito-dev@...

Hi! This is the ezmlm program. I'm managing the
graffito-dev@... mailing list.

I'm working for my owner, who can be reached
at graffito-dev-owner@....

To confirm that you would like

emedinam@...

added to the graffito-dev mailing list, please send
a short reply to this address:

graffito-dev-sc.1211872189.cnibjekggjjdmgcjaakp-emedinam=uci.cu@incubato
r.apache.org

Usually, this happens when you just hit the "reply" button.
If this does not work, simply copy the address and paste it into
the "To:" field of a new message.

or click here:

mailto:graffito-dev-sc.1211872189.cnibjekggjjdmgcjaakp-emedinam=uci.cu@i
ncubator.apache.org

This confirmation serves two purposes. First, it verifies that I am able
to get mail through to you. Second, it protects you in case someone
forges a subscription request in your name.

Some mail programs are broken and cannot handle long addresses. If you
cannot reply to this request, instead send a message to
<graffito-dev-request@...> and put the
entire address listed above into the "Subject:" line.

--- Administrative commands for the graffito-dev list ---

I can handle administrative requests automatically. Please
do not send them to the list address! Instead, send
your message to the correct command address:

To subscribe to the list, send a message to:
<graffito-dev-subscribe@...>

To remove your address from the list, send a message to:
<graffito-dev-unsubscribe@...>

Send mail to the following for info and FAQ for this list:
<graffito-dev-info@...>
<graffito-dev-faq@...>

Similar addresses exist for the digest list:
<graffito-dev-digest-subscribe@...>
<graffito-dev-digest-unsubscribe@...>

To get messages 123 through 145 (a maximum of 100 per request), mail:
<graffito-dev-get.123_145@...>

To get an index with subject and author for messages 123-456 , mail:
<graffito-dev-index.123_456@...>

They are always returned as sets of 100, max 2000 per request,
so you'll actually get 100-499.

To receive all messages with the same subject as message 12345,
send a short message to:
<graffito-dev-thread.12345@...>

The messages do not really need to be empty, but I will ignore
their content. Only the ADDRESS you send to is important.

You can start a subscription for an alternate address,
for example "john@...", just add a hyphen and your
address (with '=' instead of '@') after the command word:
<graffito-dev-subscribe-john=host.domain@...>

To stop subscription for this address, mail:
<graffito-dev-unsubscribe-john=host.domain@...>

In both cases, I'll send a confirmation message to that address. When
you receive it, simply reply to it to complete your subscription.

If despite following these instructions, you do not get the
desired results, please contact my owner at
graffito-dev-owner@.... Please be patient, my owner is
a
lot slower than I am ;-)

--- Enclosed is a copy of the request I received.

Return-Path: <emedinam@...>
Received: (qmail 60349 invoked by uid 99); 27 May 2008 07:09:49 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 May 2008 00:09:49
-0700
X-ASF-Spam-Status: No, hits=-1.1 required=10.0

tests=ASF_EMPTY_LIST_OPS,ASF_LIST_OPS,EMPTY_MESSAGE,HTML_MESSAGE,MIME_HT
ML_MOSTLY,MISSING_SUBJECT,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of emedinam@...
designates 200.55.140.180 as permitted sender)
Received: from [200.55.140.180] (HELO mx3.uci.cu) (200.55.140.180)
by apache.org (qpsmtpd/0.29) with SMTP; Tue, 27 May 2008 07:08:56
+0000
Received: (qmail 18536 invoked by uid 507); 27 May 2008 07:09:11 -0000
Received: from 10.0.0.31 by ns3.uci.cu (envelope-from <emedinam@...>,
uid 501) with qmail-scanner-2.01st
(avp: 5.0.2.0. spamassassin: 3.0.6. perlscan: 2.01st.
Clear:RC:1(10.0.0.31):.
Processed in 0.628069 secs); 27 May 2008 07:09:11 -0000
Received: from unknown (HELO ucixw2.uci.cu) (10.0.0.31)
by 0 with SMTP; 27 May 2008 07:09:10 -0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C8BFC8.8FAEB7CF"
Subject:
Date: Tue, 27 May 2008 03:10:43 -0400
Message-ID: <1A668661A3AAA343B3C49E2F266DDAE073A9B3@...>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Index: Aci/yMcYX2mY4TxhRXyh7FqfEbhcYA==
From: "Evelio Maikel Medina Manrique" <emedinam@...>
To: <graffito-dev-subscribe@...>
X-Virus-Checked: Checked by ClamAV on apache.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8BFC8.8FAEB7CF
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

------_=_NextPart_001_01C8BFC8.8FAEB7CF
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>

</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><o:p> </o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C8BFC8.8FAEB7CF--

Graffito presentation at Fast Feather Track ApacheCon US 2007

2007-09-21T12:22:34Z

Call for Presenters for Fast Feather Track at ApacheCon US 2007

Deadline: 27 September 2007 (!)

You may already know the new "Fast Feather Track" which was held
for the first time at ApacheCon Europe 2007. Fast Feather track
presentations are 10-15 minute presentations about a specific
project or topic. The focus is on Apache Incubator and Apache Labs
projects, and projects that recently graduated from incubation
(see also Bill Rowe's recent email to general@incubator).

For the upcoming ApacheCon in Atlanta we are planning to give the
Fast Feather Track a bit more structure, and to include the
schedule with the selected presentations in the printed conference
program and Web site.

We would very much like to have a presentation about Graffito
at the Fast Feather Track, and would like to invite someone from
the team to submit a presentation proposal!

Please note, that we CANNOT cover the registration fee, travel
or other expenses for speakers of the Fast Feather Track (if you
are not a committer yet you will get a registration discount), so
this is mainly an opportunity for people already planning to
attend ApacheCon US 2007. However, as a speaker you will be
listed on the Web site and in the printed conference program.

If you would like to propose a presentation for the Fast
Feather Track, please send a separate email to the address

fastfeather-2007-us@...

and include the following information:

- Presentation title
- Short abstract
- Short biography
- Did you already register for the conference? (yes/no)

Deadline: 27 September 2007
Notification of acceptance: 2 October 2007

Presentations for the Fast Feather Track are accepted on a
first-come, first-served basis.

We look forward to your submission ...
--
Lars Eilebrecht
lars@...
ApacheCon US 2007 Planning Team

Re: [RESULT] [VOTE] Retire the Graffito project

2007-07-13T05:04:36Z

Hi,

On 6/15/07, Jukka Zitting <jukka.zitting@...> wrote:
> This vote is now closed and the consensus is to retire the project. I
> will ask the Incubator PMC to formally retire Graffito.

The Incubator PMC has ratified the decision, and I will now start
closing things down as described in
http://wiki.apache.org/incubator/RetiringPodlings.

Thanks all for participating!

BR,

Jukka Zitting

Re: [RESULT] [VOTE] Retire the Graffito project

2007-06-17T08:37:44Z

> Thanks for the reminder! Your original vote doesn't seem to have made
> it to the mailing list,
Sorry, my bad. I missed the retirement vote and mixed it up with
the move vote. To make it clear:

[X] +1, retire the Graffito project

Jukka Zitting wrote:

> Hi,
>
> On 6/15/07, Sandro Böhme <sandro.boehme@...> wrote:
>
>> I also voted with +1.
>
>
> Thanks for the reminder! Your original vote doesn't seem to have made
> it to the mailing list, see
> http://mail-archives.apache.org/mod_mbox/incubator-graffito-dev/200706.mbox/browser.
>
>
> With your vote the tally is:
>
> +1 Christophe Lombart *
> +1 Jukka Zitting *
> +1 Oliver Kiessler *
> +1 Carsten Ziegeler
> +0 David Sean Taylor *
> +1 Sandro Böhme *
>
> BR,
>
> Jukka Zitting

--
https://www.xing.com/profile/Sandro_Boehme
http://www.linkedin.com/in/sandroboehme
http://www.wingsuit.de

Re: [RESULT] [VOTE] Retire the Graffito project

2007-06-15T21:19:57Z

Hi,

On 6/15/07, Sandro Böhme <sandro.boehme@...> wrote:
> I also voted with +1.

Thanks for the reminder! Your original vote doesn't seem to have made
it to the mailing list, see
http://mail-archives.apache.org/mod_mbox/incubator-graffito-dev/200706.mbox/browser.

With your vote the tally is:

+1 Christophe Lombart *
+1 Jukka Zitting *
+1 Oliver Kiessler *
+1 Carsten Ziegeler
+0 David Sean Taylor *
+1 Sandro Böhme *

BR,

Jukka Zitting

Re: [RESULT] [VOTE] Retire the Graffito project

2007-06-15T11:00:12Z

Hi Jukka,

I also voted with +1.

Bye,

Sandro

Jukka Zitting schrieb:

> Hi,
>
> On 6/1/07, Jukka Zitting <jukka.zitting@...> wrote:
>> So, please vote on retiring the Graffito project. The result of this
>> vote, if positive, will be used as a recommendation to the Incubator
>> PMC to formally retire Graffito.
>
> The following votes were cast (* indicates a member of the Graffito
> PPMC) in the past two weeks:
>
> +1 Christophe Lombart *
> +1 Jukka Zitting *
> +1 Oliver Kiessler *
> +1 Carsten Ziegeler
> +0 David Sean Taylor *
>
> This vote is now closed and the consensus is to retire the project. I
> will ask the Incubator PMC to formally retire Graffito.
>
> BR,
>
> Jukka Zitting
>

[RESULT] [VOTE] Retire the Graffito project

2007-06-15T10:15:26Z

Hi,

On 6/1/07, Jukka Zitting <jukka.zitting@...> wrote:
> So, please vote on retiring the Graffito project. The result of this
> vote, if positive, will be used as a recommendation to the Incubator
> PMC to formally retire Graffito.

The following votes were cast (* indicates a member of the Graffito
PPMC) in the past two weeks:

+1 Christophe Lombart *
+1 Jukka Zitting *
+1 Oliver Kiessler *
+1 Carsten Ziegeler
+0 David Sean Taylor *

This vote is now closed and the consensus is to retire the project. I
will ask the Incubator PMC to formally retire Graffito.

BR,

Jukka Zitting

Re: Can jcr mapping be specified through bean fields without set/get methods ?

2007-06-04T16:09:28Z

Sorry I didn't see your post on the jackrabbit mailing list.
This feature is not yet supported. You are welcome to create a new JIRA
issue (from Jackrabbit).

br,
Christophe

On 6/4/07, rajab57 <rajalakshmi@...> wrote:

>
>
> Hi,
>
> I would like to do jcr mapping for a java class through the fields. I have
> some scenarios where
> I would like to expose only the getter and not allow it to be modified.
> Also
> these objects are in states where they cannot be directly used with set
> and
> get from outside. In these situations, i woulld like to write java Beans
> without the getter/setter pair.
>
> When I do such a mapping I get an error message that the setter method is
> not there.
>
> I looked at the graffito-jcr-mapping.dtd to see if there were any flags
> that
> can handle the case without set/get. But I could not find any.
>
> Is there a way to specifiy java class without setter/getter for jcr
> Mapping
> ?
>
> Thanks for the help in advance,
> Raji
>
>
> I have already posted this question in jackrabbit forum. Sorry for posting
> this here again. I was not sure if anybody is checking graffito related
> questions there.
>
> --
> View this message in context:
> http://www.nabble.com/Can-jcr-mapping-be-specified-through-bean-fields-without-set-get-methods---tf3867935.html#a10958356
> Sent from the Graffito - Dev mailing list archive at Nabble.com.
>
>

Can jcr mapping be specified through bean fields without set/get methods ?

2007-06-04T15:02:07Z

Hi,

I would like to do jcr mapping for a java class through the fields. I have
some scenarios where
I would like to expose only the getter and not allow it to be modified. Also
these objects are in states where they cannot be directly used with set and
get from outside. In these situations, i woulld like to write java Beans
without the getter/setter pair.

When I do such a mapping I get an error message that the setter method is
not there.

I looked at the graffito-jcr-mapping.dtd to see if there were any flags that
can handle the case without set/get. But I could not find any.

Is there a way to specifiy java class without setter/getter for jcr Mapping
?

Thanks for the help in advance,
Raji

I have already posted this question in jackrabbit forum. Sorry for posting this here again. I was not sure if anybody is checking graffito related questions there.

Re: [VOTE] Retire the Graffito project

2007-06-04T12:25:19Z

On Jun 1, 2007, at 5:16 AM, Carsten Ziegeler wrote:

> [X] +1, retire the Graffito project
>
>

+0

Re: [VOTE] Retire the Graffito project

2007-06-01T06:16:35Z

[X] +1, retire the Graffito project

Carsten

Re: [VOTE] Retire the Graffito project

2007-06-01T05:08:15Z

> So, please vote on retiring the Graffito project. The result of this
> vote, if positive, will be used as a recommendation to the Incubator
> PMC to formally retire Graffito.
>

[x] +1, retire the Graffito project
[ ] -1, do not retire the Graffito project

regards, oliver

Re: [VOTE] Retire the Graffito project

2007-06-01T02:33:03Z

Hi,

On 6/1/07, Jukka Zitting <jukka.zitting@...> wrote:
> So, please vote on retiring the Graffito project.

[x] +1, retire the Graffito project
[ ] -1, do not retire the Graffito project

It's unfortunate to see the project becoming dormant, but I guess
retiring it is the best option for now. There are a number of good
ideas in the codebase that I hope will live on in Jackrabbit, Portals,
and other interested projects.

BR,

Jukka Zitting

Re: [VOTE] Retire the Graffito project

2007-06-01T02:28:13Z

+1

On 6/1/07, Jukka Zitting <jukka.zitting@...> wrote:

>
> Hi,
>
> As discussed before, now that the JCR mapping component has been moved
> to the Jackrabbit project I propose to retire the Graffito project
> from the Apache Incubator. The Graffito codebase would be moved to
> dormant state from where it can still be resurrected if renewed
> interest appears.
>
> So, please vote on retiring the Graffito project. The result of this
> vote, if positive, will be used as a recommendation to the Incubator
> PMC to formally retire Graffito.
>
> [ ] +1, retire the Graffito project
> [ ] -1, do not retire the Graffito project
>
> BR,
>
> Jukka Zitting
>

[VOTE] Retire the Graffito project

2007-06-01T02:26:26Z

Hi,

As discussed before, now that the JCR mapping component has been moved
to the Jackrabbit project I propose to retire the Graffito project
from the Apache Incubator. The Graffito codebase would be moved to
dormant state from where it can still be resurrected if renewed
interest appears.

So, please vote on retiring the Graffito project. The result of this
vote, if positive, will be used as a recommendation to the Incubator
PMC to formally retire Graffito.

[ ] +1, retire the Graffito project
[ ] -1, do not retire the Graffito project

BR,

Jukka Zitting

Re: How do I specify the graffito jcr mapping for classes that extend ArrayList

2007-06-01T01:50:17Z

If you have time, I will add add a new unit test with an ArrayList (hope for
this wk).

br,
Christophe

On 5/31/07, rajab57 <rajalakshmi@...> wrote:

>
>
> Hi,
>
> Thanks for the reply.
>
> I will refer to the jackrabbit project in future. I did not realize that
> the
> process has happened.
> I looked at the example for HashMap. And I have implemented the case of
> ArrayList, Set etc.
> In this scenario this ElementsList extends ArrayList. And I was not sure
> how
> I can specify that mapping.
>
> Thanks again,
> Raji
>
>
> Christophe Lombart wrote:
> >
> > The jcr mapping tools has been moved into the Jackrabbit project (
> > http://jackrabbit.apache.org). I advise you to use the Jackrabbit
> mailing
> > list.
> >
> > FYI, ArrayList are supportedd by default.
> >
> > If you want to support your own collection/map class :
> > 1/ your collection/map class have to implement the ManagableCollection
> > interface.
> > 2/ You have to specify the collection class name in the mapping file.
> >
> > We have a unit test with an specific HashMap. That's exactly the same
> for
> > collection like ArrayList, ...
> > * See the class HashMapElement which implement the interface
> > ManageableCollection
> > * See the unit test HashMapTest.
> > * Check in the mapping file "jcrmapping.xml" the mapping descriptor for
> > the
> > class o.a.j.ocm.testmodel.hashmap.Main which contains a descriptor based
> > on
> > the HashMapElement class.
> >
> > HTH
> > Christophe
> >
> >
> > On 5/31/07, rajab57 <rajalakshmi@...> wrote:
> >>
> >>
> >>
> >> Example
> >>
> >> import java.util.ArrayList;
> >> import java.util.ListIterator;
> >>
> >> public class MainClass {
> >> private ElementsList elements;
> >>
> >> }
> >>
> >> public class ElementsList extends ArrayList<Elements> {
> >> private static final long serialVersionUID = 1L;
> >>
> >> }
> >>
> >>
> >> public class Element {
> >> private String name ;
> >> private String id ;
> >>
> >> }
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/How-do-I-specify-the-graffito-jcr-mapping-for-classes-that-extend-ArrayList-tf3848661.html#a10901203
> >> Sent from the Graffito - Dev mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/How-do-I-specify-the-graffito-jcr-mapping-for-classes-that-extend-ArrayList-tf3848661.html#a10901887
> Sent from the Graffito - Dev mailing list archive at Nabble.com.
>
>

Re: How do I specify the graffito jcr mapping for classes that extend ArrayList

2007-05-31T14:58:01Z

Hi,

Thanks for the reply.

I will refer to the jackrabbit project in future. I did not realize that the process has happened.
I looked at the example for HashMap. And I have implemented the case of ArrayList, Set etc.
In this scenario this ElementsList extends ArrayList. And I was not sure how I can specify that mapping.

Thanks again,
Raji

Christophe Lombart wrote:

The jcr mapping tools has been moved into the Jackrabbit project (
http://jackrabbit.apache.org). I advise you to use the Jackrabbit mailing
list.

FYI, ArrayList are supportedd by default.

If you want to support your own collection/map class :
1/ your collection/map class have to implement the ManagableCollection
interface.
2/ You have to specify the collection class name in the mapping file.

We have a unit test with an specific HashMap. That's exactly the same for
collection like ArrayList, ...
* See the class HashMapElement which implement the interface
ManageableCollection
* See the unit test HashMapTest.
* Check in the mapping file "jcrmapping.xml" the mapping descriptor for the
class o.a.j.ocm.testmodel.hashmap.Main which contains a descriptor based on
the HashMapElement class.

HTH
Christophe

On 5/31/07, rajab57 <rajalakshmi@gmail.com> wrote:
>
>
>
> Example
>
> import java.util.ArrayList;
> import java.util.ListIterator;
>
> public class MainClass {
> private ElementsList elements;
>
> }
>
> public class ElementsList extends ArrayList<Elements> {
> private static final long serialVersionUID = 1L;
>
> }
>
>
> public class Element {
> private String name ;
> private String id ;
>
> }
>
>
>
>
> --
> View this message in context:
> http://www.nabble.com/How-do-I-specify-the-graffito-jcr-mapping-for-classes-that-extend-ArrayList-tf3848661.html#a10901203
> Sent from the Graffito - Dev mailing list archive at Nabble.com.
>
>

Re: How do I specify the graffito jcr mapping for classes that extend ArrayList

2007-05-31T14:37:11Z

The jcr mapping tools has been moved into the Jackrabbit project (
http://jackrabbit.apache.org). I advise you to use the Jackrabbit mailing
list.

FYI, ArrayList are supportedd by default.

If you want to support your own collection/map class :
1/ your collection/map class have to implement the ManagableCollection
interface.
2/ You have to specify the collection class name in the mapping file.

We have a unit test with an specific HashMap. That's exactly the same for
collection like ArrayList, ...
* See the class HashMapElement which implement the interface
ManageableCollection
* See the unit test HashMapTest.
* Check in the mapping file "jcrmapping.xml" the mapping descriptor for the
class o.a.j.ocm.testmodel.hashmap.Main which contains a descriptor based on
the HashMapElement class.

HTH
Christophe

On 5/31/07, rajab57 <rajalakshmi@...> wrote:

>
>
>
> Example
>
> import java.util.ArrayList;
> import java.util.ListIterator;
>
> public class MainClass {
> private ElementsList elements;
>
> }
>
> public class ElementsList extends ArrayList<Elements> {
> private static final long serialVersionUID = 1L;
>
> }
>
>
> public class Element {
> private String name ;
> private String id ;
>
> }
>
>
>
>
> --
> View this message in context:
> http://www.nabble.com/How-do-I-specify-the-graffito-jcr-mapping-for-classes-that-extend-ArrayList-tf3848661.html#a10901203
> Sent from the Graffito - Dev mailing list archive at Nabble.com.
>
>

How do I specify the graffito jcr mapping for classes that extend ArrayList

2007-05-31T14:14:16Z

Example

import java.util.ArrayList;
import java.util.ListIterator;

public class MainClass {
private ElementsList elements;

}

public class ElementsList extends ArrayList<Elements> {
private static final long serialVersionUID = 1L;

}

public class Element {
private String name ;
private String id ;

}

Re: [RESULT] [VOTE] Move JCR Mapping to Jackrabbit

2007-04-25T04:18:23Z

On 4/25/07, Jukka Zitting <jukka.zitting@...> wrote:
>
>
>
> Christophe is now a Jackrabbit committer, so he should have write
> access also the new location in subversion. Christophe, can you do a
> test commit to check that everything works fine?
>

I'm on customer site but I will try this evening.

Thanks
Christophe

Re: [RESULT] [VOTE] Move JCR Mapping to Jackrabbit

2007-04-25T04:14:38Z

Hi,

On 4/25/07, Alexandru Popescu ☀ <the.mindstorm.mailinglist@...> wrote:
> I know I haven't committed anything in Graffitto for the last months,
> but this was mainly because I was not agreeing with its direction at
> the time, and I was clearly saying that I am still interested in only
> OCM. Having in mind the InfoQ is probably the biggest application
> using OCM I would definitely like to preserve my commit role on the
> OCM project.

I believe the Jackrabbit PMC would be happy to have you on board. For
now we looked at the recent commit activity when selecting who should
be invited as a committer along with the codebase, but anyone who
shows renewed activity will probably receive committer status very
quickly based on earlier contributions.

BR,

Jukka Zitting

Re: [RESULT] [VOTE] Move JCR Mapping to Jackrabbit

2007-04-25T04:06:00Z

On 4/25/07, Jukka Zitting <jukka.zitting@...> wrote:

> Hi,
>
> On 4/23/07, Christophe Lombart <christophe.lombart@...> wrote:
> > tha's ok now. We can move the code.
>
> OK, thanks. I've now moved the codebase to:
>
> http://svn.apache.org/repos/asf/jackrabbit/trunk/contrib/jackrabbit-jcr-mapping
>
> I just did a svn move from .../incubator/graffito/trunk/jcr, so the
> build scripts are a bit broken at the moment, but I'll look into that
> later today.
>
> I also moved all the open JCR Mapping issues into the Jackrabbit
> project in Jira. See the jcr-mapping component in the Jackrabbit
> project.
>
> Christophe is now a Jackrabbit committer, so he should have write
> access also the new location in subversion. Christophe, can you do a
> test commit to check that everything works fine?
>
> As for the future development of the JCR mapping component, I would
> like to welcome everyone who is interested to join the Jackrabbit
> development mailing list and to continue any related discussions
> there.
>

I know I haven't committed anything in Graffitto for the last months,
but this was mainly because I was not agreeing with its direction at
the time, and I was clearly saying that I am still interested in only
OCM. Having in mind the InfoQ is probably the biggest application
using OCM I would definitely like to preserve my commit role on the
OCM project.

bests,

./alex
--
.w( the_mindstorm )p.
_____________________________________
Alexandru Popescu, OSS Evangelist
TestNG/Groovy/AspectJ/WebWork/more...
Information Queue ~ www.InfoQ.com

> BR,
>
> Jukka Zitting
>

Re: [RESULT] [VOTE] Move JCR Mapping to Jackrabbit

2007-04-25T04:00:57Z

Hi,

On 4/23/07, Christophe Lombart <christophe.lombart@...> wrote:
> tha's ok now. We can move the code.

OK, thanks. I've now moved the codebase to:

http://svn.apache.org/repos/asf/jackrabbit/trunk/contrib/jackrabbit-jcr-mapping

I just did a svn move from .../incubator/graffito/trunk/jcr, so the
build scripts are a bit broken at the moment, but I'll look into that
later today.

I also moved all the open JCR Mapping issues into the Jackrabbit
project in Jira. See the jcr-mapping component in the Jackrabbit
project.

Christophe is now a Jackrabbit committer, so he should have write
access also the new location in subversion. Christophe, can you do a
test commit to check that everything works fine?

As for the future development of the JCR mapping component, I would
like to welcome everyone who is interested to join the Jackrabbit
development mailing list and to continue any related discussions
there.

BR,

Jukka Zitting

Re: [RESULT] [VOTE] Move JCR Mapping to Jackrabbit

2007-04-25T01:28:20Z

Hi,

On 4/25/07, ruchi goel <Ruchi.Goel@...> wrote:
> Did not get the "non-binding " part of the vote ??

Everyone is welcome to participate in the vote and normally all votes
are heard, but in tight cases only votes from the PMC members are
binding to the project.

For example if someone outside the Graffito PPMC had cast a
non-binding -1 vote I would certainly have considered tabling the
issue until more consensus is achieved, but a binding -1 vote from a
Graffito committer would have vetoed the motion regardless of my
opinion.

BR,

Jukka Zitting

Re: [RESULT] [VOTE] Move JCR Mapping to Jackrabbit

2007-04-25T01:13:13Z

Jukka Zitting wrote:

> Hi,
>
> On 4/17/07, Jukka Zitting <jukka.zitting@...> wrote:
>> As already discussed, I'd like to formally propose moving the JCR
>> Mapping codebase and related pieces of code
>> (http://svn.apache.org/repos/asf/incubator/graffito/trunk/jcr/) to the
>> Apache Jackrabbit project.
>>
>> Please vote on whether to move the codebase. The vote is open for the
>> next 72 hours, with binding votes from the Graffito PPMC.
>
> The vote passes with five binding +1 votes and three non-binding +1
> votes. As the parallel vote on the Jackrabbit mailing list also
> passed, I will now proceed to move the codebase.
>
> The binding votes were:
>
> +1 Sandro Böhme
> +1 Christophe Lombart
> +1 Oliver Kiessler
> +1 Alexandru Popescu
> +1 Jukka Zitting
>
> The non-binding votes were:
>
> +1 Ruchi Goel
> +1 Felix Meschberger
> +1 Carsten Ziegeler
>
> BR,
>
> Jukka Zitting

Did not get the "non-binding " part of the vote ??
-Ruchi

Re: [RESULT] [VOTE] Move JCR Mapping to Jackrabbit

2007-04-23T14:01:15Z

tha's ok now. We can move the code.

Thanks
Christophe

On 4/23/07, Christophe Lombart <christophe.lombart@...> wrote:

>
> Ok probably for tomorrow in the morning.
>
> Thanks,
> Christophe
>
>
> On 4/23/07, Jukka Zitting <jukka.zitting@... > wrote:
> >
> > Hi,
> >
> > On 4/23/07, Christophe Lombart < christophe.lombart@...> wrote:
> > > I have some stuff to commit (probably at the end of the day). Can we
> > wait
> > > until tomorrow ? If not, I will make changes in the new svn repo.
> >
> > No problem, there's no rush to get this done. Just ping me when you're
> > ready. Meanwhile I'll try to figure out if we can move the open JCR
> > Mapping issues over to the Jackrabbit project in Jira.
> >
> > BR,
> >
> > Jukka Zitting
> >
>
>

Re: [RESULT] [VOTE] Move JCR Mapping to Jackrabbit

2007-04-23T04:02:11Z

Ok probably for tomorrow in the morning.

Thanks,
Christophe

On 4/23/07, Jukka Zitting <jukka.zitting@...> wrote:

>
> Hi,
>
> On 4/23/07, Christophe Lombart <christophe.lombart@...> wrote:
> > I have some stuff to commit (probably at the end of the day). Can we
> wait
> > until tomorrow ? If not, I will make changes in the new svn repo.
>
> No problem, there's no rush to get this done. Just ping me when you're
> ready. Meanwhile I'll try to figure out if we can move the open JCR
> Mapping issues over to the Jackrabbit project in Jira.
>
> BR,
>
> Jukka Zitting
>

Re: [RESULT] [VOTE] Move JCR Mapping to Jackrabbit

2007-04-23T03:59:33Z

Hi,

On 4/23/07, Christophe Lombart <christophe.lombart@...> wrote:
> I have some stuff to commit (probably at the end of the day). Can we wait
> until tomorrow ? If not, I will make changes in the new svn repo.

No problem, there's no rush to get this done. Just ping me when you're
ready. Meanwhile I'll try to figure out if we can move the open JCR
Mapping issues over to the Jackrabbit project in Jira.

BR,

Jukka Zitting

Re: [RESULT] [VOTE] Move JCR Mapping to Jackrabbit

2007-04-23T03:56:15Z

I have some stuff to commit (probably at the end of the day). Can we wait
until tomorrow ? If not, I will make changes in the new svn repo.

Thanks,
Christophe

On 4/23/07, Jukka Zitting <jukka.zitting@...> wrote:

>
> Hi,
>
> On 4/17/07, Jukka Zitting <jukka.zitting@...> wrote:
> > As already discussed, I'd like to formally propose moving the JCR
> > Mapping codebase and related pieces of code
> > (http://svn.apache.org/repos/asf/incubator/graffito/trunk/jcr/) to the
> > Apache Jackrabbit project.
> >
> > Please vote on whether to move the codebase. The vote is open for the
> > next 72 hours, with binding votes from the Graffito PPMC.
>
> The vote passes with five binding +1 votes and three non-binding +1
> votes. As the parallel vote on the Jackrabbit mailing list also
> passed, I will now proceed to move the codebase.
>
> The binding votes were:
>
> +1 Sandro Böhme
> +1 Christophe Lombart
> +1 Oliver Kiessler
> +1 Alexandru Popescu
> +1 Jukka Zitting
>
> The non-binding votes were:
>
> +1 Ruchi Goel
> +1 Felix Meschberger
> +1 Carsten Ziegeler
>
> BR,
>
> Jukka Zitting
>

[RESULT] [VOTE] Move JCR Mapping to Jackrabbit

2007-04-23T03:43:58Z

Hi,

On 4/17/07, Jukka Zitting <jukka.zitting@...> wrote:
> As already discussed, I'd like to formally propose moving the JCR
> Mapping codebase and related pieces of code
> (http://svn.apache.org/repos/asf/incubator/graffito/trunk/jcr/) to the
> Apache Jackrabbit project.
>
> Please vote on whether to move the codebase. The vote is open for the
> next 72 hours, with binding votes from the Graffito PPMC.

The vote passes with five binding +1 votes and three non-binding +1
votes. As the parallel vote on the Jackrabbit mailing list also
passed, I will now proceed to move the codebase.

The binding votes were:

+1 Sandro Böhme
+1 Christophe Lombart
+1 Oliver Kiessler
+1 Alexandru Popescu
+1 Jukka Zitting

The non-binding votes were:

+1 Ruchi Goel
+1 Felix Meschberger
+1 Carsten Ziegeler

BR,

Jukka Zitting

[jira] Assigned: (GRFT-131) ResidualProperties Converter uses wrong AtomicType Converter on update

2007-04-21T03:14:15Z

[ https://issues.apache.org/jira/browse/GRFT-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christophe Lombart reassigned GRFT-131:
---------------------------------------

Assignee: Christophe Lombart

> ResidualProperties Converter uses wrong AtomicType Converter on update
> ----------------------------------------------------------------------
>
> Key: GRFT-131
> URL: https://issues.apache.org/jira/browse/GRFT-131
> Project: Graffito
> Issue Type: Bug
> Components: JCR-Mapping
> Affects Versions: 1.0-a1-dev
> Reporter: Felix Meschberger
> Assigned To: Christophe Lombart
> Fix For: 1.0-a1-dev
>
> Attachments: GRFT-131.diff
>
>
> When writing back data, the ResidualPropertiesCollectionConverterImpl.internalSetProperties method looks at the type of the Java object
> to find the atomic type converter instead of getting the converter according to the collection descriptor.
> This may lead to NullPointerExceptions in case the concrete type is an extension (or implementation) of the declared type.
> I am currently working on a patch to attache to this bug.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GRFT-131) ResidualProperties Converter uses wrong AtomicType Converter on update

2007-04-20T08:23:15Z

[ https://issues.apache.org/jira/browse/GRFT-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger updated GRFT-131:
-----------------------------------

Attachment: GRFT-131.diff

And here is the patch.

Note that the ResidualProperties converter will now throw a PersistenceException on read or write if no atomic type converter can be found for the element class name.

> ResidualProperties Converter uses wrong AtomicType Converter on update
> ----------------------------------------------------------------------
>
> Key: GRFT-131
> URL: https://issues.apache.org/jira/browse/GRFT-131
> Project: Graffito
> Issue Type: Bug
> Components: JCR-Mapping
> Affects Versions: 1.0-a1-dev
> Reporter: Felix Meschberger
> Fix For: 1.0-a1-dev
>
> Attachments: GRFT-131.diff
>
>
> When writing back data, the ResidualPropertiesCollectionConverterImpl.internalSetProperties method looks at the type of the Java object
> to find the atomic type converter instead of getting the converter according to the collection descriptor.
> This may lead to NullPointerExceptions in case the concrete type is an extension (or implementation) of the declared type.
> I am currently working on a patch to attache to this bug.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GRFT-131) ResidualProperties Converter uses wrong AtomicType Converter on update

2007-04-20T08:12:15Z

ResidualProperties Converter uses wrong AtomicType Converter on update
----------------------------------------------------------------------

Key: GRFT-131
URL: https://issues.apache.org/jira/browse/GRFT-131
Project: Graffito
Issue Type: Bug
Components: JCR-Mapping
Affects Versions: 1.0-a1-dev
Reporter: Felix Meschberger
Fix For: 1.0-a1-dev

When writing back data, the ResidualPropertiesCollectionConverterImpl.internalSetProperties method looks at the type of the Java object
to find the atomic type converter instead of getting the converter according to the collection descriptor.

This may lead to NullPointerExceptions in case the concrete type is an extension (or implementation) of the declared type.

I am currently working on a patch to attache to this bug.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (GRFT-106) Avoid INFINITE RECURSION when Object Model has cycles.

2007-04-18T13:35:15Z

[ https://issues.apache.org/jira/browse/GRFT-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christophe Lombart resolved GRFT-106.
-------------------------------------

Resolution: Fixed
Fix Version/s: ocm-1.0

Solve by using an object cache. This is not yet a complete cache system but this small cache is used per persistenceManager and only for retrieve requests. It allows to perform circular lookups (as by crossreferenced objects) that would result in non-terminating loops without such a cache.

Later I would like to implement a complete object cache support. Something like in Hibernate or OJB. There is a good description here : http://db.apache.org/ojb/docu/guides/objectcache.html. I think we have similar needs but we have to define a proposal for this kind of feature with the most useful use cases.

> Avoid INFINITE RECURSION when Object Model has cycles.
> ------------------------------------------------------
>
> Key: GRFT-106
> URL: https://issues.apache.org/jira/browse/GRFT-106
> Project: Graffito
> Issue Type: Improvement
> Components: JCR-Mapping
> Reporter: Dan Connelly
> Assigned To: Christophe Lombart
> Priority: Critical
> Fix For: ocm-1.0
>
>
> The default ObjectConverterImpl is restricted to acyclic graphs in the object model.
> Many Java object models are NOT acyclic. For instance, I am on your Friends list. Yoar are on my Friends list. Java encourages such structures. Almost any large object model in Java will have hidden cycles.
> Saving an Object Model that contains cycles using Graffito causes an infinite recursion.
> Clearly, it is important to maintain a 1-to-1 correspondence between Nodes and Objects to prevent this. In the absence of Multiple Parent Nodes, it will be necessary to use REFERENCE or UNDEFINED Items in place of the 2nd (or greater) Node representing a given Object. My preference si that the default ObjectConverterImpl should support REFERENCE., Failing this, use of UNDEFINED also solves this problem and would acceptable (as default). Whether or not REFERENCE is used, both insertion and retrieval must provide a reasonable result. A custom ojbect converter should be available to switch UNDEFINED to REFERENCE, or vice versa.
> Also, it is probably best to keep the targeted, well-defined Nodes close to the Root Node. This implies that the default ObjectConverterImpl should implement a Breadth-First, rather than a Depth-First, traversal of the Object Model on both insertion and retrieval. Again, if the default is Depth-First, a custom object converter should be available that implements Breadth-First.
> Admittedly, support for (2 representations) X (2 traversals) implies a drastic refactoring and/or rewriting of the ObjectConverterImpl class.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Move JCR Mapping to Jackrabbit

2007-04-18T06:00:10Z

Jukka Zitting wrote:

> Hi,
>
> As already discussed, I'd like to formally propose moving the JCR
> Mapping codebase and related pieces of code
> (http://svn.apache.org/repos/asf/incubator/graffito/trunk/jcr/) to the
> Apache Jackrabbit project.
>
> Please vote on whether to move the codebase. The vote is open for the
> next 72 hours, with binding votes from the Graffito PPMC. I will call
> a parallel vote on the Jackrabbit PMC to accept the codebase. The move
> will happen only if both votes pass.
>
> [ ] +1 Move JCR Mapping to Jackrabbit
> [ ] -1 Do not move the component because ...
>
> Here's my +1
>
> BR,
>
> Jukka Zitting

+1 Move JCR Mapping to Jackrabbit .
-Ruchi