Return-Path: 
 <jackrabbit-dev-return-4855-apmail-incubator-jackrabbit-dev-archive=www.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-jackrabbit-dev-archive@www.apache.org
Received: (qmail 6380 invoked from network); 13 Dec 2005 17:13:11 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 13 Dec 2005 17:13:11 -0000
Received: (qmail 78182 invoked by uid 500); 13 Dec 2005 10:06:27 -0000
Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:jackrabbit-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:jackrabbit-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:jackrabbit-dev@incubator.apache.org>
List-Id: <jackrabbit-dev.incubator.apache.org>
Reply-To: jackrabbit-dev@incubator.apache.org
Delivered-To: mailing list jackrabbit-dev@incubator.apache.org
Received: (qmail 78171 invoked by uid 99); 13 Dec 2005 10:06:27 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Dec 2005 02:06:27 -0800
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [212.40.5.52] (HELO smtp.tiscali.ch) (212.40.5.52)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Dec 2005 02:06:25 -0800
Received: from [127.0.0.1] (adsl-177-92-fixip.tiscali.ch [212.254.177.92])
	by smtp.tiscali.ch (8.11.7/8.11.7) with ESMTP id jBDA63p00670
	for <jackrabbit-dev@incubator.apache.org>; Tue, 13 Dec 2005 11:06:03 +0100
Message-ID: <439E9D07.6060708@day.com>
Date: Tue, 13 Dec 2005 11:05:59 +0100
From: Felix Meschberger <Felix.Meschberger@day.com>
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: jackrabbit-dev@incubator.apache.org
Subject: Re: deploying to JBoss
References: <C2CDEFBECFC9A14892BCCFB4C95F486804E5A5@EX-201.mail.navisite.com>
In-Reply-To: <C2CDEFBECFC9A14892BCCFB4C95F486804E5A5@EX-201.mail.navisite.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Hi John,

John Mazzitelli wrote:

 >  I tried that but failed due to the repository impl. class not being 
serializable:

Have you taken a look at the  BindableRepository class ? This class is 
Referencable - a requirement fo some JNDI context providers - and 
serializable.

>         <init-param>
>             <param-name>jndi-bind-remote</param-name>
>             <param-value>true</param-value>
>         </init-param>
>
> If true, the servlet would then know that it should bind the *remote* repo object to the JNDI context, as opposed to the repository object reference itself.
>   
I do not think registering the remote object to the JNDI is in general a 
good idea - as always your mileage may vary. Especially considering that 
most of the applications accessing resources from JNDI within an 
application server are running locally to the application server and use 
JNDI to access deployed resources such as JDBC data sources - as always, 
there are exceptions if you for example access an LDAP server using the 
JNDI-API.

Regarding the startup of the repository, I think, that starting it from 
within a web application is a workaround for servlet containers without 
resource management support. In the case of JBoss I would suggest 
deploying the repository as a resource archive.
> In general, this will allow you to bind the remote repo object to *any* JNDI tree - which would be useful if that JNDI tree is remotely accessible.
>
> In my case, it would allow me to bind the remoted interface (which is inherently serializable) to a JBoss JNP naming service (which then automatically gives you remote access since you could then use the JNP client from a remote VM to get the repo).  
>
> As it stands, it looks like you have no choice wrt where you bind the remote object - the RMI Registry (via the rmi-XXX servlet init parameters).  The rmi-XXX options trigger the servlet to end up calling "LocateRegistry.createRegistry" - this under the covers uses the SUN JNDI impl 
I suppose you mean "SUN RMI impl" and not "SUN JNDI impl", as 
RegistryImpl is part of the RMI implementation.
> "sun.rmi.registry.RegistryImpl" when running with SUN's JRE).  I don't want to use that - I want the JNP service to be my remote registry.
>
> Unless I'm missing something, which is entirely possible :-) I can't see how I can get the remote repo unless I register it in the RMI Registry.
>   
Well, IMHO the RepositoryStartupServlet serves two purposes: It shows 
how to write a servlet to start a repository and register it with JNDI 
and/or RMI registries and second it is the basis for the contributed 
WebDAV servers. Using the RepositoryStartupServlet is by no means the 
only way to start, access and deploy a repository from within a web 
application.

Rather, I would suggest to use application server resource deployment 
functionality wherever possible. This would also resolve the issue of 
cross-web application dependencies, which I consider unstable.

So, if you create your own resource deployment, you are of course free 
to deploy whatever object you like (RepositoryImpl, BindableRepository, 
ServerRepository) to whatever registry you like :-)

Hope, this sheds some lights on the issues - and I did not pack too many 
errors into the message.

Regards
Felix