Re: remove JackrabbitRepository.shutdown()
Hi,
> I have no concerns about shutdown being in an interface as such
> I just object to putting it in a client-level interface.
We should have discussed that earlier...
> For example the
> idea of a separate RepositoryManager interface that covers both
> repository startup and shutdown is IMHO much better.
OK then let's do that. Technically it's not a problem. It's not the
most simple solution, but I understand your concern.
> > > [JCRLog] It doesn't cover repository startup.
> Sorry, doesn't cover the startup in a repository-independent manner.
It does up to some point, see RepositoryFactory.open.
> Since JCRLog already has a dependency to jackrabbit-core
I hope it's just a compile time dependency. If not, it could be made
into a compile time dependency if required.
> and uses specific class references (TransientRepository) to start up a
> repository, why should it have a generic mechanism for shutting the
> repository down?
JCRLog is incomplete. Currently it's hard to use it because there are
still too many direct references to Jackrabbit classes in containers
and applications using Jackrabbit. Shutdown is one of them ;-)
> public interface RepositoryMBean {
> void startRepository() throws RepositoryException;
> void stopRepository() throws RepositoryException;
> boolean isRunning();
> Repository getRepository();
> }
That would be OK for me.
> RepositoryMBean bean = new RepositoryMBeanImpl(/* config */);
This could be written as:
RepositoryMBean bean = RepositoryMBeanFactory.create(url);
The URL could be one of:
"jackrabbit/transient"
"jackrabbit:file:~/repos/test"
"jackrabbit:jndi:jcr/globalRepository"
"jackrabbit:rmi:localhost/jackrabbit"
"jackrabbit:rmi://localhost/jackrabbit"
"jackrabbit:jcrlog:jackrabbit/file/~/repos/test"
The RepositoryMBeanFactory doesn't need to know the classes
(RepositoryMBeanImpl,...). Instead, the Java service provider
interface can be used to load the classes, and the classes would
register themselves in the RepositoryMBeanFactory.
Regards,
Thomas
Re: remove JackrabbitRepository.shutdown()
Hi,
On Mon, Apr 28, 2008 at 3:29 PM, Thomas Müller <[EMAIL PROTECTED]> wrote:
> What about the other points? I repeat them here and I hope I get an
> answer on them as well:
Your other points are good, no concerns about them.
> > But how many applications really need to shutdown the repository in
> > the generic case?
>
> All applications that call shutdown. Felix's sling/jcrapp for example.
> A backup tool. A test case.
All of your examples are implementation-specific. Is there a generic
JCR application (i.e. one with only a dependency to jcr-1.0.jar plus
potentially also jackrabbit-api), that needs
JackrabbitRepository.shutdown()?
> As you know, the TransientRepository _should_ shut down the repository
> automatically when the last session is closed.
It's a bug if it doesn't.
> However this doesn't work currently, see bug
> https://issues.apache.org/jira/browse/JCR-1551
The repository is closed at the last logout(). The shutdown delay is
caused by a static instance variable that holds a few threads for an
extended period of time after the shutdown, but that doesn't for
example prevent some other process from opening the repository.
> how come nobody found out?
Probably because most Jackrabbit apps are long-lived, and even if the
application itself is closed (for example a webapp is undeployed) the
JVM is still running so the extra thread doesn't show up.
> > You need to do that *only* if you embed the
> > repository, in which case you already are bound to a single
> > implementation.
>
> No, you are not bound to a single implementation. If you use Spring or
> Google Guice or another factory to create the repository, you are not.
Then your configuration is bound to the implementation. More notably,
in such cases it's the IoC container that should be in charge of the
repository lifecycle, and since the repository startup configuration
is Jackrabbit-specific I don't see why the shutdown part needs to be
generic.
> > IMHO, if we want to make the repository more manageable, I'd opt for a
> > JMX MBean.
>
> What's the point of adding complexity? Why exactly you like to avoid
> shutdown in an interface?
I have no concerns about shutdown being in an interface as such, I
just object to putting it in a client-level interface. For example the
idea of a separate RepositoryManager interface that covers both
repository startup and shutdown is IMHO much better.
> > [JCRLog] It doesn't cover repository startup.
>
> Of course it does. It must cover that aspect, otherwise it wouldn't be
> useful. Have a look at the JCRLog implementation and the samples.
Sorry, doesn't cover the startup in a repository-independent manner.
Since JCRLog already has a dependency to jackrabbit-core and uses
specific class references (TransientRepository) to start up a
repository, why should it have a generic mechanism for shutting the
repository down?
> I fail to see in your mail why it is better to _not_ have an
> interface. Could you please explain why you rather not have this
> interface please?
Again, no objections against an interface as such. My main point is
that such an interface shouldn't be something that you'd cast a
Repository object to.
Somewhat on the same lines as Toby, how about something like this:
public interface RepositoryMBean {
void startRepository() throws RepositoryException;
void stopRepository() throws RepositoryException;
boolean isRunning();
Repository getRepository();
}
A normal Java application can use this interface to control an
embedded repository (but note that it still needs a dependency to the
implementation class):
RepositoryMBean bean = new RepositoryMBeanImpl(/* config */);
bean.startRepository();
try {
doSomething(bean.getRepository());
} finally {
bean.stopRepository();
}
Note that there is no need to worry about access control or things
like whether a given repository instance was created by this
management object. If a client has a reference to the management
object, then it has full control over the repository. For example the
doSomething() method in the above example would have no way to
shutdown the repository, even by casting the repository instance to
whatever interface or implementation class.
And since the interface follows the JMX conventions for MBeans, it's
very easy to expose the management interface to generic JMX management
tools like jconsole, or even any SNMP-aware network and server
monitoring tools.
BR,
Jukka Zitting
Re: remove JackrabbitRepository.shutdown()
Hi, > RepositoryManagement mgmgt = new JackrabbitRepositoryMgmt(); > Repository mgmt.createRepository() > > mgmt.shutdown(Repository rep) This looks good as well, as long as RepositoryManagement is an interface. There are some advantages compared to having shutdown on the Repository: no session is required to call shutdown. What about: JackrabbitRepositoryFactory factory = new JackrabbitRepositoryFactoryImpl(); JackrabbitRepository rep = factory.createRepository(...); ... rep.shutdown(factory); or JackrabbitRepositoryFactory factory = new JackrabbitRepositoryFactoryImpl(); JackrabbitRepository rep = factory.createRepository(...); ... factory.shutdown(rep); or JackrabbitRepositoryFactory factory = new JackrabbitRepositoryFactoryImpl(); Repository rep = factory.createRepository(...); ... factory.shutdown(rep); As far as I see any of those should work for JCRLog, and be future prove. Regards, Thomas
Re: remove JackrabbitRepository.shutdown()
hi, i really think we need a management API/Class that controls creation and destruction of the repository. currently this is "hidden" in the RepositoryImpl. so other infrastructure applications (other than "TransientRepository") can make use of that. after all, it's not the job or the responsibility of a client (local or RMI) to shutdown the repo, but of the embedding container. i would see something like (better names welcome): RepositoryManagement mgmgt = new JackrabbitRepositoryMgmt(); Repository mgmt.createRepository() mgmt.shutdown(Repository rep) the important thing is, that the repo can only be shutdown by the same mgmt object that created it. this ensures that no arbitrary client can destroy the repo. WDYT? -- toby On 4/28/08, Thomas Müller <[EMAIL PROTECTED]> wrote: > Hi, > > What about the other points? I repeat them here and I hope I get an > answer on them as well: > > > - Developers can write applications against an interface. > > > - Developers can use Javadocs. Also, the autocomplete feature in the > IDE would list relevant methods. > > - Access right checking can be implemented where required, improving > security. It is no longer possible to shut down a repository without > privileges. > > > > > - It is possible to write applications that work with Jackrabbit and > > > other implementations (for example Day CRX). > > > > But how many applications really need to shutdown the repository in > > the generic case? > > > All applications that call shutdown. Felix's sling/jcrapp for example. > A backup tool. A test case. As you know, the TransientRepository > _should_ shut down the repository automatically when the last session > is closed. However this doesn't work currently, see bug > https://issues.apache.org/jira/browse/JCR-1551 - how come nobody found > out? I don't know, but one answer would be because people don't > actually use TransientRepository. What else do they use instead? Maybe > the use RepositoryImpl directly. > > > > You need to do that *only* if you embed the > > repository, in which case you already are bound to a single > > implementation. > > > No, you are not bound to a single implementation. If you use Spring or > Google Guice or another factory to create the repository, you are not. > If you use JCRLog, you can't get the RepositoryImpl object because you > get a proxy object. > > > > IMHO, if we want to make the repository more manageable, I'd opt for a > > JMX MBean. > > > What's the point of adding complexity? Why exactly you like to avoid > shutdown in an interface? > > > > > - JCRLog can work. When no interface is used, log files are incomplete > > > and re-running the log file fails. > > > > Does JCRLog need to cover the shutdown case? > > > Yes, of course it does. I have already explained why, but I can repeat > it here: When no interface is used, log files are incomplete and > re-running the log file fails. An application that uses JCRLog > wouldn't even compile if it uses RepositoryImpl.shutdown directly. > > > [JCRLog] It doesn't cover repository startup. > > Of course it does. It must cover that aspect, otherwise it wouldn't be > useful. Have a look at the JCRLog implementation and the samples. > > > > IMHO it only needs to cover the JCR API, and > > potentially the extensions in jackrabbit-api. > > > Why should there be a method that is not covered by an interface in > the Jackrabbit API? > > I fail to see in your mail why it is better to _not_ have an > interface. Could you please explain why you rather not have this > interface please? > > Regards, > > Thomas >
Re: remove JackrabbitRepository.shutdown()
Hi, What about the other points? I repeat them here and I hope I get an answer on them as well: - Developers can write applications against an interface. - Developers can use Javadocs. Also, the autocomplete feature in the IDE would list relevant methods. - Access right checking can be implemented where required, improving security. It is no longer possible to shut down a repository without privileges. > > - It is possible to write applications that work with Jackrabbit and > > other implementations (for example Day CRX). > > But how many applications really need to shutdown the repository in > the generic case? All applications that call shutdown. Felix's sling/jcrapp for example. A backup tool. A test case. As you know, the TransientRepository _should_ shut down the repository automatically when the last session is closed. However this doesn't work currently, see bug https://issues.apache.org/jira/browse/JCR-1551 - how come nobody found out? I don't know, but one answer would be because people don't actually use TransientRepository. What else do they use instead? Maybe the use RepositoryImpl directly. > You need to do that *only* if you embed the > repository, in which case you already are bound to a single > implementation. No, you are not bound to a single implementation. If you use Spring or Google Guice or another factory to create the repository, you are not. If you use JCRLog, you can't get the RepositoryImpl object because you get a proxy object. > IMHO, if we want to make the repository more manageable, I'd opt for a > JMX MBean. What's the point of adding complexity? Why exactly you like to avoid shutdown in an interface? > > - JCRLog can work. When no interface is used, log files are incomplete > > and re-running the log file fails. > > Does JCRLog need to cover the shutdown case? Yes, of course it does. I have already explained why, but I can repeat it here: When no interface is used, log files are incomplete and re-running the log file fails. An application that uses JCRLog wouldn't even compile if it uses RepositoryImpl.shutdown directly. > [JCRLog] It doesn't cover repository startup. Of course it does. It must cover that aspect, otherwise it wouldn't be useful. Have a look at the JCRLog implementation and the samples. > IMHO it only needs to cover the JCR API, and > potentially the extensions in jackrabbit-api. Why should there be a method that is not covered by an interface in the Jackrabbit API? I fail to see in your mail why it is better to _not_ have an interface. Could you please explain why you rather not have this interface please? Regards, Thomas
Re: remove JackrabbitRepository.shutdown()
Hi, On Mon, Apr 28, 2008 at 1:25 PM, Thomas Müller <[EMAIL PROTECTED]> wrote: > - It is possible to write applications that work with Jackrabbit and > other implementations (for example Day CRX). But how many applications really need to shutdown the repository in the generic case? You need to do that *only* if you embed the repository, in which case you already are bound to a single implementation. IMHO, if we want to make the repository more manageable, I'd opt for a JMX MBean. > - JCRLog can work. When no interface is used, log files are incomplete > and re-running the log file fails. Does JCRLog need to cover the shutdown case? It doesn't cover repository startup. IMHO it only needs to cover the JCR API, and potentially the extensions in jackrabbit-api. BR, Jukka Zitting
Re: remove JackrabbitRepository.shutdown()
Hi,
before I get into some conceptual thoughs, I think the main question
regarding shutdown() is:
Do people need to be able to call shutdown() remotely?
I consider the interface "Repository" as part of the JCR client API.
The actually started JCR-server is IMHO a different entity, which is
currently somewhat represented by TransientRepository - but it has the
problem of implementing the Repository interface as well, which makes
things very confusing.
== Server
Things get clearer when we look at a remoting situation: here someone
starts the Jackrabbit/JCR server on one server. I will call this the
"server" entity for now, which is not standardized or even mentioned
in the JSR specs (1.0 and 2.0). This is the entity which is started
and stopped (shutdown) and probably managed in other ways as well. I
don't know if this should be standardized, but it would look good if
the code in the end (even if it is Jackrabbit-specific) would look
like this:
RepositoryServer server = new RepositoryServer("jndi://localhost/
jackrabbit"); // register on JNDI
RepositoryServer server = new RepositoryServer("http://localhost:1234
"); // start webdav server on port 1234
...
server.shutdown();
The shutdown method would be completely natural here. And note that
the RepositoryServer is only needed for server-startup code; the
embedded variant can be handled simpler (see below).
== Client
Then we have on a different machine a JCR client that connects to this
server. Here we have the normal JCR API, which always implements the
*client-side view* on a repository - a good example is "Workspace",
which is session-bound and does not represent the persisted Workspace
entity on the server, but rather what that specific client "sees".
Therefor we should not mix the interface "Repository" with the server.
A better naming in this regard would probably be
"RepositoryConnection", but as this is part of the standard we can't
change it anyway ;-)
Now to the solutions: I personally like the RepositoryFactory (or
ClientRepositoryFactory) proposal: it is a generic way to get client-
Repository instances. In the case of an embedded Repositories the
server entity gets completely hidden by the respective implementation
of the RepositoryFactory for the embedded case.
To allow shutdown(), I think it would be better to put this method
into the factory than in some client interface:
RepositoryFactory.shutdownEmbedded(Repository repo)
In all other cases, in which we start a server (eg. RMI), we can
easily shut it down on the server side (eg.
RepositoryServer.shutdown()); on the client side it depends on my
original question: if we want a remote shutdown, we need some general
interface like JackrabbitManagedRepository for the client. Otherwise
we can remove that interface completely.
Alex
PS: createWorkspace, node type registration etc. are on a different
layer than start/shutdown, so they should be part of the Workspace or
Session interface (including authorization) - which is already the case.
--
Alexander Klimetschek
[EMAIL PROTECTED]
>> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<
Re: remove JackrabbitRepository.shutdown()
Hi,
> But we're diverging from the shutdown() issue.
Yes. I propose create a new public interface
JackrabbitManagedRepository extends Repository {
void shutdown(JackrabbitSession session);
}
This would have the following advantages:
- Developers can write applications against an interface. Programming
against interfaces is a common best practice. It helps achieve
information hiding, encapsulation, and decouples the application that
is using the module from the module itself. See also the book
"Effective Java", item 16 "Prefer interfaces to abstract classes",
item 34 "Refer to objects by their interfaces", and items 12, 15, and
28. See also design pattern "Abstract factory", "Factory method", and
"Builder".
- Developers can use Javadocs. Also, the autocomplete feature in the
IDE would list relevant methods.
- Access right checking can be implemented where required, improving
security. It is no longer possible to shut down a repository without
privileges.
- It is possible to write applications that work with Jackrabbit and
other implementations (for example Day CRX). Applications don't need
to cast to RepositoryImpl, making them only work for Jackrabbit.
- JCRLog can work. When no interface is used, log files are incomplete
and re-running the log file fails.
RepositoryImpl should implement the new JackrabbitManagedRepository
interface. For security reasons, the current JackrabbitRepository
interface should be deprecated and the current shutdown method should
throw an exception. TransientRepository should be kept.
Regards,
Thomas
Re: remove JackrabbitRepository.shutdown()
Hi,
On Mon, Apr 21, 2008 at 12:04 PM, Thomas Mueller
<[EMAIL PROTECTED]> wrote:
> When using the 'service provider' appraoch, interfaces are used. It is
> not required to hardcode any implementation classes.
Agreed. This is being introduced in JSR 283.
But we're diverging from the shutdown() issue. The factory pattern
only covers creation, not the whole lifecycle. Personally I'd
recommend that embedded clients use TransientRepository (through the
JSR 283 factory pattern), but if there's need we can certainly also
add something like the login("SHUTDOWN") trick.
BR,
Jukka Zitting
Re: remove JackrabbitRepository.shutdown()
Hi, FYI, there is an article about the "Factory Method" design pattern at http://java.dzone.com/news/gof-design-patterns-factory-me "The Factory Method returns an instance of a class (ConcreteProduct) that is defined through an interface or abstract parent (Product) class." In our case an interface is cleaner, but abstract parent is an option as well (calling methods of abstract classes is slightly faster than methods of interfaces, but really only slightly). Regards, Thomas On Mon, Apr 21, 2008 at 11:04 AM, Thomas Mueller <[EMAIL PROTECTED]> wrote: > Hi, > > > > there is no technical reason why remoting couldn't be reasonably > > fast > > I agree. Because there is an overhead for each TCP/IP roundtrip, > remote access can never be as fast as when running Jackrabbit in the > same virtual machine, except if requests are very coarse grained. > > > > That's IMHO a minor nit. You can avoid that with: > > JackrabbitRepository repository = RepositoryImpl.create(...); > > The recommended factory method should be declared to return > JackrabbitRepository (or maybe a new interface). However I'm not sure > if the recommended factory method should be RepositoryImpl.create. > It's inconsistent to get a remote repository object using "new > ClientRepositoryFactory().getRepository(String)" but a embedded > repository using "RepositoryImpl.create(RepositoryConfig)". It would > be better to have only one factory for Jackrabbit, and only one way to > get a repository object, for example: > > JackrabbitRepositoryFactory.open(String url) > > This 'service provider' approach is used by the following APIs: > - JDBC (java.sql.DriverManager.getConnection) > - Security (for example java.security.MessageDigest.getInstance) > - Cryptography (javax.crypto.Cipher.getInstance) > - XML > - Sound (for example javax.sound.sampled.AudioSystem.getAudioInputStream) > - Java Naming Services (javax.naming.spi.NamingManager. getInitialContext) > - Java Image I/O (for example javax.imageio.ImageIO.read) > - New IO (java.nio.channels, java.nio.charset) > - Input Methods (java.awt.im) > - ... and various other places > > When using the 'service provider' appraoch, interfaces are used. It is > not required to hardcode any implementation classes. > > > an application that embeds RepositoryImpl ... needs to call shutdown() ... > > > Is it a big problem that when making this call you > > see extra stuff in IDE autocomplete and the javadocs? > > You see those 'forbidden but public' methods whenever you call > anything on RepositoryImpl. Developers shouldn't see any method that > they must not call. It's just one of many problems you get when you > force developers to use RepositoryImpl directly. It's a potential > problem an can be easily avoided by using an interface. > > Regards, > Thomas >
Re: remove JackrabbitRepository.shutdown()
Hi, > there is no technical reason why remoting couldn't be reasonably > fast I agree. Because there is an overhead for each TCP/IP roundtrip, remote access can never be as fast as when running Jackrabbit in the same virtual machine, except if requests are very coarse grained. > That's IMHO a minor nit. You can avoid that with: > JackrabbitRepository repository = RepositoryImpl.create(...); The recommended factory method should be declared to return JackrabbitRepository (or maybe a new interface). However I'm not sure if the recommended factory method should be RepositoryImpl.create. It's inconsistent to get a remote repository object using "new ClientRepositoryFactory().getRepository(String)" but a embedded repository using "RepositoryImpl.create(RepositoryConfig)". It would be better to have only one factory for Jackrabbit, and only one way to get a repository object, for example: JackrabbitRepositoryFactory.open(String url) This 'service provider' approach is used by the following APIs: - JDBC (java.sql.DriverManager.getConnection) - Security (for example java.security.MessageDigest.getInstance) - Cryptography (javax.crypto.Cipher.getInstance) - XML - Sound (for example javax.sound.sampled.AudioSystem.getAudioInputStream) - Java Naming Services (javax.naming.spi.NamingManager. getInitialContext) - Java Image I/O (for example javax.imageio.ImageIO.read) - New IO (java.nio.channels, java.nio.charset) - Input Methods (java.awt.im) - ... and various other places When using the 'service provider' appraoch, interfaces are used. It is not required to hardcode any implementation classes. > an application that embeds RepositoryImpl ... needs to call shutdown() ... > Is it a big problem that when making this call you > see extra stuff in IDE autocomplete and the javadocs? You see those 'forbidden but public' methods whenever you call anything on RepositoryImpl. Developers shouldn't see any method that they must not call. It's just one of many problems you get when you force developers to use RepositoryImpl directly. It's a potential problem an can be easily avoided by using an interface. Regards, Thomas
Re: remove JackrabbitRepository.shutdown()
Hi,
On Thu, Apr 17, 2008 at 10:58 AM, Thomas Mueller
<[EMAIL PROTECTED]> wrote:
> > IMHO we should be targeting server
> > deployments as the default model
>
> What exactly do you mean with "server deployment"?
Model 2 or model 3. Basically any deployment where the client is not
in control of the repository lifecycle.
> The main problem for me is the poor performance when Jackrabbit
> is accessed remotely (over RMI). Do we have a plan to solve this?
Model 2 deployments don't have that issue.
Also, there is no technical reason why remoting couldn't be reasonably
fast, it's just that so far we haven't really focused on that. I think
that's something we need to fix, and putting more emphasis on model 3
deployments will naturally highlight the issue and hopefully attract
related contributions.
> > > remote repositories (can it?)
>
> > Repository repository = new TransientRepository();
> > RemoteAdapterFactory factory = new ServerAdapterFactory();
> > RemoteRepository remote = factory.getRemoteRepository(repository);
> > Naming.bind("//localhost/jackrabbit", remote);
>
> That's even more implementation specific code to write. It should be as easy
> as:
> [...]
> Repository rep = RepositoryFactory.open(url);
>
> Like that the application does not need to be re-compiled when using
> another connection mode or repository implementation.
Ah, I thought you were asking for a way to expose an embedded
TransientRepository through RMI. There's no need for
TransientRepository or anything from jackrabbit-core when you just
need to access a remote repository:
ClientRepositoryFactory factory = new ClientRepositoryFactory();
Repository repository = factory.getRepository("//localhost/jackrabbit");
It'll also be no problem to implement JSR 283 repository acquisition
support for RMI.
> > > - The repository is closed (shut down) if the first login fails,
> > > unlike other repositories
> >
> > Is that a problem? If there's no session open, does the repository be up?
>
> It's a usability issue. If the first login fails the application has
> to re-create the TransientRepository object before it can be used
> again.
Oh, that's certainly a bug then. A failed initial login will shutdown
the underlying repository, but the next login attempt should just
restart it under the hood. There should be no need to reconstruct the
TransientRepository instance.
> > > - It doesn't solve the Javadoc problem (the class has public methods
> > > that should not be called)
> >
> > Why is this a problem? We can improve the documentation if needed.
>
> I use autocomplete in the IDE or the Javadoc HTML documentation
> instead of or in addition to reading the documentation. When a
> developer is forced to use RepositoryImpl (in order to call shutdown)
> as in
>
> RepositoryImpl repo = ...
>
> and then he types:
>
> repo.
>
> He will get the list of public methods. This list includes methods he
> shouldn't call - shouldn't ever call - for example:
> getItemStateCacheFactory, loggedOut, loggingOut, onEvent. The same
> when he reads the Javadoc HTML documentation.
>
> The factory method (currently RepositoryImpl.create) shouldn't be
> declared to return RepositoryImpl. It should return
> JackrabbitRepository. That way, a developer will only see the methods
> he is allowed to call.
That's IMHO a minor nit. You can avoid that with:
JackrabbitRepository repository = RepositoryImpl.create(...);
Also, an application that embeds RepositoryImpl, only needs to call
shutdown() once. Is it a big problem that when making this call you
see extra stuff in IDE autocomplete and the javadocs? We can certainly
change that if you think it's a problem.
BR,
Jukka Zitting
Re: remove JackrabbitRepository.shutdown()
Hi,
> > For Jukka the embedded use case (Model 1) is completely unimportant.
> :-) Don't put words into my mouth.
I'm sorry, I was mislead by your statement "Jackrabbit is a server not
a library".
> IMHO we should be targeting server
> deployments as the default model
What exactly do you mean with "server deployment"? The main problem
for me is the poor performance when Jackrabbit is accessed remotely
(over RMI). Do we have a plan to solve this?
> > remote repositories (can it?)
> Repository repository = new TransientRepository();
> RemoteAdapterFactory factory = new ServerAdapterFactory();
> RemoteRepository remote = factory.getRemoteRepository(repository);
> Naming.bind("//localhost/jackrabbit", remote);
That's even more implementation specific code to write. It should be as easy as:
Repository rep = RepositoryFactory.open("jackrabbit/transient");
or
Repository rep = RepositoryFactory.open("jackrabbit:file:~/repos/test");
or
Repository rep = RepositoryFactory.open("jackrabbit:jndi:jcr/globalRepository");
or
Repository rep = RepositoryFactory.open("jackrabbit:rmi:localhost/jackrabbit");
or
Repository rep =
RepositoryFactory.open("jackrabbit:rmi://localhost/jackrabbit");
or
Repository rep =
RepositoryFactory.open("jackrabbit:jcrlog:jackrabbit/file/~/repos/test");
or more general:
Repository rep = RepositoryFactory.open(url);
Like that the application does not need to be re-compiled when using
another connection mode or repository implementation.
> > - The repository is closed (shut down) if the first login fails,
> > unlike other repositories
>
> Is that a problem? If there's no session open, does the repository be up?
It's a usability issue. If the first login fails the application has
to re-create the TransientRepository object before it can be used
again. But only when using TransientRepository, and only if the first
login fails. If the second login fails, or when not using
TransientRepository, the application must not re-create the repository
object. For a developer that's strange: it shouldn't matter what login
attempt this is and it shouldn't matter what kind of repository object
this is.
> > - It doesn't solve the Javadoc problem (the class has public methods
> > that should not be called)
>
> Why is this a problem? We can improve the documentation if needed.
I use autocomplete in the IDE or the Javadoc HTML documentation
instead of or in addition to reading the documentation. When a
developer is forced to use RepositoryImpl (in order to call shutdown)
as in
RepositoryImpl repo = ...
and then he types:
repo.
He will get the list of public methods. This list includes methods he
shouldn't call - shouldn't ever call - for example:
getItemStateCacheFactory, loggedOut, loggingOut, onEvent. The same
when he reads the Javadoc HTML documentation.
The factory method (currently RepositoryImpl.create) shouldn't be
declared to return RepositoryImpl. It should return
JackrabbitRepository. That way, a developer will only see the methods
he is allowed to call.
Regards,
Thomas
Re: remove JackrabbitRepository.shutdown()
Hi,
On Wed, Apr 16, 2008 at 4:21 PM, Thomas Mueller
<[EMAIL PROTECTED]> wrote:
> I think we agree that we disagree.
I think there's certainly a road to consensus here, so let's keep going.
> For Jukka Jackrabbit is a server, and the embedded use case (Model 1)
> use case is completely unimportant.
:-) Don't put words into my mouth. IMHO we should be targeting server
deployments as the default model for Jackrabbit (all the easy
deployment, nice browser interface, etc. stuff planned for 1.5 is
explicitly related to server deployments), but there's no reason why
we can't keep the embedded deployment case around as well.
> > Why not use TransientRepository?
>
> That's probably the best solution so far. I'm not sure if that works
> however. Some problems (which may be solvable):
> - It cannot be used for remote repositories (can it?)
Sure it can:
Repository repository = new TransientRepository();
RemoteAdapterFactory factory = new ServerAdapterFactory();
RemoteRepository remote = factory.getRemoteRepository(repository);
Naming.bind("//localhost/jackrabbit", remote);
> - The repository is closed (shut down) if the first login fails,
> unlike other repositories
Is that a problem? If there's no session open, does the repository be up?
> - It doesn't solve the Javadoc problem (the class has public methods
> that should not be called)
Why is this a problem? We can improve the documentation if needed.
> - It's still a class not an interface
JSR 283 is specifying an implementation-independent mechanism for
constructing a Repository instance. We can implement that for
TransientRepository to have an implementation-independent way of
starting (and stopping) a Jackrabbit repository.
> - No way to force shutdown (unlike with
> JackrabbitSession.shutdown(Session adminSession))
Just close all open sessions.
BR,
Jukka Zitting
Re: remove JackrabbitRepository.shutdown()
Hi, Am Mittwoch, den 16.04.2008, 15:21 +0200 schrieb Thomas Mueller: > Hi, > > I think we agree that we disagree. Very true ! The problem is that many people have use cases which are deemed by other people as invalid or at least as not important ... This is not the way to go ! > > sling/jcrapp > > This sounds like the 'server' model. Not really, it is really model 4: It may be used as a server and - by deploying OSGi bundles into the same OSGi framework instance - it can be used as an embedded repository. > My concern is that is internally > uses Jackrabbit specific classes directly. Yes, internally and in one single location: The same class which creates the Repository instance also shuts it down. IMHO it is valid to use internal methods in this way. And yes, I would rather cast the Repository to some interface - e.g. JackrabbitRepository - than to the implementation class. > P.S. Maybe you want to > tweak the name a bit... Somehow it reminds me of Crap4J > (http://www.crap4j.org/). Sorry, just joking. Hehe, if you get me better short name, your are my friend ;-) Regards Felix
Re: remove JackrabbitRepository.shutdown()
Hi, I think we agree that we disagree. For Jukka Jackrabbit is a server, and the embedded use case (Model 1) use case is completely unimportant. For me and Alexander, the embedded use case (Model 1) is important. Not only because of performance, also because of ease-of-use. > Model 2 and 3 clients should not be able shutdown the repository, > as the repository lifecycle is managed by the server. Removing shutdown from the API will not solve this problem as everybody can still call the method. A possible solution is that only the very first session may call shutdown. Let's say there is JackrabbitRepository.shutdown(Session adminSession). When the repository is created the server (the entity that manages the repository) opens a special 'admin session' and keeps it. An application does not have access to it, only the server. If an application calls shutdown with another session (or null) an exception is thrown. The server can still force a shutdown if required. That's just an idea and can still be improved. > As a new Jackrabbit user these complicated ways to create and shutdown > a repository are really annonying, because this is always the *first code* > you will have to write to get it running in your application! So there should > be lots of effort to make it as simple as possible! I fully agree. I don't see how making things harder helps. > And since all model 1 applications in any case have a direct > Jackrabbit dependency, I don't see why we couldn't expect > them to use the direct RepositoryImpl.shutdown() method. Because RepositoryImpl is a class and not an interface. A) C) D) and E). Again A-E for reference: A) programming against interfaces B) The "security" argument is invalid C) How about Javadocs? D) How about other implementations (RMI, CRX)? E) JCRLog is impossible. > Why not use TransientRepository? That's probably the best solution so far. I'm not sure if that works however. Some problems (which may be solvable): - It cannot be used for remote repositories (can it?) - The repository is closed (shut down) if the first login fails, unlike other repositories - It doesn't solve the Javadoc problem (the class has public methods that should not be called) - It's still a class not an interface - No way to force shutdown (unlike with JackrabbitSession.shutdown(Session adminSession)) > why would JCRLog need to cover shutdown? You can't use JCRLog because ((RepositoryImpl)rep).shutdown() throws a ClassCastException. Even if you could solve this somehow, another problem remains. The JCRLog should log all method calls that affect Jackrabbit. By re-playing the log file a repository should be in the same state as before. If shutdown is not logged, you can't do that. Example: an application could call shutdown too early or not at all. Replaying the log file would result in another state, and you wouldn't see the problem. The log file may contain multiple runs of an application (multiple open-close / start-stop). > It's probably more fruitful to debate that goal, as the way we expose > the shutdown mechanism is highly dependent on the expected deployment > model. In my view Model 1 usage is important. Ease-of-use is important (sample apps, Javadoc, wiki,...), and there are technical reasons why shutdown should be part of an interface. For me, Model 2 and 3 are variations of Model 1. In Model 1, the client application starts and stops the repository, while in Model 2 and 3 the 'server' starts and stops it. There is even a Model 4: Mixed Mode. In that case, the application starts the repository and uses it in embedded mode, plus it starts a server so that other processes can connect to it remotely. The main advantages of Model 4 are: high performance for the embedded sessions, while providing remote access. This model is what Alexander is proposing in "simple Repository start interface". > sling/jcrapp This sounds like the 'server' model. My concern is that is internally uses Jackrabbit specific classes directly. P.S. Maybe you want to tweak the name a bit... Somehow it reminds me of Crap4J (http://www.crap4j.org/). Sorry, just joking. Regards, Thomas
Re: remove JackrabbitRepository.shutdown()
Hi, Am Mittwoch, den 16.04.2008, 13:24 +0200 schrieb Alexander Klimetschek: > Am 16.04.2008 um 13:11 schrieb Jukka Zitting: > > This seems to be the cause of differing opinions here. > > Yes ;-) > > > IMHO we should > > be pushing the Jackrabbit content repository more towards being > > "server infrastructure" than a "client library". See also the last > > section in http://markmail.org/message/p6nn4nfywa6xcn3z. > > From the perspective of a passionate Jackrabbit user: please do both! > Embedded is so important in the Java world, and it's a big advantage, > cause it reliefs you from the complexity of installing, configuring > and starting an external application. > > The best solution IMHO would be: > > 1) have a simple Repository start interface, including registering the > object on JNDI, starting the RMI server etc. Let me do some selling ;-) You might want to have a look at the sling/jcrapp module. This creates a single jar file which just launches the JCR repository and registers with RMI (and JNDI) out of the box. Give it a try ;-) You may add start/stop script support easily. And you may even continue - assuming you are willing to build OSGi bundles, which is great BTW - to use this same repository embedded by deploying bundles there .. Everything you ever wanted and more... > 2) have a simple "give me the Repository interface" for the JCR client > (that's what JSR-283 specifies right?) > 3) have a proper shutdown() which requires admin rights (via Session > as already proposed, not just by doing an "((RepositoryImpl) > session.getRepository()).shutdown()) > 4) provide command line tools for start and stop, that are built on > top of 1 and 3 (and other adminstration tasks, but that's for the > future) > > Alex > > -- > Alexander Klimetschek > [EMAIL PROTECTED] > > >> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ << > > > >
Re: remove JackrabbitRepository.shutdown()
Hi, On Wed, Apr 16, 2008 at 2:24 PM, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: > From the perspective of a passionate Jackrabbit user: please do both! > Embedded is so important in the Java world, and it's a big advantage, cause > it reliefs you from the complexity of installing, configuring and starting > an external application. OK. Responding below for the embedded case: > The best solution IMHO would be: > > 1) have a simple Repository start interface, including registering the > object on JNDI, starting the RMI server etc. I don't think that stuff is needed in an embedded repository. > 2) have a simple "give me the Repository interface" for the JCR client > (that's what JSR-283 specifies right?) Yes. > 3) have a proper shutdown() which requires admin rights (via Session as > already proposed, not just by doing an "((RepositoryImpl) > session.getRepository()).shutdown()) Why not use TransientRepository? > 4) provide command line tools for start and stop, that are built on top of > 1 and 3 (and other adminstration tasks, but that's for the future) Again, not needed in the embedded case. BR, Jukka Zitting
Re: remove JackrabbitRepository.shutdown()
Am 16.04.2008 um 13:11 schrieb Jukka Zitting: This seems to be the cause of differing opinions here. Yes ;-) IMHO we should be pushing the Jackrabbit content repository more towards being "server infrastructure" than a "client library". See also the last section in http://markmail.org/message/p6nn4nfywa6xcn3z. From the perspective of a passionate Jackrabbit user: please do both! Embedded is so important in the Java world, and it's a big advantage, cause it reliefs you from the complexity of installing, configuring and starting an external application. The best solution IMHO would be: 1) have a simple Repository start interface, including registering the object on JNDI, starting the RMI server etc. 2) have a simple "give me the Repository interface" for the JCR client (that's what JSR-283 specifies right?) 3) have a proper shutdown() which requires admin rights (via Session as already proposed, not just by doing an "((RepositoryImpl) session.getRepository()).shutdown()) 4) provide command line tools for start and stop, that are built on top of 1 and 3 (and other adminstration tasks, but that's for the future) Alex -- Alexander Klimetschek [EMAIL PROTECTED] >> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<
Re: remove JackrabbitRepository.shutdown()
Hi, On Wed, Apr 16, 2008 at 2:01 PM, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: > It really makes sense, because Jackrabbit can be used embedded. Oracle is a > massive standalone server, which makes the comparison flawed. Using > Jackrabbit embedded is probably the main use case, definitely for small > desktop applications, but also for most web applications. This seems to be the cause of differing opinions here. IMHO we should be pushing the Jackrabbit content repository more towards being "server infrastructure" than a "client library". See also the last section in http://markmail.org/message/p6nn4nfywa6xcn3z. It's probably more fruitful to debate that goal, as the way we expose the shutdown mechanism is highly dependent on the expected deployment model. BR, Jukka Zitting
Re: remove JackrabbitRepository.shutdown()
Hi, On Wed, Apr 16, 2008 at 11:24 AM, Thomas Mueller <[EMAIL PROTECTED]> wrote: > A) I think that when using libraries, programming against interfaces > is better than programming against fixed implementation classes. Sure, but Jackrabbit is a server not a library. Sure, you can use Jackrabbit as an embedded repository like you'd use Derby or hsqldb as an embedded database, but the standard deployment is already jackrabbit-webapp and IMHO our goal for Jackrabbit should be to make it even more like a standalone server like PostgreSQL, MySQL, or Oracle in the database world. > B) The "security" argument is invalid. Isn't it strange to remove the > interface JackrabbitRepository because "shutdown" is "not save", but a > Model 1 application has to call "shutdown" to close the repository? Model 2 and 3 clients should not be able shutdown the repository, as the repository lifecycle is managed by the server. And since all model 1 applications in any case have a direct Jackrabbit dependency, I don't see why we couldn't expect them to use the direct RepositoryImpl.shutdown() method. > D) How about other implementations (RMI, CRX)? If there is no > interface, things will get complicated. If there is no interface, an > application needs to have three ways to shutdown a repository. > Wouldn't it be cool to only have one way? RMI clients should never shutdown the repository. CRX has it's own repository lifecycle. > E) And again, JCRLog is impossible. Why is that? A client should never call shutdown in the first place, so why would JCRLog need to cover that? BR, Jukka Zitting
Re: remove JackrabbitRepository.shutdown()
Am 16.04.2008 um 07:08 schrieb Jukka Zitting:
If you really needed that, you could always implement
repository.login("SHUTDOWN")... But just like you can't do that to an
Oracle database, I don't think it makes that much sense for
Jackrabbit.
It really makes sense, because Jackrabbit can be used embedded. Oracle
is a massive standalone server, which makes the comparison flawed.
Using Jackrabbit embedded is probably the main use case, definitely
for small desktop applications, but also for most web applications. At
my former company Mindquarry we tried to scale on Amazon EC2 and were
still using Jackrabbit embedded on the application servers, because it
was just the simplest way to do it.
And even if you use Jackrabbit standalone, could you point me to the
standardized and simple command line tools for starting a Jackrabbit
server? These are available for Oracle and co, but not for Jackrabbit.
That's why everyone needs to write his own code calling shutdown().
As a new Jackrabbit user these complicated ways to create and shutdown
a repository are really annonying, because this is always the *first
code* you will have to write to get it running in your application! So
there should be lots of effort to make it as simple as possible! An
Open Source project is the best place to improve on those things,
where the spec isn't perfect (yet).
Regards,
Alex
--
Alexander Klimetschek
[EMAIL PROTECTED]
>> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<
Re: remove JackrabbitRepository.shutdown()
Am 16.04.2008 um 10:24 schrieb Thomas Mueller: I have never used Spring or Guice, do you know if they support "customizable shutdown mechanisms"? Spring has the concept of a destroy-method that should get called, when the spring application context is closed. But generally these frameworks (or Spring in particular) very much concentrate on the wiring-together part. Alex -- Alexander Klimetschek [EMAIL PROTECTED] >> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<
Re: remove JackrabbitRepository.shutdown()
Hi, A) I think that when using libraries, programming against interfaces is better than programming against fixed implementation classes. B) The "security" argument is invalid. Isn't it strange to remove the interface JackrabbitRepository because "shutdown" is "not save", but a Model 1 application has to call "shutdown" to close the repository? How is it "saver" to call a method in a class versus calling a method in an interface? A good way to make it safer is by changing shutdown to shutdown(Session), by adding shutdownRepository to JackrabbitSession, or by adding a new JackrabbitRepositoryManagement interface. But not by removing the interface. C) How about Javadocs? The JackrabbitRepository interface is removed, but applications must call shutdown() in Model 1. Shutdown must be called but is not in the Javadocs? Or in the RepositoryImpl Javadocs mixed with the other public methods (loggedOut, onEvent,...) that the user shouldn't call? D) How about other implementations (RMI, CRX)? If there is no interface, things will get complicated. If there is no interface, an application needs to have three ways to shutdown a repository. Wouldn't it be cool to only have one way? E) And again, JCRLog is impossible. > In model 1 you're embedding the repository and thus you'd have a > direct dependency to jackrabbit-core and use RepositoryImpl.create() > to start the repository up. Yes, that's already bad enough. In JSR 283 repository construction will hopefully be standardized. But there are solutions even without JCR 283, for example using using Spring or Google Guice. From the Google Guice home page: "Guice alleviates the need for factories and the use of new in your Java code... You will still need to write factories in some cases, but your code will not depend directly on them. Your code will be easier to change...". Those tools are made for exactly this use case. Specially for components that don't have a standard way to create objects (unlike JDBC, and components that have a service provider interface). I have never used Spring or Guice, do you know if they support "customizable shutdown mechanisms"? > Using RepositoryImpl.shutdown() to shut it > down doesn't make things any more complicated. Sorry, I don't follow this logic. Because there is a problem at one place, we don't need to care in another place? Regards, Thomas
Re: remove JackrabbitRepository.shutdown()
On Tue, Apr 15, 2008 at 6:14 PM, Thomas Mueller
<[EMAIL PROTECTED]> wrote:
> > how would you do it with a relational database using JDBC?
>
> Connection conn = DriverManager.getConnection(...);
> if (url.startsWith("jdbc:hsqldb:")) {
> conn.createStatement().execute("SHUTDOWN");
> }
> conn.close();
> ... backup ...
> Connection conn = DriverManager.getConnection(...);
> ...
>
> There is no vendor specific import. The 'SHUTDOWN' statement is vendor
> specific, but uses the standard JDBC API. Using a JDBC wrapper is not
> a problem.
If you really needed that, you could always implement
repository.login("SHUTDOWN")... But just like you can't do that to an
Oracle database, I don't think it makes that much sense for
Jackrabbit.
> > I don't think the above use case is something that really needs to be
> > vendor-independent, i.e. how often a generic application needs to do
> > that?
>
> Do you mean how often does an application need to backup data? It
> depends on the use case.
Much more specifically: needs to shutdown a repository to backup the
underlying storage. If you need to do that, you're in any case tied to
implementation-specific functionality as already the "backup
underlying storage" requires implementation-specific knowledge. So
IMHO there's not much benefit for the "shutdown the repository" part
to be independent of the underlying implementation.
> Another use case:
> http://jackrabbit.apache.org/deployment-models.html
> Model 1: The (Web-) Application Bundle
> "The individual repository instances are started and stopped with
> their containing applications"
> How should a standalone application close a repository before the
> application ends, without importing Jackrabbit specific classes?
> Hopefully this is defined in JCR 2.0.
In model 1 you're embedding the repository and thus you'd have a
direct dependency to jackrabbit-core and use RepositoryImpl.create()
to start the repository up. Using RepositoryImpl.shutdown() to shut it
down doesn't make things any more complicated.
BR,
Jukka Zitting
Re: remove JackrabbitRepository.shutdown()
Hi,
> how would you do it with a relational database using JDBC?
Connection conn = DriverManager.getConnection(...);
if (url.startsWith("jdbc:hsqldb:")) {
conn.createStatement().execute("SHUTDOWN");
}
conn.close();
... backup ...
Connection conn = DriverManager.getConnection(...);
...
There is no vendor specific import. The 'SHUTDOWN' statement is vendor
specific, but uses the standard JDBC API. Using a JDBC wrapper is not
a problem.
> I don't think the above use case is something that really needs to be
> vendor-independent, i.e. how often a generic application needs to do
> that?
Do you mean how often does an application need to backup data? It
depends on the use case.
Another use case:
http://jackrabbit.apache.org/deployment-models.html
Model 1: The (Web-) Application Bundle
"The individual repository instances are started and stopped with
their containing applications"
How should a standalone application close a repository before the
application ends, without importing Jackrabbit specific classes?
Hopefully this is defined in JCR 2.0.
Of course you could say "use TransientRepository". But that would mean
all repository implementations need to work like TransientRepository.
Maybe that would be an option?
> That's about constructing the Repository object, not about starting up
> the underlying repository.
So, you mean constructing the Repository object is using the JCR 2.0
API, but the repository needs to be 'started' in another way?
((RepositoryImpl) rep).startup(); ? That would be strange.
Regards,
Thomas
Re: remove JackrabbitRepository.shutdown()
Hi, On Tue, Apr 15, 2008 at 4:47 PM, Thomas Mueller <[EMAIL PROTECTED]> wrote: > How would you write an application that does the following: > > 1) open a repository, write some data to it > 2) close the repository > 3) backup the files that make up the repository > 4) re-open the repository > 5) close the repository > > The implementation should be as vendor independent as possible. And > how would you instrument the code to use the JCRLog wrapper? Turning that around, how would you do it with a relational database using JDBC? I don't think the above use case is something that really needs to be vendor-independent, i.e. how often a generic application needs to do that? BR, Jukka Zitting
Re: remove JackrabbitRepository.shutdown()
Hi, How would you write an application that does the following: 1) open a repository, write some data to it 2) close the repository 3) backup the files that make up the repository 4) re-open the repository 5) close the repository The implementation should be as vendor independent as possible. And how would you instrument the code to use the JCRLog wrapper? Regards, Thomas On Tue, Apr 15, 2008 at 3:40 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote: > Hi, > > > On Tue, Apr 15, 2008 at 4:24 PM, Thomas Mueller > <[EMAIL PROTECTED]> wrote: > > Do you mean "repository creation and deletion" or "repository object > > creation and closing"? JSR 283, version 2.0, public review 2 July > > 2007, page 49 talks about "Repository Construction". > > That's about constructing the Repository object, not about starting up > the underlying repository. > > > > When the application has to link to a specific class it is not > > possible to create wrappers (for example JCRLog). When the application > > links to an interface this is not an issue. > > You can certainly wrap things around the existing Repository > interface. I don't see how the lack of a shutdown method is a problem > here. Note that shutting down the repository should be the > responsibility of whoever started the repository in the first place, > and they will always have an unwrapped reference to the underlying > repository implementation. > > > > There is no 'Database' interface in the JDBC API, and applications > > don't need it. When using the JCR API, you first have to have to > > construct a Repository object to get a Session. > > The Repository interface in JCR is roughly equivalent to DataSource in JDBC. > > BR, > > Jukka Zitting >
Re: remove JackrabbitRepository.shutdown()
Hi, On Tue, Apr 15, 2008 at 4:24 PM, Thomas Mueller <[EMAIL PROTECTED]> wrote: > Do you mean "repository creation and deletion" or "repository object > creation and closing"? JSR 283, version 2.0, public review 2 July > 2007, page 49 talks about "Repository Construction". That's about constructing the Repository object, not about starting up the underlying repository. > When the application has to link to a specific class it is not > possible to create wrappers (for example JCRLog). When the application > links to an interface this is not an issue. You can certainly wrap things around the existing Repository interface. I don't see how the lack of a shutdown method is a problem here. Note that shutting down the repository should be the responsibility of whoever started the repository in the first place, and they will always have an unwrapped reference to the underlying repository implementation. > There is no 'Database' interface in the JDBC API, and applications > don't need it. When using the JCR API, you first have to have to > construct a Repository object to get a Session. The Repository interface in JCR is roughly equivalent to DataSource in JDBC. BR, Jukka Zitting
Re: remove JackrabbitRepository.shutdown()
Hi, > > - Applications must hardcode a specific class, > > org.apache.jackrabbit.core.RepositoryImpl > you have to hard code that in any case, because otherwise you cannot start > the repository. > Repository construction and destruction is not specified in JSR 170 nor in > JSR 283. Do you mean "repository creation and deletion" or "repository object creation and closing"? JSR 283, version 2.0, public review 2 July 2007, page 49 talks about "Repository Construction". > why is that an issue? When the application has to link to a specific class it is not possible to create wrappers (for example JCRLog). When the application links to an interface this is not an issue. >> JDBC > but this is about getting a connection and closing it again, which is > equivalent to obtaining a JCR session and logging out when your done. that's > already standardized in JSR 170. There is no 'Database' interface in the JDBC API, and applications don't need it. When using the JCR API, you first have to have to construct a Repository object to get a Session. Yes, closing a database is vendor specific. However it is still possible without having to cast to a specific interface or class, that means it is still possible to write a wrapper around the JDBC API. To close a database in HSQLDB and H2, you execute the SQL statement "SHUTDOWN". Apache Derby is a bit more complicated: you have to open connection with a special URL. But in all cases, you don't need to import any vendor specific interface or class. Regards, Thomas
Re: remove JackrabbitRepository.shutdown()
Hi, On Mon, Apr 14, 2008 at 8:16 PM, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > i want to remove the shutdown method from the JackrabbitRepository > interface. the reason is that there should at least be some > authorization. so rather move that to workspace or session. > OTOH, since repository creation is not covered by the api, it's > destruction should be neither. +1 The shutdown() method got into JackrabbitRepository in JCR-309 without too much consideration, and looking back it seems like a bad decision. I would deprecate the method in 1.5 and remove it (or make it throw an exception) in 2.0. BR, Jukka Zitting
Re: remove JackrabbitRepository.shutdown()
Hi! Am 15.04.2008 um 13:32 schrieb Marcel Reutegger: why is that an issue? repository construction and destruction is not specified in JSR 170 nor in JSR 283. applications will always have to write implementation specific code to shutdown a repository. JSR 283 will have a standardized mechanism to 'connect' to a repository. whether that also include repository construction is probably implementation dependent. repository shutdown is not mentioned at all. Things not mentioned in the spec != useless ideas. Jackrabbit's goal should not only be spec-compliance, but also usability for the developers/frameworks using it! Let's compare this to the JDBC API (as an example). but this is about getting a connection and closing it again, which is equivalent to obtaining a JCR session and logging out when your done. that's already standardized in JSR 170. Embedded JDBC solutions use parameters in the connection URL for starting databases (like "...START=true" at the end). One could do that via session attributes in JCR/Jackrabbit, but the spec prevents this by having the additional Repository interface, which has to be fetched via JNDI for repository startup in JSR-283. Just my 2 cents, Alex -- Alexander Klimetschek [EMAIL PROTECTED] >> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<
Re: remove JackrabbitRepository.shutdown()
Hi Thomas, Thomas Mueller wrote: So, you wouldn't have any interface that defines shutdown()? This is bad because: - Applications must hardcode a specific class, org.apache.jackrabbit.core.RepositoryImpl you have to hard code that in any case, because otherwise you cannot start the repository. - Applications can only be compatible to one specific implementation (Jackrabbit, or CRX) - Wrappers (for example JCRLog) are impossible why is that an issue? repository construction and destruction is not specified in JSR 170 nor in JSR 283. applications will always have to write implementation specific code to shutdown a repository. Repository closing can and should be implementation independent. I know repository creation is not, and that's already bad enough (I hope this will be fixed in JCR 2.0). JSR 283 will have a standardized mechanism to 'connect' to a repository. whether that also include repository construction is probably implementation dependent. repository shutdown is not mentioned at all. Let's compare this to the JDBC API (as an example). An application that uses the JDBC API can look like this: 1) import java.sql.*; 2) Class.forName(jdbcDriverClassName); 3) Connection conn = DriverManager.getConnection(url, user, password); 4) conn.close(); The application does not have to import any database vendor or version specific classes. The driver, url, user and password are parameters (strings). When using newer versions of Java, you don't even need line 2 (drivers are discovered automatically). When using your approach, it would look like this: 1) import java.sql.*; 2) import com.oracle10.*; 3) OracleConnectionImpl conn = OracleConnectionImpl.create(...); 4) conn.close(); If you switch from Oracle to PostgreSQL, you would have to change the import statement and recompile the application. Maybe even if you change from Oracle 10 to Oracle 11 (because you are importing classes in line 2, not just interfaces). Your have to pass a specific class (OracleConnectionImpl) in your application if you close the connection somewhere else. but this is about getting a connection and closing it again, which is equivalent to obtaining a JCR session and logging out when your done. that's already standardized in JSR 170. regards marcel
Re: remove JackrabbitRepository.shutdown()
Hi, Am Montag, den 14.04.2008, 10:16 -0700 schrieb Tobias Bocanegra: > hi, > i want to remove the shutdown method from the JackrabbitRepository > interface. the reason is that there should at least be some > authorization. so rather move that to workspace or session. > OTOH, since repository creation is not covered by the api, it's > destruction should be neither. > > wdyt? First of all, the method is public API (for quite some time now). So we cannot just remove the method without breaking backwards compatibility ! -1 therefore to just removing. BUT: I understand the "security" requirement to prevent shutting down an instance which you happen to get into your hands. Especially in case the instance is the RepositoryImpl instance retrieved e.g. from JDNI. My two options would be: (1) JackrabbitRepository.shutdown(Session) provide a valid Session with enough access rights (2) Add an RepositoryAdmin interface which is retrieved from JackrabbitSession.getRepositoryAdmin() method This would allow implementing more repository level administrative functionality which may be tied to limited access rights. Node Type Management (actually available from the Workspace interface in JCR) and Workspace Management (actually available from the Workspace interface in JCR 2.0). My personal favourite would be #2. But as the possible additional functionality (NodeType Management and Workspace management) is available from the Workspace interface in JCR 2.0, I tend to favorize #1. Regards Felix
Re: remove JackrabbitRepository.shutdown()
Hi, > To me it does not seem right to have that method in the API. So, you wouldn't have any interface that defines shutdown()? This is bad because: - Applications must hardcode a specific class, org.apache.jackrabbit.core.RepositoryImpl - Applications can only be compatible to one specific implementation (Jackrabbit, or CRX) - Wrappers (for example JCRLog) are impossible Repository closing can and should be implementation independent. I know repository creation is not, and that's already bad enough (I hope this will be fixed in JCR 2.0). Let's compare this to the JDBC API (as an example). An application that uses the JDBC API can look like this: 1) import java.sql.*; 2) Class.forName(jdbcDriverClassName); 3) Connection conn = DriverManager.getConnection(url, user, password); 4) conn.close(); The application does not have to import any database vendor or version specific classes. The driver, url, user and password are parameters (strings). When using newer versions of Java, you don't even need line 2 (drivers are discovered automatically). When using your approach, it would look like this: 1) import java.sql.*; 2) import com.oracle10.*; 3) OracleConnectionImpl conn = OracleConnectionImpl.create(...); 4) conn.close(); If you switch from Oracle to PostgreSQL, you would have to change the import statement and recompile the application. Maybe even if you change from Oracle 10 to Oracle 11 (because you are importing classes in line 2, not just interfaces). Your have to pass a specific class (OracleConnectionImpl) in your application if you close the connection somewhere else. Regards, Thomas
Re: remove JackrabbitRepository.shutdown()
Hi, > that is not true. a workspace has the same authorization scope as the > session and is retrieved via the session. Yes, technically it may have the same authorization scope. However this is not obvious to an end user. Anyway, having to call a method on Workspace to close the repository seems strange. > the correct location for the shutdown method would be on the > repository, so passing the session could be another option: > > Repository.shutdown(Session s); Looks good, +1 > or on some management object, > RepositoryManagement Session.getRepositoryManagement() > RepositoryManagement.shutdown() > this object could also be used for other 'admin' stuff, like nodetype > registration. If there are more such methods then that's good as well. Regards, Thomas
Re: remove JackrabbitRepository.shutdown()
Tobias Bocanegra wrote: i want to remove the shutdown method from the JackrabbitRepository interface. the reason is that there should at least be some authorization. so rather move that to workspace or session. OTOH, since repository creation is not covered by the api, it's destruction should be neither. I agree with you. To me it does not seem right to have that method in the API. Looking at the method that creates a repository, we have the static method RepositoryImpl.create(RepositoryConfig), which returns a RepositoryImpl. Who ever calls that method is most probably also responsible for shutting the repository down at the appropriate time. And RepositoryImpl indeed has a shutdown method, which is all you need. regards marcel
Re: remove JackrabbitRepository.shutdown()
> I agree, to support authorization the method could be on JackrabbitSession: > > void JackrabbitSession.shutdownRepository() throws RepositoryException > > Maybe with a boolean parameter forceShutdown to shutdown even if > others are connected, but such a method could be added later on as > well. > > In my view it makes more sense on the session than on the workspace > because workspace objects don't necessarily have an authorization > context, same as repository objects. However session always have that. that is not true. a workspace has the same authorization scope as the session and is retrieved via the session. this is mandatory and intentional since it offers methods like copy and clone which of course need authorization, too. the correct location for the shutdown method would be on the repository, so passing the session could be another option: Repository.shutdown(Session s); or on some management object, RepositoryManagement Session.getRepositoryManagement() RepositoryManagement.shutdown() this object could also be used for other 'admin' stuff, like nodetype registration. -- toby > > By the way, there is SessionImpl.createDataStoreGarbageCollector that > is similar. Offtopic: this methods should probably also be added to > JackrabbitSession, but then we need to add a > JackrabbitGarbageCollector interface. > > Regards, > > Thomas > > > > > On Mon, Apr 14, 2008 at 7:16 PM, Tobias Bocanegra > <[EMAIL PROTECTED]> wrote: > > hi, > > i want to remove the shutdown method from the JackrabbitRepository > > interface. the reason is that there should at least be some > > authorization. so rather move that to workspace or session. > > OTOH, since repository creation is not covered by the api, it's > > destruction should be neither. > > > > wdyt? > > > > -- > > toby > > >
Re: remove JackrabbitRepository.shutdown()
Hi, I agree, to support authorization the method could be on JackrabbitSession: void JackrabbitSession.shutdownRepository() throws RepositoryException Maybe with a boolean parameter forceShutdown to shutdown even if others are connected, but such a method could be added later on as well. In my view it makes more sense on the session than on the workspace because workspace objects don't necessarily have an authorization context, same as repository objects. However session always have that. By the way, there is SessionImpl.createDataStoreGarbageCollector that is similar. Offtopic: this methods should probably also be added to JackrabbitSession, but then we need to add a JackrabbitGarbageCollector interface. Regards, Thomas On Mon, Apr 14, 2008 at 7:16 PM, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > hi, > i want to remove the shutdown method from the JackrabbitRepository > interface. the reason is that there should at least be some > authorization. so rather move that to workspace or session. > OTOH, since repository creation is not covered by the api, it's > destruction should be neither. > > wdyt? > > -- > toby >
