jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Reis <markus.r...@researchstudio.at>
Subject Re: [Re: Re: JBoss and Jackrabbit JCA]
Date Tue, 14 Aug 2007 08:45:11 GMT
Hi Dominique,


ejb-jar.xml and jboss.xml are deployment descriptors necessary for 
EJB2.x - I (would like to) use annotations and dependency injection (as 
proposed for EJB3.x) instead.

Nevertheless I tried to change my code according to your suggestions:

     //new field:
    @Resource(mappedName="java:jcr/local", 
type=javax.jcr.Repository.class, 
authenticationType=javax.annotation.Resource.AuthenticationType.CONTAINER) 
Repository repo;

    //changed method excerpt:
            Credentials cred = new SimpleCredentials(path.getUsername(), 
path.getPassword());
            session = repo.login(cred, null);
            Node root = session.getRootNode();
            Node child = root.hasNode(path.getRelativePath()) ? 
root.getNode(path.getRelativePath()) : createFilePath(root, 
path.getPathParts(), path.getObjectName());
            FileTypeResolver ftr = FileTypeResolver.instantiate();
            child.setProperty("jcr:mimeType", ftr.getMIMEType(obj));
            child.setProperty("jcr:data", new FileInputStream(obj));
            Calendar rightNow = Calendar.getInstance();
            child.setProperty("jcr:lastModified", rightNow);
            session.save();
I annotated the method with:
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
This should be the default setting, but who knows ...

I used the following datasource config:
    <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-definition>
            <config-property name="homeDir" 
type="java.lang.String">${jboss.server.data.dir}${/}jackrabbit</config-property>
            <config-property name="configFile" 
type="java.lang.String">classpath:repository.xml</config-property>
            <config-property name="bindSessionToTransaction" 
type="java.lang.Boolean">true</config-property>
        </tx-connection-factory>
    </connection-factories>

Debugging my code I found out that everything works fine until and after 
session.save() - When the method returns however it seems that a commit 
takes place (calling XASessionImpl.end()) and this commit is not 
successful due to a missing transaction:
143394 [http-0.0.0.0-8080-3] ERROR 
org.jboss.ws.core.jaxws.SOAPFaultHelperJAXWS  - SOAP request exception
java.lang.RuntimeException: org.jboss.tm.JBossRollbackException: Unable 
to commit, tx=TransactionImpl:XidImpl[FormatId=257,
 GlobalId=dme018/14, BranchQual=, localId=14] 
status=STATUS_NO_TRANSACTION; - nested throwable: 
(javax.transaction.xa.XAExc
eption)
        at 
org.jboss.aspects.tx.TxPolicy.handleEndTransactionException(TxPolicy.java:198)
        at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:180)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
        at 
org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
        at 
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
        at 
org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
        at 
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
        at 
org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
        at 
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
        at 
org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
        at 
org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:102)
        at 
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
        at 
org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
        at 
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
        at 
org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
        at 
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
        at 
org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:211)
        at 
org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:173)
        at 
org.jboss.ws.integration.jboss42.ServiceEndpointInvokerEJB3.invokeServiceEndpoint(ServiceEndpointInvokerEJB3.jav
a:114)
        at 
org.jboss.ws.core.server.AbstractServiceEndpointInvoker.invoke(AbstractServiceEndpointInvoker.java:173)
        at 
org.jboss.ws.core.server.ServiceEndpoint.handleRequest(ServiceEndpoint.java:204)
        at 
org.jboss.ws.core.server.ServiceEndpointManager.processSOAPRequest(ServiceEndpointManager.java:440)
        at 
org.jboss.ws.core.server.AbstractServiceEndpointServlet.doPost(AbstractServiceEndpointServlet.java:114)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at 
org.jboss.ws.core.server.AbstractServiceEndpointServlet.service(AbstractServiceEndpointServlet.java:75)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
        at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
        at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at 
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
        at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
        at 
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
        at 
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
        at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
        at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at 
org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
        at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
        at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
        at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
        at 
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:66
4)
        at 
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
        at 
org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
        at java.lang.Thread.run(Thread.java:595)
Caused by: org.jboss.tm.JBossRollbackException: Unable to commit, 
tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=dme018/
14, BranchQual=, localId=14] status=STATUS_NO_TRANSACTION; - nested 
throwable: (javax.transaction.xa.XAException)
        at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:372)
        at org.jboss.tm.TxManager.commit(TxManager.java:240)
        at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:175)
        ... 43 more
Caused by: javax.transaction.xa.XAException
        at 
org.apache.jackrabbit.core.XASessionImpl.end(XASessionImpl.java:279)
        at 
org.apache.jackrabbit.jca.TransactionBoundXAResource.end(TransactionBoundXAResource.java:46)
        at 
org.jboss.tm.TransactionImpl$Resource.endResource(TransactionImpl.java:2143)
        at 
org.jboss.tm.TransactionImpl$Resource.endResource(TransactionImpl.java:2118)
        at 
org.jboss.tm.TransactionImpl.endResources(TransactionImpl.java:1462)
        at 
org.jboss.tm.TransactionImpl.beforePrepare(TransactionImpl.java:1116)
        at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:324)
        ... 45 more

I really don't know why this happens - Do you have any other idea?
Do you know somebody who may have tested the XASessionImpl in a JBoss 
EJB3 SLSB (I saw that Jukka added/committed the jcr-ds.xml file)?


kind regards and many thanks,
Markus



Dominique Pfister schrieb:
> Hi Markus
>
> and what about creating references in the local JNDI namespace instead
> of directly referencing objects in the global one? I found a section
> talking about resource references within XML deployment descriptors in
> this JBoss EJB 3.0 tutorial:
>
> http://docs.jboss.com/ejb3/app-server/tutorial/jboss_resource_ref/jboss_rr.html
>
> Does that help?
> Dominique
>
> On 8/7/07, Markus Reis <markus.reis@researchstudio.at> wrote:
>   
>> Hi Dominique,
>>
>>
>> here's where it really gets strange - I'm also accessing the jackrabbit
>> repository through my own JSF application using:
>>             InitialContext context = new InitialContext();
>>             Repository repository = (Repository)
>> context.lookup("java:jcr/local");
>>             SimpleCredentials credentials = new
>> SimpleCredentials(username, password.toCharArray());
>>             Session session = repository.login(credentials);
>> and subsequent operations on the repository in this session work without
>> any problems.
>>
>> Then I have an EJB (3.0, SLSB) with the following code:
>>             InitialContext ctx = new InitialContext();
>>             Repository repo = (Repository)ctx.lookup("java:jcr/local");
>>             Credentials cred = new SimpleCredentials(path.getUsername(),
>> path.getPassword());
>>             Session session = repo.login(cred, null);
>> and here subsequent calls bring up the reported problems.
>>
>> Do you have any idea what is wrong in the EJB (or what I could try
>> alternatively - Do I have to add certain annotations regarding CMT?)?
>>
>>
>> many thanks,
>> Markus
>>
>> Dominique Pfister schrieb:
>>     
>>> 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 = new InitialContext();
>>>     Repository repository = (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/%3C9064463.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
in
>>>>> 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-definition>
>>>>>         <config-property name="homeDir"
>>>>> type="java.lang.String">${jboss.server.data.dir}${/}jackrabbit</config-property>
>>>>>         <config-property name="configFile"
>>>>> type="java.lang.String">classpath:repository.xml</config-property>
>>>>>         <config-property name="bindSessionToTransaction"
>>>>> type="java.lang.Boolean">false</config-property>
>>>>>     </tx-connection-factory>
>>>>>    </connection-factories>
>>>>>
>>>>> Here's my client code:
>>>>>     XAResource xares =
>>>>> ((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 = 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 = session.getRootNode();
>>>>>             Node child = root.hasNode(path.getRelativePath()) ?
>>>>> root.getNode(path.getRelativePath()) : createFilePath(root,
>>>>> path.getPathParts(), path.getObjectName());
>>>>>             FileTypeResolver ftr = FileTypeResolver.instantiate();
>>>>>             child.setProperty("jcr:mimeType", ftr.getMIMEType(obj));
>>>>>             child.setProperty("jcr:data", new FileInputStream(obj));
>>>>>             Calendar rightNow = 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
on
>>>>> 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 – FN 115980i – ATU14703506
>>>>
>>>>
>>>>
>>>>         
>> --
>> 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 – FN 115980i – ATU14703506
>>
>>
>>     


-- 
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 – FN 115980i – ATU14703506


Mime
View raw message