headers
Angela Schreiber | 1 Feb 2011 11:57
Picon
Favicon

Re: Seeking help finding session leak using davex.

hi luis

could you please shed some light on the circumstances that
produces the error log entry? with the information present
it's hard to tell what could go wrong...

could you please post a testcase to execute with the client side or
on the spi2dav layer directly that allows to reproduce the problem? 
alternatively the corresponding http conversation log could be helpful
(althought probably much more verbose).

see AbstractJCRTest or AbstractSPITest for base classes
used as starting point for writing test cases against the
jcr-client or the SPI.

thanks
angela

On 1/31/11 3:40 PM, Luis Muniz wrote:
> Bump?
>
> On Wed, Jan 26, 2011 at 3:58 PM, Luis Muniz<neur0maner <at> gmail.com>  wrote:
>
>> Hi,
>>
>> I am using davex to access a jackrabbit 2.2.1 repository remotely.
>>
>> Everything works OK, only I see these messages in the jackrabbit log:
>>
>> 2011-01-26 13:11:24.713 ERROR [444092735 <at> qtp-1957835280-22]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Viper Viper | 1 Feb 2011 15:02
Picon

[TransientRepository] Session closed/opened

Hi ,
I'm  wonder if is possible somehow easily turn off  logging of transient
repository when is Session open and close .
It's little bit unnecessarily to see all this rows in logs , but I don't
want to change level logging of jackrabbit.

Thanks

Example :

14:11:39,687 INFO  [TransientRepository] Session closed
14:11:39,687 INFO  [TransientRepository] Session opened
14:11:39,734 INFO  [TransientRepository] Session closed
14:11:39,750 INFO  [TransientRepository] Session opened
14:11:39,750 INFO  [TransientRepository] Session closed
14:11:39,750 INFO  [TransientRepository] Session opened
14:11:40,265 INFO  [TransientRepository] Session closed
14:11:40,265 INFO  [TransientRepository] Session opened
Permalink | Reply | 0 comments |
headers
GOODWIN, MATTHEW (ATTCORP | 1 Feb 2011 16:35
Picon
Favicon

Jackrabbit dependencies

We'd like to trim down the required dependencies that are deployed in
our application.  I've seen the output of the mvn dependency:tree but I
was curious if some of the poi dependencies can be excluded at runtime.
For example, I believe we can exclude the bouncy castle jars since we
know we aren't going to be handling encrypted pdfs and the derby jar
since we're not using oracle.  Any others?

Thanks,

Matt
Permalink | Reply | 21 comments |
headers
GOODWIN, MATTHEW (ATTCORP | 1 Feb 2011 16:41
Picon
Favicon

RE: Jackrabbit dependencies

I meant since we are using oracle. Sorry.

-----Original Message-----
From: GOODWIN, MATTHEW (ATTCORP) 
Sent: Tuesday, February 01, 2011 10:36 AM
To: users <at> jackrabbit.apache.org
Subject: Jackrabbit dependencies

We'd like to trim down the required dependencies that are deployed in
our application.  I've seen the output of the mvn dependency:tree but I
was curious if some of the poi dependencies can be excluded at runtime.
For example, I believe we can exclude the bouncy castle jars since we
know we aren't going to be handling encrypted pdfs and the derby jar
since we're not using oracle.  Any others?

Thanks,

Matt
Permalink | Reply | 0 comments |
headers
Jukka Zitting | 1 Feb 2011 16:58
Picon
Favicon
Gravatar

Re: Jackrabbit dependencies

Hi,

On 02/01/2011 04:35 PM, GOODWIN, MATTHEW (ATTCORP) wrote:
> We'd like to trim down the required dependencies that are deployed
> in our application.

Do you have some pressing need for this (size, licensing, etc.)? If not,
by far the easiest solution is just to leave the dependencies intact, as
otherwise you'll need to keep reviewing your custom deployment whenever
you do an upgrade as the dependency graph may have changed.

In the end it's just a few megabytes of extra bits which should nowadays
only be a problem if you're targeting a mobile or other embedded
environment. If you do and there's wider demand for something like this, 
we might want to consider including such a jackrabbit-lite package in 
our normal releases.

> I've seen the output of the mvn dependency:tree but I was curious if
> some of the poi dependencies can be excluded at runtime.

The POI libraries are used for full text indexing of various Microsoft 
file formats, most notably MS Office.

--

-- 
Jukka Zitting
Permalink | Reply | 19 comments |
headers
GOODWIN, MATTHEW (ATTCORP | 1 Feb 2011 17:07
Picon
Favicon

RE: Jackrabbit dependencies

No we are not really that resource constrained or license constrained.
For the maintenance headaches you stated I think we'll go with the
standard package - just was curious.  Thanks for the quick response.

Matt

-----Original Message-----
From: Jukka Zitting [mailto:jzitting <at> adobe.com] 
Sent: Tuesday, February 01, 2011 10:58 AM
To: users <at> jackrabbit.apache.org
Subject: Re: Jackrabbit dependencies

Hi,

On 02/01/2011 04:35 PM, GOODWIN, MATTHEW (ATTCORP) wrote:
> We'd like to trim down the required dependencies that are deployed
> in our application.

Do you have some pressing need for this (size, licensing, etc.)? If not,
by far the easiest solution is just to leave the dependencies intact, as
otherwise you'll need to keep reviewing your custom deployment whenever
you do an upgrade as the dependency graph may have changed.

In the end it's just a few megabytes of extra bits which should nowadays
only be a problem if you're targeting a mobile or other embedded
environment. If you do and there's wider demand for something like this,

we might want to consider including such a jackrabbit-lite package in 
our normal releases.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Guggisberg | 2 Feb 2011 12:28
Picon

Re: override property definition in node type definition?

On Mon, Jan 31, 2011 at 5:46 PM, sam lee <skynare <at> gmail.com> wrote:
> Hey, I have this:
>
> <example = 'http://www.example.com/1.0'>
> [example:Base] > nt:base
>    - * (undefined) multiple
>    - * (undefined)
>
> example:Base nodes can have all kinds of properties named anyway.
>
> [example:Derived] > example:Base
>
> In example:Derived, can I override so that only certain properties are
> valid?
>
> I want to mask some of property definitions of example:Base:
>    - * (undefined) multiple
>    - * (undefined)
>

that's unfortunately not possible. node type inheritance supports
aggregation but not overriding of child node/property definitions.

cheers
stefan

>
> Thanks.
> Sam
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Guggisberg | 2 Feb 2011 13:43
Picon

Re: Jackrabbit dependencies

On Tue, Feb 1, 2011 at 4:58 PM, Jukka Zitting <jzitting <at> adobe.com> wrote:
> Hi,
>
> On 02/01/2011 04:35 PM, GOODWIN, MATTHEW (ATTCORP) wrote:
>>
>> We'd like to trim down the required dependencies that are deployed
>> in our application.
>
> Do you have some pressing need for this (size, licensing, etc.)? If not,
> by far the easiest solution is just to leave the dependencies intact, as
> otherwise you'll need to keep reviewing your custom deployment whenever
> you do an upgrade as the dependency graph may have changed.
>
> In the end it's just a few megabytes of extra bits which should nowadays

sorry, but i don't agree. adding 'just a few megabytes' of extra dependencies
which the majority of the users won't need do add up in the end and
might cause conflicts in different deployment scenarios.

the recent addition of the netcdf library is IMO an excellent example.
apparently it did cause classloader issues, it increased the size of
stand-alone
jackrabbit by 15% and the majority of jackrabbit users will probably
never use it... [1]

just my 0.02$

cheers
stefan
(Continue reading)

Permalink | Reply | 17 comments |
headers
Norman Maurer | 2 Feb 2011 13:58
Picon
Favicon

Re: Jackrabbit dependencies

Good point Stefan,

thats exactly the cause why we (JAMES) exclude a bunch of
dependencies. I think jackrabbit would better be of to provide a
"light" distribution or mark things like these a optional.

Bye,
Norman

2011/2/2 Stefan Guggisberg <stefan.guggisberg <at> gmail.com>:
> On Tue, Feb 1, 2011 at 4:58 PM, Jukka Zitting <jzitting <at> adobe.com> wrote:
>> Hi,
>>
>> On 02/01/2011 04:35 PM, GOODWIN, MATTHEW (ATTCORP) wrote:
>>>
>>> We'd like to trim down the required dependencies that are deployed
>>> in our application.
>>
>> Do you have some pressing need for this (size, licensing, etc.)? If not,
>> by far the easiest solution is just to leave the dependencies intact, as
>> otherwise you'll need to keep reviewing your custom deployment whenever
>> you do an upgrade as the dependency graph may have changed.
>>
>> In the end it's just a few megabytes of extra bits which should nowadays
>
> sorry, but i don't agree. adding 'just a few megabytes' of extra dependencies
> which the majority of the users won't need do add up in the end and
> might cause conflicts in different deployment scenarios.
>
> the recent addition of the netcdf library is IMO an excellent example.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jukka Zitting | 2 Feb 2011 14:00
Picon
Favicon
Gravatar

Re: Jackrabbit dependencies

Hi,

On 02/02/2011 01:43 PM, Stefan Guggisberg wrote:
> the recent addition of the netcdf library is IMO an excellent
> example. apparently it did cause classloader issues, it increased the
> size of stand-alone jackrabbit by 15% and the majority of jackrabbit
> users will probably never use it... [1]

Yes, I agree that we had a bug (that got resolved) and that the netcdf 
dependency does bring in quite a bit of extra weight compared to the 
functionality it adds. I wouldn't object if people want to exclude it.

My point before was mostly that such decisions (what to include/exclude) 
are best made at the project level rather than separately in each 
individual deployment. We are at a much better position to understand 
where and how each dependency is being used, and have also tools for 
tracking and documenting such decisions across releases. If there are 
conflicting requirements (for example functionality vs. size), we can 
always add separate packagings for different deployment targets.

--

-- 
Jukka Zitting
Permalink | Reply | 12 comments |

Gmane