jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Pfister" <dominique.pfis...@day.com>
Subject Re: [Re: Re: JBoss and Jackrabbit JCA]
Date Fri, 17 Aug 2007 08:19:57 GMT
Hi Markus,

that's great news! Before adding this to jcr-ds.xml, I'd like to
understand why this setting makes the resource adapter work: as far as
I understand, it is meant to overcome a limitation on the datasource
side and I don't see what Jackrabbit's resource adapter is doing wrong
that makes this setting necessary. Can you possibly provide a small
test EJB/application and guide that helps reproducing this "no
transaction" error? If it really turned out to be some missing
functionality in our resource adapter that could also affect other
application servers I'd rather like to fix that.

Kind regards
Dominique

On 16/08/07, Markus Reis <markus.reis@researchstudio.at> wrote:
> Hi Dominique,
>
>
> I finally solved the problem ... The "trick" was to set
> <track-connection-by-tx/> in the jcr-ds.xml datasource configuration; It
> should be:
> <connection-factories>
>  <tx-connection-factory>
>  <jndi-name>jcr/local</jndi-name>
>  <xa-transaction/>
>  <rar-name>jackrabbit-jca-1.3.1.rar</rar-name>
>  <track-connection-by-tx/>
>  <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>
>
> Further information on this property can be found under:
> http://docs.jboss.org/jbossas/jboss4guide/r2/html/ch7.chapt.html#ch7.xaconf.fig
>
>
> I think that we/you/someone (Jukka) should update
> jackrabbit-jca\deploy\jboss\4.x\jcr-ds.xml accordingly - What do you think?
>
>
> kind regards,
> Markus
>
> Markus Reis schrieb:
> > 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