Re: Jackrabbit servlet-api dependency

 <at> Minos : Perhaps you can re-send it, with Ate's comments included to
the dev list. Hopefully someone on that list more familiar with the
webdav module can inform us.

Would it be hard to create a patch containing the fix as suggested by Ate?

Regards Ard

On Wed, Feb 29, 2012 at 5:40 PM, Minos Chatzidakis
<m.chatzidakis <at> onehippo.com> wrote:
> No, no comment yet on the question.
>
> I agree it's very weird (and the first time I see it) implementing the
> servlet Request/Response. I suppose it was easier this way to support the
> http SEARCH method..
> A wrapper though could manage it quite as well...
>
> Anyway, thnx for looking into this
>
>
> On Wed, Feb 29, 2012 at 5:13 PM, Ate Douma <ate <at> douma.nu> wrote:
>
>> Any comment on this question?
>>
>> Looking just briefly at the code it seems odd to me in the first place
>> that jackrabbit-webdav itself implements the ServletRequest class, whereas
>> these interfaces are supposed to be container managed and implemented.
>>
>> Why isn't a HttpServletRequestWrapper used as base class instead?
>> Now this WebdavRequestImpl is missing methods added to Servlet API 2.4+,

Re: Jackrabbit servlet-api dependency

Well I don't think patching it is simple. This because looking at the
request and response implementations, I see these are kinda of wrappers
too. It's like a hybrid. These implementations provide a constructor that
accepts the original (container managed) request or response and they do
delegate most of the calls to the managed request/response. I think the
main problem is that webdav is http and they need to support some
extensions on this. Like, new status codes, being stateful (I'm seeing a
webdav session), supporting the http SEARCH method and more, low level
additions to the http request and response. From my point of view I don't
see something a wrapper couldn't handle. But implementing servlet
request/response is so unusual that I guess I'm missing something, there
must be more serious reasons for this.

 <at> Ard: yes using the dev-list sounds like a very good idea. Thnx

Regards,
Minos

On Thu, Mar 1, 2012 at 9:12 AM, Ard Schrijvers <a.schrijvers <at> onehippo.com>wrote:

>  <at> Minos : Perhaps you can re-send it, with Ate's comments included to
> the dev list. Hopefully someone on that list more familiar with the
> webdav module can inform us.
>
> Would it be hard to create a patch containing the fix as suggested by Ate?
>
> Regards Ard
>
> On Wed, Feb 29, 2012 at 5:40 PM, Minos Chatzidakis
> <m.chatzidakis <at> onehippo.com> wrote:

Re: Jackrabbit servlet-api dependency

FWIW, I've yet to see a message which describes an actual problem. I
understand you think JR should be compiled against Servlet API 2.4,
but what problem is that going to solve? Are you getting an error
message? Is something not working correctly?

Regards,
Justin

On Thu, Mar 1, 2012 at 6:28 AM, Minos Chatzidakis
<m.chatzidakis <at> onehippo.com> wrote:
> Well I don't think patching it is simple. This because looking at the
> request and response implementations, I see these are kinda of wrappers
> too. It's like a hybrid. These implementations provide a constructor that
> accepts the original (container managed) request or response and they do
> delegate most of the calls to the managed request/response. I think the
> main problem is that webdav is http and they need to support some
> extensions on this. Like, new status codes, being stateful (I'm seeing a
> webdav session), supporting the http SEARCH method and more, low level
> additions to the http request and response. From my point of view I don't
> see something a wrapper couldn't handle. But implementing servlet
> request/response is so unusual that I guess I'm missing something, there
> must be more serious reasons for this.
>
>  <at> Ard: yes using the dev-list sounds like a very good idea. Thnx
>
> Regards,
> Minos
>
>
> On Thu, Mar 1, 2012 at 9:12 AM, Ard Schrijvers <a.schrijvers <at> onehippo.com>wrote:

Re: Jackrabbit servlet-api dependency

There is no problem here, it works great! Only my IDE is marking those java
files red (files with errors). But really, no problem here.

I'm merely asking whether there was any specific reason to use servlet-api
2.3. It's like creating nowadays an application on java 1.4. Not really a
problem, but why? Cause if there's no reason for this, then I would
consider creating a patch.. should be trivial.

Thanks,
Minos

On Thu, Mar 1, 2012 at 1:58 PM, Justin Edelson <justin <at> justinedelson.com>wrote:

> FWIW, I've yet to see a message which describes an actual problem. I
> understand you think JR should be compiled against Servlet API 2.4,
> but what problem is that going to solve? Are you getting an error
> message? Is something not working correctly?
>
> Regards,
> Justin
>
> On Thu, Mar 1, 2012 at 6:28 AM, Minos Chatzidakis
> <m.chatzidakis <at> onehippo.com> wrote:
> > Well I don't think patching it is simple. This because looking at the
> > request and response implementations, I see these are kinda of wrappers
> > too. It's like a hybrid. These implementations provide a constructor that
> > accepts the original (container managed) request or response and they do
> > delegate most of the calls to the managed request/response. I think the
> > main problem is that webdav is http and they need to support some
> > extensions on this. Like, new status codes, being stateful (I'm seeing a

Re: RepositoryImpl closing sessions twice on shutdown

Seems like there is no wisdom or other interest in this issue, so I've logged it as
https://issues.apache.org/jira/browse/JCR-3246 since I failed to find a solution for the problem
apart from changing JR code.

Would be nice if this can be fixed in 1.4.1

Thanks,
Jan

On Feb 28, 2012, at 11:00 AM, Jan Haderka wrote:

> Hi,
> I ran into strange issue w/ JR 2.4.0. 
> On shutdown sessions are being closed twice which lead to the exception being logged as shown below. As far
as I can tell RepositoryImpl has system sessions in the list of active sessions which is why it tries to
close them twice - first time when closing all active sessions (RepositoryImpl.java:1078) and second
time when disposing workspace (RepositoryImpl.java:1090).
> 
> However I have no idea if the system session is supposed to be on the list of active sessions or not. 
> Also it seems to be related to timing - I have troubles reproducing the issue with debugger attached to the server.
> 
> Is this known issue? Any pointers to what to look for when preventing this issue from occurring?
> 
> Thanks,
> Jan
> 
> 
> 2012-02-28 10:36:00,614 WARN  org.apache.jackrabbit.core.session.SessionState   : Attempt to close
session-31 after it has already been closed. Please review your code for proper session management.
> java.lang.Exception: Stack trace of the duplicate attempt to close session-31

Clustering and WebDAV

CacheManager access on JBoss 7

Hi,

I am using Jakcrabbit 2.2.9 on JBoss 7 with JCA. I get repository/session in my code using:
repository = (Repository) new InitialContext().lookup(config.getJndiName());

This repository is JCARepositoryHandle. I need to get RepositoryImpl so that I can get CacheManeger but
due to class loading in JBoss I cannot use:
        Session session = repository.login(config.getCredentials());
        RepositoryImpl r = (RepositoryImpl) session.getRepository();

because class RepositoryImpl in my code and returned from session are loaded by different classloader. Is
there any way how to access Jackrabbti API/core classes? (I had the same problem with
DataStoreGarbageCollector.) So far I did not find
any solution to this. Or I need some other way how to change CacheManager setting.

If I understand correctly CacheManager limits memory used by all caches and max default is now 16MB so if I
set bundleCacheSize on higher value it has no effect right?

Thanks

Marek

Marek Slama
mslama <at> email.cz

Re: CacheManager access on JBoss 7

By looking at code I found that CacheManager is actually using system property so I must set system property
for it.
Still I am interested if there is any way how to access Jackrabbit API/core in JBoss. I know JCR API is used as
JBoss module so its classes should be loaded just once. I even tried to make also some Jackrabbit jars as
JBoss modules but it did not work for me. I could not initialize connection then. Is there anybody who
successfuly solved this problem on JBoss 7?

Thanks

Marek

> ------------ Původní zpráva ------------
> Od:  <mslama <at> email.cz>
> Předmět: CacheManager access on JBoss 7
> Datum: 02.3.2012 13:01:08
> ----------------------------------------
> Hi,
> 
> I am using Jakcrabbit 2.2.9 on JBoss 7 with JCA. I get repository/session in my
> code using:
> repository = (Repository) new InitialContext().lookup(config.getJndiName());
> 
> This repository is JCARepositoryHandle. I need to get RepositoryImpl so that I
> can get CacheManeger but due to class loading in JBoss I cannot use:
>         Session session = repository.login(config.getCredentials());
>         RepositoryImpl r = (RepositoryImpl) session.getRepository();
> 
> because class RepositoryImpl in my code and returned from session are loaded by
> different classloader. Is there any way how to access Jackrabbti API/core
> classes? (I had the same problem with DataStoreGarbageCollector.) So far I did
> not find
> any solution to this. Or I need some other way how to change CacheManager
> setting.
> 
> If I understand correctly CacheManager limits memory used by all caches and max
> default is now 16MB so if I set bundleCacheSize on higher value it has no effect
> right?
> 
> Thanks
> 
> Marek
> 
> 
> Marek Slama
> mslama <at> email.cz
> 
> 
> 

Marek Slama
mslama <at> email.cz

Is it possible to change the property of a version node from versionStorage?

I have some xml files kept inside jcr which also have versions.

I want to update my xml data with other xml (obtained with xslt from the
older one) on all my nodes. I can do this for all nodes in my repository,
except the versions nodes. 

I get all my version nodes with an xpath like :

/jcr:root/jcr:system/jcr:versionStorage//*[ <at> className='....' and
 <at> type='...']//*[fn:name()='jcr:content' and  <at> jcr:mimeType='text/xml']

I get my xml content property:

node.getProperty("jcr:data")

I convert this xml to the new xml format with an xslt transformation.

Then I want to  save the new content:

node.setProperty ("jcr:data", binaryValue); 

An exception is raised:

ConstraintViolationException: Unable to perform operation. Node is protected

Is this because version nodes are read only? Is it possible to change the
property of a version node?

--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Is-it-possible-to-change-the-property-of-a-version-node-from-versionStorage-tp4438579p4438579.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

CacheManager settings, maxMemory, maxMemoryPerCache

Hi,

I am experimenting with CacheManager settings. I found that setting bundleCacheSize in repository.xml
is not relevant anymore in 2.2.9 because AbstractBundlePersistenceManager uses ConcurrentCache as
other parts of Jackrabbit. I want to ask what is then recommended ratio between maxMemory and
maxMemoryPerCache. CacheManager resizes caches according usage policy but it handles all caches
equally so there is no way how to say keep size of cache for AbstractBundlePersistenceManager fixed. I
enabled logging for CacheManager set maxMemory == maxMemoryPerCache in hope that when eg bundle cache
will need more memory it will take it and keep it. But actually it fluctuates as follows:

resizeAll size=4 
 org.apache.jackrabbit.core.cache.ConcurrentCache <at> ceb95b now:131072 used:0 access:0 new:131072
 org.apache.jackrabbit.core.cache.ConcurrentCache <at> 1ec3263 now:131072 used:78000 access:0 new:131072
 org.apache.jackrabbit.core.cache.ConcurrentCache <at> 18f89c9 now:502135168 used:89953950
access:12192 new:89953950
 org.apache.jackrabbit.core.cache.ConcurrentCache <at> 174a57e now:34473600 used:34473600 access:0 new:446654818
 resizeAll size=4
 org.apache.jackrabbit.core.cache.ConcurrentCache <at> ceb95b now:131072 used:0 access:0 new:131072
 org.apache.jackrabbit.core.cache.ConcurrentCache <at> 1ec3263 now:131072 used:78000 access:0 new:131072
 org.apache.jackrabbit.core.cache.ConcurrentCache <at> 18f89c9 now:89953950 used:89953550
access:8763 new:502135168
 org.apache.jackrabbit.core.cache.ConcurrentCache <at> 174a57e now:446654818 used:34473600 access:0 new:34473600
 resizeAll size=4
 org.apache.jackrabbit.core.cache.ConcurrentCache <at> ceb95b now:131072 used:0 access:0 new:131072
 org.apache.jackrabbit.core.cache.ConcurrentCache <at> 1ec3263 now:131072 used:78000 access:0 new:131072
 org.apache.jackrabbit.core.cache.ConcurrentCache <at> 18f89c9 now:502135168 used:92719750
access:9144 new:92719750
 org.apache.jackrabbit.core.cache.ConcurrentCache <at> 174a57e now:34473600 used:34473600 access:0 new:443889018
 resizeAll size=4
 org.apache.jackrabbit.core.cache.ConcurrentCache <at> ceb95b now:131072 used:0 access:0 new:131072
 org.apache.jackrabbit.core.cache.ConcurrentCache <at> 1ec3263 now:131072 used:78000 access:0 new:131072
 org.apache.jackrabbit.core.cache.ConcurrentCache <at> 18f89c9 now:92719750 used:92719650
access:9906 new:502135168
 org.apache.jackrabbit.core.cache.ConcurrentCache <at> 174a57e now:443889018 used:34473600 access:0 new:34473600

Is there any way how to change this? It might be good to set some cache instance fixed eg. bundle cache and rest
let to be managed by CacheManager.

Marek