In XASessionImpl#end, the javadoc says:
* If TMFAIL is specified, we disassociate this session from
* the transaction specified and mark the transaction rollback
only.
But the actual implementation doesn't mark as rollback only:
if (flags == TMSUCCESS || flags == TMFAIL || fl
Yes, we would be very interested in this too.
Cheers,
Rob.
-Original Message-
From: Angela Schreiber [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 06, 2006 6:38 AM
To: dev@jackrabbit.apache.org
Subject: SPI contribution to Jackrabbit
hi
in JSR-283 internal discussion it has been deci
I would be interested as well
Kevin
-Original Message-
From: Julian Reschke [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 06, 2006 4:44 AM
To: dev@jackrabbit.apache.org
Subject: Re: SPI contribution to Jackrabbit
Angela Schreiber schrieb:
> hi
>
> in JSR-283 internal discussion i
Angela Schreiber schrieb:
hi
in JSR-283 internal discussion it has been decided, that
the issue covering a service provider interface (SPI) should
rather not be part of the follow-up specification.
this offers the possibility to open the discussion for
a broader audience and the expert group ag
Hi all,
I have the following configuration:
Tomcat 5.5.17
Java 1.5_07
JackRabbit 1.0
Webapp using JackRabbit
My problem is that when i hot redploy my webapp on the tomcat container, the
webapp fails to start since the JackRabbit repository has a .lock file which
is locked to tomcat. I have to
hi
in JSR-283 internal discussion it has been decided, that
the issue covering a service provider interface (SPI) should
rather not be part of the follow-up specification.
this offers the possibility to open the discussion for
a broader audience and the expert group agreed on
contributing the ex
[
http://issues.apache.org/jira/browse/JCR-473?page=comments#action_12419466 ]
Tobias Bocanegra commented on JCR-473:
--
> i guess you responded to a post, which gmail considered to be written by
> jukka...
> hehthey start getting subversive... it w
[
http://issues.apache.org/jira/browse/JCR-473?page=comments#action_12419464 ]
Stefan Guggisberg commented on JCR-473:
---
> Julian Reschke commented on JCR-473:
>
>
> Regarding QName...:
>
> Did anybody consider to
[
http://issues.apache.org/jira/browse/JCR-473?page=comments#action_12419462 ]
Jukka Zitting commented on JCR-473:
---
Julian:
> Did anybody consider to require JAXP 1.3 (available as seperate download for
> JDK 1.4), and just to use javax.xml.namespace.QNam
[
http://issues.apache.org/jira/browse/JCR-473?page=comments#action_12419461 ]
angela commented on JCR-473:
Tobi:
> but i ment 'jukka'. it was a response to your post :-)
i guess you responded to a post, which gmail considered to be written by
jukka... heh..
[
http://issues.apache.org/jira/browse/JCR-473?page=comments#action_12419460 ]
Marcel Reutegger commented on JCR-473:
--
Yes, I did, but the JCR QName are different from an XML QName. E.g. in JCR you
may start a name with a digit, which is not possible i
[
http://issues.apache.org/jira/browse/JCR-473?page=comments#action_12419458 ]
Julian Reschke commented on JCR-473:
Regarding QName...:
Did anybody consider to require JAXP 1.3 (available as seperate download for
JDK 1.4), and just to use javax.xml.nam
[
http://issues.apache.org/jira/browse/JCR-473?page=comments#action_12419456 ]
Jukka Zitting commented on JCR-473:
---
Tobias:
> but i ment 'jukka'. it was a response to your post :-)
Ah, OK. Just got confused as I didn't mention anything about ValueFactori
[
http://issues.apache.org/jira/browse/JCR-473?page=comments#action_12419453 ]
Tobias Bocanegra commented on JCR-473:
--
> Tobias:
> > jukka, you're right
>
> It was Angela, credit where credit is due. :-)
but i ment 'jukka'. it was a response to your po
[
http://issues.apache.org/jira/browse/JCR-473?page=comments#action_12419447 ]
angela commented on JCR-473:
and for the latter (modifications within core classes) i suggested 2 solutions
from the top of my head (because i was thinking about this before). if you
[
http://issues.apache.org/jira/browse/JCR-473?page=comments#action_12419446 ]
angela commented on JCR-473:
a bit? i'm angela not jukka... unfortunately ;)
> i would put all convertion code into ValueHelper, and
> ValueFactoryImpl and InternalValue can then ma
[
http://issues.apache.org/jira/browse/JCR-473?page=comments#action_12419445 ]
Jukka Zitting commented on JCR-473:
---
Tobias:
> jukka, you're right
It was Angela, credit where credit is due. :-)
I think you're right about questioning the excessive passing
[
http://issues.apache.org/jira/browse/JCR-473?page=comments#action_12419443 ]
Tobias Bocanegra commented on JCR-473:
--
sorry. i'm a bit dizzy today:
- this was just a first ides but you're right.
+ this was just a first idea but you're right.
- somewh
[ http://issues.apache.org/jira/browse/JCR-475?page=all ]
Tobias Bocanegra closed JCR-475:
Resolution: Invalid
the failing constraints is not a bug of the CNDReader. The JSR170 specification
states:
6.7.16 Value Constraints:
[...]
The remaining ty
[ http://issues.apache.org/jira/browse/JCR-441?page=all ]
Rod Mackenzie updated JCR-441:
--
Attachment: lock.patch
This patch includes the test case originally supplied and a possible fix.
> Session logout doesn't release locks acquired using addLockToken
>
[
http://issues.apache.org/jira/browse/JCR-473?page=comments#action_12419439 ]
Tobias Bocanegra commented on JCR-473:
--
jukka, you're right. ValueFactory has nothing to do with resolving names.
> moving the InternalValue.create to the ValueHelper looks
[
http://issues.apache.org/jira/browse/JCR-473?page=comments#action_12419425 ]
angela commented on JCR-473:
2. So, not passing the ValueFactory throughout the code, could be solved by:
- leave InternalValue as proposed in the patch
- remove usage of InternalVa
22 matches
Mail list logo
