Return-Path: 
 <users-return-4419-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org>
Delivered-To: apmail-jackrabbit-users-archive@locus.apache.org
Received: (qmail 32594 invoked from network); 7 Aug 2007 09:14:10 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 7 Aug 2007 09:14:10 -0000
Received: (qmail 91078 invoked by uid 500); 7 Aug 2007 09:14:08 -0000
Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org
Received: (qmail 91060 invoked by uid 500); 7 Aug 2007 09:14:07 -0000
Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@jackrabbit.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@jackrabbit.apache.org>
List-Post: <mailto:users@jackrabbit.apache.org>
List-Id: <users.jackrabbit.apache.org>
Reply-To: users@jackrabbit.apache.org
Delivered-To: mailing list users@jackrabbit.apache.org
Received: (qmail 91051 invoked by uid 99); 7 Aug 2007 09:14:07 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Aug 2007 02:14:07 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [62.192.10.254] (HELO goobak01.day.com) (62.192.10.254)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Aug 2007 09:14:02 +0000
Received: by goobak01.day.com (Postfix, from userid 1212)
	id AE3F950862; Tue,  7 Aug 2007 11:08:17 +0200 (CEST)
Received: from wa-out-1112.google.com (wa-out-1112.google.com
 [209.85.146.178])
	by goobak01.day.com (Postfix) with ESMTP id 9652D5086E
	for <users@jackrabbit.apache.org>; Tue,  7 Aug 2007 11:08:15 +0200 (CEST)
Received: by wa-out-1112.google.com with SMTP id k40so2529764wah
        for <users@jackrabbit.apache.org>;
 Tue, 07 Aug 2007 02:13:38 -0700 (PDT)
Received: by 10.115.106.7 with SMTP id i7mr6560275wam.1186478017783;
        Tue, 07 Aug 2007 02:13:37 -0700 (PDT)
Received: by 10.114.190.8 with HTTP; Tue, 7 Aug 2007 02:13:37 -0700 (PDT)
Message-ID: <e176788c0708070213y5e3dfd13ta63c759d431476cc@mail.gmail.com>
Date: Tue, 7 Aug 2007 11:13:37 +0200
From: "Dominique Pfister" <dominique.pfister@day.com>
Sender: dpfister@day.com
To: users@jackrabbit.apache.org
Subject: Re: [Re: Re: JBoss and Jackrabbit JCA]
In-Reply-To: <46B738BB.30507@researchstudio.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <46B738BB.30507@researchstudio.at>
X-Google-Sender-Auth: 01bb87a36e1b3139
X-Virus-Checked: Checked by ClamAV on apache.org

Hi Markus,

I don't know whether your client code resides in a servlet or EJB, but
this is what I did to access the repository from a sample JSP page
containing the following code snippet:

    InitialContext ctx =3D new InitialContext();
    Repository repository =3D (Repository)
ctx.lookup("java:comp/env/jcr/repository");

(1) inside the web application's web.xml file I declared the reference:

    <resource-ref>
        <description>Jackrabbit</description>
        <res-ref-name>jcr/repository</res-ref-name>
        <res-type>javax.jcr.Repository</res-type>
        <res-auth>Container</res-auth>
    </resource-ref>

(2) inside the web application's jboss-web.xml file I linked the reference =
to
     the actual datasource:

    <resource-ref>
        <res-ref-name>jcr/repository</res-ref-name>
        <res-type>javax.jcr.Repository</res-type>
        <jndi-name>java:jcr/local</jndi-name>
    </resource-ref>

As far as I can tell - I'm not a JBoss expert - the exception in that
other post is caused by accessing the global data source directly
instead of declaring a reference to it in the web application
descriptor.

Dominique

On 8/6/07, Markus Reis <markus.reis@researchstudio.at> wrote:
> Hi Dominique,
>
>
> that's exactly what I expected as well - however if I execute the code
> as is (i.e. without the surrounding XA stuff), I get an exception that
> tells me that no transaction has been started (STATUS_NO_TRANSACTION) -
> my exception is very similar to what has been reported at
> http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200702.mbox/%3C90=
64463.post@talk.nabble.com%3E.
>
> Therefore I tried to start the transaction myself ...
>
> ... any further help/guidance/hints is/are highly appreciated ...
>
>
> kind regards,
> Markus
>
> -------- Original-Nachricht --------
> Betreff:        Re: JBoss and Jackrabbit JCA
> Datum:  Mon, 6 Aug 2007 16:25:01 +0200
> Von:    Dominique Pfister <dominique.pfister@day.com>
> Antwort an:     users@jackrabbit.apache.org
> An:     users@jackrabbit.apache.org
> Referenzen:     <46B6FC00.1060004@researchstudio.at>
>
>
>
> Hi Markus,
>
> Apparently, your session is already associated with a transaction. I
> don't unterstand why you'd want to access the XAResource directly in
> your client code. I'd expect that if you left only your core code
> (starting with the comment "// .... add new nodes & properties and
> save them") JBoss would automatically execute the surrounding code you
> inserted manually.
>
> Kind regards
> Dominique
>
>
> On 8/6/07, Markus Reis <markus.reis@researchstudio.at> wrote:
> > Dear All,
> >
> >
> > I'm currently playing around with Jackrabbit's jca package and end up i=
n
> > some strange errors (which will mainly be due to wrong use from my code
> > :-)). Here's my environment:
> > JBoss 4.0.5.GA
> > Java 1.5_06
> > Jackrabbit 1.3.1 (checked out and build tagged version)
> > jcr-ds.xml (only modified homeDir property - I experimented with both
> > true and false for bindSessionToTransaction):
> >    <connection-factories>
> >     <tx-connection-factory>
> >         <jndi-name>jcr/local</jndi-name>
> >         <xa-transaction/>
> >         <rar-name>jackrabbit-jca-1.3.1.rar</rar-name>
> >         <connection-definition>javax.jcr.Repository</connection-definit=
ion>
> >         <config-property name=3D"homeDir"
> > type=3D"java.lang.String">${jboss.server.data.dir}${/}jackrabbit</confi=
g-property>
> >         <config-property name=3D"configFile"
> > type=3D"java.lang.String">classpath:repository.xml</config-property>
> >         <config-property name=3D"bindSessionToTransaction"
> > type=3D"java.lang.Boolean">false</config-property>
> >     </tx-connection-factory>
> >    </connection-factories>
> >
> > Here's my client code:
> >     XAResource xares =3D
> > ((JCASessionHandle)session).getManagedConnection().getXAResource();
> > //xares is either of type org.apache.jackrabbit.core.XASessionImpl (if
> > bindSessionToTransaction is set to false and
> > org.apache.jackrabbit.jca.TransactionBoundXAResource if set to true)
> >     // create dummy Xid
> >     Xid xid =3D new XidImpl(counter++); //XidImpl is simply copied from
> > org.apache.jackrabbit.core.UserTransactionImpl
> >     ((org.apache.jackrabbit.core.XASessionImpl)xares).associate(null);
> > //I think I shouldn't do that :-)
> >     xares.start(xid, XAResource.TMNOFLAGS);
> >
> >            // .... add new nodes & properties and save them
> >             Node root =3D session.getRootNode();
> >             Node child =3D root.hasNode(path.getRelativePath()) ?
> > root.getNode(path.getRelativePath()) : createFilePath(root,
> > path.getPathParts(), path.getObjectName());
> >             FileTypeResolver ftr =3D FileTypeResolver.instantiate();
> >             child.setProperty("jcr:mimeType", ftr.getMIMEType(obj));
> >             child.setProperty("jcr:data", new FileInputStream(obj));
> >             Calendar rightNow =3D Calendar.getInstance();
> >             child.setProperty("jcr:lastModified", rightNow);
> >             //child.setProperty("original-file-name", obj.getName());
> >             session.save();
> >
> >     xares.end(xid, XAResource.TMSUCCESS);
> >     xares.prepare(xid);
> >     xares.commit(xid, false);
> > If I set bindSessionToTransaction to false and disassociate the
> > XAResource from it's transaction (calling associate(null)), I can start
> > (and end and commit) the transaction successfully - I have however the
> > strong feeling that I shouldn't do that :-)
> > If I set bindSessionToTransaction to true (which would be the default)
> > or if I do not disassociate the XAResource from it's transaction then I
> > always get an exception thrown at XASessionImpl line 227 (remember that
> > I'm working on 1.3.1).
> >
> > I never found out why the XAResource was associated with a transaction
> > although bindSessionToTransaction was set to false.
> >
> > It would be great if someone could tell me what I'm doing wrong and/or
> > point me to sample code that should work in my environment and/or tell
> > me if she/he already did something similar successfully when deployed o=
n
> > JBoss.
> >
> >
> > many thanks,
> > Markus
> >
>
>
> --
> Mag. Markus Reis
>
> Austrian Research Centers GmbH - ARC
> Research Studios
> Studio Digital Memory Engineering
>
> Thurngasse 8/3/20, A-1090 Wien
> Mobile: +43 664 825 1106
> Tel.: +43-1-585 05 37 - 16
> Fax: +43-1-585 37 41
>
> <markus.reis@researchstudio.at>
> http://www.arcs.ac.at/
> http://www.researchstudio.at/
> http://dme.researchstudio.at/
>
> HG Wien =96 FN 115980i =96 ATU14703506
>
>