Hy I need to know how to uses graffito framework to development
application .
-----Original Message-----
From: graffito-dev-help@incubator.apache.org
[mailto:graffito-dev-help@incubator.apache.org]
Sent: Martes, 27 de Mayo de 2008 03:10 a.m.
To: Evelio Maikel Medina Manrique
Subject: confirm subscribe to graffito-dev@incubator.apache.org
Hi! This is the ezmlm program. I'm managing the
graffito-dev@incubator.apache.org mailing list.
I'm working for my owner, who can be reached
at graffito-dev-owner@incubator.apache.org.
To confirm that you would like
emedinam@uci.cu
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@incubator.apache.org> 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@incubator.apache.org>
To remove your address from the list, send a message to:
<graffito-dev-unsubscribe@incubator.apache.org>
Send mail to the following for info and FAQ for this list:
<graffito-dev-info@incubator.apache.org>
<graffito-dev-faq@incubator.apache.org>
Similar addresses exist for the digest list:
<graffito-dev-digest-subscribe@incubator.apache.org>
<graffito-dev-digest-unsubscribe@incubator.apache.org>
To get messages 123 through 145 (a maximum of 100 per request), mail:
<graffito-dev-get.123_145@incubator.apache.org>
To get an index with subject and author for messages 123-456 , mail:
<graffito-dev-index.123_456@incubator.apache.org>
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@incubator.apache.org>
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@host.domain", just add a hyphen and your
address (with '=' instead of '@') after the command word:
<graffito-dev-subscribe-john=host.domain@incubator.apache.org>
To stop subscription for this address, mail:
<graffito-dev-unsubscribe-john=host.domain@incubator.apache.org>
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@incubator.apache.org. Please be patient, my owner is
a
lot slower than I am ;-)
--- Enclosed is a copy of the request I received.
Return-Path: <emedinam@uci.cu>
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@uci.cu
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@uci.cu>,
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@ucixw2.uci.cu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Index: Aci/yMcYX2mY4TxhRXyh7FqfEbhcYA==
From: "Evelio Maikel Medina Manrique" <emedinam@uci.cu>
To: <graffito-dev-subscribe@incubator.apache.org>
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>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</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--
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@apachecon.com
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@apache.org
ApacheCon US 2007 Planning Team
Hi, On 6/15/07, Jukka Zitting <jukka.zitting@gmail.com> 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
> 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@gmx.de> 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
Hi,
On 6/15/07, Sandro Böhme <sandro.boehme@gmx.de> 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
Hi Jukka, I also voted with +1. Bye, Sandro Jukka Zitting schrieb: > Hi, > > On 6/1/07, Jukka Zitting <jukka.zitting@gmail.com> 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 >
Hi,
On 6/1/07, Jukka Zitting <jukka.zitting@gmail.com> 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
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@gmail.com> 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. > >
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.
On Jun 1, 2007, at 5:16 AM, Carsten Ziegeler wrote: > [X] +1, retire the Graffito project > > +0
[X] +1, retire the Graffito project Carsten
> 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
Hi, On 6/1/07, Jukka Zitting <jukka.zitting@gmail.com> 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
+1 On 6/1/07, Jukka Zitting <jukka.zitting@gmail.com> 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 >
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
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@gmail.com> 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@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.
> >>
> >>
> >
> >
>
> --
> 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.
>
>
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.
>>
>>
>
>
--
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.
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.
>
>
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.
On 4/25/07, Jukka Zitting <jukka.zitting@gmail.com> 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
Hi, On 4/25/07, Alexandru Popescu ☀ <the.mindstorm.mailinglist@gmail.com> 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
On 4/25/07, Jukka Zitting <jukka.zitting@gmail.com> wrote: > Hi, > > On 4/23/07, Christophe Lombart <christophe.lombart@gmail.com> 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 >
Hi,
On 4/23/07, Christophe Lombart <christophe.lombart@gmail.com> 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
Hi, On 4/25/07, ruchi goel <Ruchi.Goel@sun.com> 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
Jukka Zitting wrote: > Hi, > > On 4/17/07, Jukka Zitting <jukka.zitting@gmail.com> 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
tha's ok now. We can move the code. Thanks Christophe On 4/23/07, Christophe Lombart <christophe.lombart@gmail.com> wrote: > > Ok probably for tomorrow in the morning. > > Thanks, > Christophe > > > On 4/23/07, Jukka Zitting <jukka.zitting@gmail.com > wrote: > > > > Hi, > > > > On 4/23/07, Christophe Lombart < christophe.lombart@gmail.com> 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 > > > >
Ok probably for tomorrow in the morning. Thanks, Christophe On 4/23/07, Jukka Zitting <jukka.zitting@gmail.com> wrote: > > Hi, > > On 4/23/07, Christophe Lombart <christophe.lombart@gmail.com> 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 >
Hi, On 4/23/07, Christophe Lombart <christophe.lombart@gmail.com> 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
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@gmail.com> wrote: > > Hi, > > On 4/17/07, Jukka Zitting <jukka.zitting@gmail.com> 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 >
Hi,
On 4/17/07, Jukka Zitting <jukka.zitting@gmail.com> 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
[ 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.
[ 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.
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.
[ 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.
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
[ https://issues.apache.org/jira/browse/GRFT-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger closed GRFT-130.
----------------------------------
Looks good. Thanks for applying.
> Some classes use JDK 5 autoboxing
> ---------------------------------
>
> Key: GRFT-130
> URL: https://issues.apache.org/jira/browse/GRFT-130
> Project: Graffito
> Issue Type: Bug
> Reporter: Felix Meschberger
> Fix For: ocm-1.0
>
> Attachments: GRFT-130.diff
>
>
> The AtomicTest and UndefinedTypeConverterImpl classes employ Java 5 autoboxing functionality
which is not available on Java 1.4 platform also supported by Jackrabbit and JCR.
> Additionally, the UndefinedTypeConverterImpl class contains a potential class ClassCasst
issue in inthat an Integer object is cast to Long.
> Attaching a patch, which uses explicit boxing/unboxing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/GRFT-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger closed GRFT-129.
----------------------------------
Looks good. Thanks for applying.
> ResidualProperties Converter may fail
> -------------------------------------
>
> Key: GRFT-129
> URL: https://issues.apache.org/jira/browse/GRFT-129
> Project: Graffito
> Issue Type: Bug
> Components: JCR-Mapping
> Reporter: Felix Meschberger
> Assigned To: Christophe Lombart
> Attachments: GRFT-129.diff
>
>
> When storing data, the ResidualPropertiesCollectionConverterImpl class first removes
all properties matching the name pattern and then sets these properties. In the case of protected
properties like jcr:primaryType this mechanism fails and prevents the properties from being
saved.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
+1 (Unbinding) Regards Felix On 4/17/07, Jukka Zitting <jukka.zitting@gmail.com> 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 >
On 4/17/07, Sandro Böhme <sandro.boehme@gmx.de> wrote: > Jukka Zitting schrieb: > > 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. > > [X] +1 Move JCR Mapping to Jackrabbit [ ] -1 Do not move the component because ... ./alex -- .w( the_mindstorm )p. _____________________________________ Alexandru Popescu, OSS Evangelist TestNG/Groovy/AspectJ/WebWork/more... Information Queue ~ www.InfoQ.com
Jukka Zitting schrieb: > 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 > [X] +1 Move JCR Mapping to Jackrabbit