It would be convenient to be able to construct a TransientRepository
with an InputStream or URL as argument for the repository config file
instead of a filename, when the repository config file is included as
part of a web application. This would allow the application to be
configured even when
[ http://issues.apache.org/jira/browse/JCR-415?page=all ]
Jukka Zitting updated JCR-415:
--
Attachment: jackrabbit-query-r421461.patch
> Yes, you are right. I thought I could get away with the dirty solution ;)
Well, as they say, do the simplest thing that c
On 7/12/06, Jukka Zitting <[EMAIL PROTECTED] > wrote:
Hi,
hi
On 7/12/06, robert burrell donkin < [EMAIL PROTECTED]> wrote:
> it strikes me that it's more natural to store emails plus meta-data in a
content
> repository such as jackrabbit rather than in a classic RDBMS.
> [...]
> 1 is jackra
Hi,
On 7/13/06, Nicolas <[EMAIL PROTECTED]> wrote:
Ok for me. I'll work on this tonight and send a patch ASAP. (How do I
differenciate Jackrabbit's patches to Core's one in our naming scheme)?
Thanks. Use for example jackrabbit-nn.patch vs. backup-nn.patch
BR,
Jukka Zitting
--
Yukatan - htt
On 7/13/06, Christoph Kiehl <[EMAIL PROTECTED]> wrote:
Stefan Guggisberg wrote:
>> Very nice! Didn't know that. How am I supposed to use the
>> NodeTypeRegistry? I
>> could use Workspace.getNodeTypeManager() cast it to
>> NodeTypeManagerImpl and call
>> getNodeTypeRegistry. But is there a better
Stefan Guggisberg wrote:
Very nice! Didn't know that. How am I supposed to use the
NodeTypeRegistry? I
could use Workspace.getNodeTypeManager() cast it to
NodeTypeManagerImpl and call
getNodeTypeRegistry. But is there a better way to get the
NodeTypeRegistry
without knowing about NodeTypeMana
[
http://issues.apache.org/jira/browse/JCR-477?page=comments#action_12420869 ]
Darren Hartford commented on JCR-477:
-
confirmed, removing log4j.jar and modifying the log4j.xml file corrected the
logging problem. Also tested on 421603, and the described
[ http://issues.apache.org/jira/browse/JCR-402?page=all ]
Stefan Guggisberg closed JCR-402:
-
Resolution: Won't Fix
cleaning up "Open Issues" list
> release module jackrabbit-bdb 1.0
> -
>
> Key: JCR-402
>
[ http://issues.apache.org/jira/browse/JCR-298?page=all ]
Stefan Guggisberg closed JCR-298:
-
cleaning up "Open Issues" list
> missing blob.remove in Berkeley DB persistance manager
> --
>
> K
[ http://issues.apache.org/jira/browse/JCR-215?page=all ]
Stefan Guggisberg closed JCR-215:
-
cleaning up "Open Issues" list
> Code depends on Log4J directly
> --
>
> Key: JCR-215
> URL: http://issues.apache
Ok for me. I'll work on this tonight and send a patch ASAP. (How do I
differenciate Jackrabbit's patches to Core's one in our naming scheme)?
Nicolas
On 7/13/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi,
On 7/12/06, Nicolas <[EMAIL PROTECTED]> wrote:
> I need to modify the code of the Conf
On 7/13/06, Christoph Kiehl <[EMAIL PROTECTED]> wrote:
Stefan Guggisberg wrote:
>> in our current system we are able to extend nodetypes by adding
>> properties or
>> nodes after the nodetype has been initially created. These
>> properties/childnodes
>> have to be non-mandatory.
>> As of now Jac
Stefan Guggisberg wrote:
in our current system we are able to extend nodetypes by adding
properties or
nodes after the nodetype has been initially created. These
properties/childnodes
have to be non-mandatory.
As of now Jackrabbit doesn't support this. Are there any reason
besides 'it's
just
[
http://issues.apache.org/jira/browse/JCR-478?page=comments#action_12420824 ]
Paco Avila commented on JCR-478:
But get the System Session would simplify a lot this work. The best way would
be implemente a standar AccessManager with user and roles. I'm writ
On 7/13/06, Christoph Kiehl <[EMAIL PROTECTED]> wrote:
Hi,
in our current system we are able to extend nodetypes by adding properties or
nodes after the nodetype has been initially created. These properties/childnodes
have to be non-mandatory.
As of now Jackrabbit doesn't support this. Are there
[
http://issues.apache.org/jira/browse/JCR-478?page=comments#action_12420820 ]
Stefan Guggisberg commented on JCR-478:
---
-1
i intentionally avoided passing a Session, ItemStateManager or similar in the
AccessManagerContext.
an AccessManager must IMO n
El jue, 13-07-2006 a las 10:24 +0200, Christoph Kiehl escribió:
> Hi,
>
> in our current system we are able to extend nodetypes by adding properties or
> nodes after the nodetype has been initially created. These
> properties/childnodes
> have to be non-mandatory.
> As of now Jackrabbit doesn't
Hi,
in our current system we are able to extend nodetypes by adding properties or
nodes after the nodetype has been initially created. These properties/childnodes
have to be non-mandatory.
As of now Jackrabbit doesn't support this. Are there any reason besides 'it's
just not implemented' why t
[
http://issues.apache.org/jira/browse/JCR-476?page=comments#action_12420814 ]
Tobias Bocanegra commented on JCR-476:
--
i totally agree to remove all QName/Path methods from NamespaceResolver. But
moving the caching caps to NameFormat might not be optim
Improve ability to access item in the AccessManager context.
Key: JCR-478
URL: http://issues.apache.org/jira/browse/JCR-478
Project: Jackrabbit
Type: Improvement
Reporter: Tobias Bocanegra
The curren
Issue Subscription
Filter: open issues (33 issues)
Open Issues for Apache Jackrabbit
Subscriber: jackrabbitdev
Key Summary
JCR-320 BinaryValue equals fails for two objects with two different byte
arrays that contain the same bytes.
http://issues.apache.org/jira/browse/JCR
Darren Hartford (JIRA) wrote:
[...] object is not assignable to a "o rg.apache.log4j.spi.ErrorHandler"
variable.
Just a wild guess, but is this caused by a configuration error?
The above class name looks very strange with the space in it.
regards
m
El jue, 13-07-2006 a las 08:47 +0200, Angela Schreiber escribió:
> hi paco
>
> Paco Avila wrote:
> > If I create a lock with isSessionScoped=false, when I perform logout and
> > login I have a new session and can't unlock this node. Should I
> > serialize and reutilize the session?
>
> for the op
I do the followin steps:
* node.lock()
* session.getLockTokens() -> This show the lock token generated by the
previous lock.
* node.unlock()
* session.getLockTokens() -> Still show me the generated token ¿?¿?
If I unlock a node, the token should'n be delete from the session?
--
Paco Avila <[EMAI
24 matches
Mail list logo
