How about we have one small config file to start everything up and then
use, I don't know, how about an xml document in a collection for the
rest :-).
Mark
"Vladimir R. Bossicard" wrote:
> > But I think that some configuration along these lines would be extremely
> > simple to implement and prov
How do you see this working in the embedded mode?
Mark
Gianugo Rabellino wrote:
> As you might have noticed, I commited some new code in scratchpad. It's
> nothing special, and it's far from being finished, but I felt that it
> was much better to put it in CVS so that interested parties might
>
I must confess ignorance of Avalon and its configuration management
capabilities, but I will be reading the docs soon.
As I said, I'm happy to implement this config either from within system.xml
or in a seperate config file for version 1.1. I personally think the
simplest way is for the informati
Vladimir R. Bossicard wrote:
Why does a relative path not make sense?
Because it's not deterministic. It's relative to the cwd where the JVM
was started, which is IMHO a totally dumb thing.
You're right. But why do we have this "totally dumb thing" (sic)
implemented *as a standard*? We provide
Vladimir R. Bossicard wrote:
But I think that some configuration along these lines would be extremely
simple to implement and provide the Xindice administrator complete
control
over what XMLRPC methods are exposed and even allow him/her to add
his/her
own methods without mucking inside the core o
I think that a driver should not be configured at all in a complex way.
A driver should be ready for use right away, with no need to locate a
configuration file on a filesystem, this is why I'm more or less OK with
System.setProperty: I want to embed all the configuration data on a URL,
like JD
Why does a relative path not make sense?
Because it's not deterministic. It's relative to the cwd where the JVM
was started, which is IMHO a totally dumb thing.
You're right. But why do we have this "totally dumb thing" (sic)
implemented *as a standard*? We provide out-of-the-box a "totally dumb
But I think that some configuration along these lines would be extremely
simple to implement and provide the Xindice administrator complete control
over what XMLRPC methods are exposed and even allow him/her to add his/her
own methods without mucking inside the core of Xindice.
Gianugo things it's
As you might have noticed, I commited some new code in scratchpad. It's
nothing special, and it's far from being finished, but I felt that it
was much better to put it in CVS so that interested parties might
discuss it and participate in the development.
Just to make things clear, I'm strongly
Here's what I was thinking initially for the XMLRPC configuration.
My basic idea was to remove all hardcoded assumptions from the XMLRPC driver
code. I had initially thought to add this configuration information to the
system.x
Vladimir R. Bossicard wrote:
Vladimir had started seriously documenting the end-user setup experience
I believe. This is probably necessary (servlet stuff in particular) for
this release, sothat people can actually install it :).
Since I was (indirectly) asked for my opinion, there it is:
I propos
Vladimir R. Bossicard wrote:
+// We need to ensure that the database points to a
place where it makes
+// sense. If the path in the system.xml file is an
absolute path, then
+// honor it. If it's not, we first check for the system
property "xindice.db.ho
gianugo 2003/01/03 08:58:31
Added: java/scratchpad/tests/src/org/apache/xindice/core/security
PassiveCallbackHandlerTest.java
XindiceLoginModuleTest.java
XindiceUserManagerTest.java
java/scratchpad/s
+// We need to ensure that the database points to a place where it makes
+// sense. If the path in the system.xml file is an absolute path, then
+// honor it. If it's not, we first check for the system property "xindice.db.home"
+// and if the
Vladimir had started seriously documenting the end-user setup experience
I believe. This is probably necessary (servlet stuff in particular) for
this release, sothat people can actually install it :).
Since I was (indirectly) asked for my opinion, there it is:
I proposed a solution to end up the me
gianugo 2003/01/03 08:49:46
xml-xindice/java/scratchpad/tests/src/org/apache/xindice/core/security - New
directory
gianugo 2003/01/03 08:49:24
xml-xindice/java/scratchpad/tests/src/org/apache/xindice/core - New directory
gianugo 2003/01/03 08:49:04
xml-xindice/java/scratchpad/tests/src/org/apache/xindice - New directory
gianugo 2003/01/03 08:48:43
xml-xindice/java/scratchpad/tests/src/org/apache - New directory
gianugo 2003/01/03 08:48:23
xml-xindice/java/scratchpad/tests/src/org - New directory
gianugo 2003/01/03 08:46:46
xml-xindice/java/scratchpad/src/org/apache/xindice/core/security - New
directory
I don't: the stuff that I thought important in 1.1 is all working now.
Vladimir had started seriously documenting the end-user setup experience
I believe. This is probably necessary (servlet stuff in particular) for
this release, sothat people can actually install it :).
James
> -Original M
22 matches
Mail list logo
