Paco Avila | 1 Aug 2006 08:52
Picon
Favicon

No way to implemente an AccessManager?

I've been reading posts about implementing an AccessManager that stores
access information as node properties. The solution I've seen is to use
a systemSession to access this node properties. Now, I'm programming my
own AccessManager with this approach and there is an bug reported in
http://issues.apache.org/jira/browse/JCR-497. The AccessManager throws
an exception because 'systemSession' can't see new transient nodes of
another session. So, how can I deal with this?

Tobias Bocanegra | 1 Aug 2006 11:20
Favicon
Gravatar

Re: No way to implemente an AccessManager?

you can't :-)
regards, toby

On 8/1/06, Paco Avila <pavila <at> git.es> wrote:
> I've been reading posts about implementing an AccessManager that stores
> access information as node properties. The solution I've seen is to use
> a systemSession to access this node properties. Now, I'm programming my
> own AccessManager with this approach and there is an bug reported in
> http://issues.apache.org/jira/browse/JCR-497. The AccessManager throws
> an exception because 'systemSession' can't see new transient nodes of
> another session. So, how can I deal with this?
>
> --
> Paco Avila <pavila <at> git.es>
>
>

Jukka Zitting | 1 Aug 2006 11:22
Picon
Gravatar

Re: Patches for JavaDoc warnings

Hi,

On 7/31/06, Julian Reschke <julian.reschke <at> gmx.de> wrote:
> attached is a set of patches to reduce the number of JavaDoc warnings (I
> guess we don't want to open an issue for that, right? :-).

Thanks! Committed as related to the javadoc issue JCR-73.

In general I would prefer to process all patches through Jira for
better tracking of changes and contributions.

BR,

Jukka Zitting

Julian Reschke | 1 Aug 2006 11:50
Picon
Picon

Re: Patches for JavaDoc warnings

Jukka Zitting schrieb:
> Thanks! Committed as related to the javadoc issue JCR-73.

Thanks.

> In general I would prefer to process all patches through Jira for
> better tracking of changes and contributions.

Ok. In this particular case, does it make sense to open a new JIRA issue 
  for each Javadoc fix, or should it be re-used when needed?

Best regards, Julian

Paco Avila | 1 Aug 2006 11:56
Picon
Favicon

Re: No way to implemente an AccessManager?

And now which possibilites do I have? Is possible to implement an custom
AccessManager actually?

El mar, 01-08-2006 a las 11:20 +0200, Tobias Bocanegra escribió:
> you can't :-)
> regards, toby
> 
> On 8/1/06, Paco Avila <pavila <at> git.es> wrote:
> > I've been reading posts about implementing an AccessManager that stores
> > access information as node properties. The solution I've seen is to use
> > a systemSession to access this node properties. Now, I'm programming my
> > own AccessManager with this approach and there is an bug reported in
> > http://issues.apache.org/jira/browse/JCR-497. The AccessManager throws
> > an exception because 'systemSession' can't see new transient nodes of
> > another session. So, how can I deal with this?
> >
> > --
> > Paco Avila <pavila <at> git.es>
> >
> >
> 
> 
Jukka Zitting | 1 Aug 2006 12:06
Picon
Gravatar

Re: Patches for JavaDoc warnings

Hi,

On 8/1/06, Julian Reschke <julian.reschke <at> gmx.de> wrote:
> > In general I would prefer to process all patches through Jira for
> > better tracking of changes and contributions.
>
> Ok. In this particular case, does it make sense to open a new JIRA issue
> for each Javadoc fix, or should it be re-used when needed?

You can attach Javadoc patches to the generic Javadoc issue JCR-73.

BR,

Jukka Zitting

Jukka Zitting | 1 Aug 2006 12:17
Picon
Gravatar

Re: No way to implemente an AccessManager?

Hi,

On 8/1/06, Paco Avila <pavila <at> git.es> wrote:
> And now which possibilites do I have? Is possible to implement an custom
> AccessManager actually?

I suppose your problem is caused by Jackrabbit asking for permissions
on a node that hasn't yet been persisted, so you can't access it from
your AccessManager. I'm not sure how this is best handled, but one
workaround could be to just grant all permissions on such nodes. After
all the transient nodes are still completely controlled by that
session.

BR,

Jukka Zitting

Christoph Kiehl (JIRA | 1 Aug 2006 13:03
Picon
Favicon

Updated: (JCR-332) maven2 pom contribution

     [ http://issues.apache.org/jira/browse/JCR-332?page=all ]

Christoph Kiehl updated JCR-332:
--------------------------------

    Attachment: pom.xml.patch

Added a patch which does the following:

- Change artifactId from "jackrabbit" to "jackrabbit-core"
- Omit generating XPath.jjt 
- Use javacc 3.2 because with 4.0 I got syntax errors
- Set system properties for unit tests

There is still some work to do to get the tests running, but at least I can build jackrabbit with "maven
-Dmaven.test.skip=true install"

> maven2 pom contribution
> -----------------------
>
>                 Key: JCR-332
>                 URL: http://issues.apache.org/jira/browse/JCR-332
>             Project: Jackrabbit
>          Issue Type: New Feature
>          Components: maven
>    Affects Versions: 1.0, 1.0.1, 0.9
>            Reporter: fabrizio giustina
>         Assigned To: Jukka Zitting
>            Priority: Minor
>             Fix For: 1.1
(Continue reading)

Jukka Zitting (JIRA | 1 Aug 2006 13:11
Picon
Favicon

Commented: (JCR-332) maven2 pom contribution

    [ http://issues.apache.org/jira/browse/JCR-332?page=comments#action_12424821 ] 

Jukka Zitting commented on JCR-332:
-----------------------------------

Thanks for the update! Committed in revision 427531.

> maven2 pom contribution
> -----------------------
>
>                 Key: JCR-332
>                 URL: http://issues.apache.org/jira/browse/JCR-332
>             Project: Jackrabbit
>          Issue Type: New Feature
>          Components: maven
>    Affects Versions: 1.0, 1.0.1, 0.9
>            Reporter: fabrizio giustina
>         Assigned To: Jukka Zitting
>            Priority: Minor
>             Fix For: 1.1
>
>         Attachments: pom.xml, pom.xml, pom.xml.patch
>
>
> If you are interested in migrating to maven2 (or adding optional maven 2 build scripts) this is a full maven
2 pom.xml for the main jackrabbit jar.
> All the xpath/javacc stuff, previously done in maven.xml, was pretty painfull to reproduce in maven2...
the attached pom exactly reproduces the m1 build by using the maven2 javacc plugin + a couple of antrun executions.
> Test configuration is not yet complete, I think it will be a lot better to reproduce the previous behaviour
(init tests run first) without any customization (maybe using a single junit test suite with setUp
(Continue reading)

Paco Avila | 1 Aug 2006 13:34
Picon
Favicon

Re: No way to implemente an AccessManager?

El mar, 01-08-2006 a las 13:17 +0300, Jukka Zitting escribió:
> Hi,
> 
> On 8/1/06, Paco Avila <pavila <at> git.es> wrote:
> > And now which possibilites do I have? Is possible to implement an custom
> > AccessManager actually?
> 
> I suppose your problem is caused by Jackrabbit asking for permissions
> on a node that hasn't yet been persisted, so you can't access it from
> your AccessManager. I'm not sure how this is best handled, but one
> workaround could be to just grant all permissions on such nodes. After
> all the transient nodes are still completely controlled by that
> session.
> 

Thanks, I was thinking in this workaround and I was not sure it was a
good idea. I will try it and check for possible problems.

Thanks again :)

Gmane