exist-development — eXist Developer's List

[Exist-development] eXist and Cocoon - protocol question

[Adam H. <Ada...@be...>]

Hi
I have a very important question. In an application we're developing,
we have a lot of different resource, some of which we want to place
inside eXist - but not all of them. The application is quite old, and
has a lot of gotchas, so we'd like to be able to simply retrieve some
data via cocoon:/ sitemap protocol, and store them in eXist. Is there
any good/proper way of doing such thing? We've tried to pass
cocoon:/resource in XQueryGenerator, but to no vail - we're getting
malformed URL - unknown protocol.

-- 
Pozdrawiam serdecznie
Adam Hepner

tel. 509 093 095
e-mail: ada...@be...
http://AdamHepner.pl

Re: [Exist-development] LDAP configuration in the security tag in conf.xml

[Dmitriy S. <sha...@gm...>]

Plus, current implementation don't use ldap authentication at all. 
Here example the way I like:
http://java.sun.com/products/jndi/tutorial/ldap/security/ldap.html

That give an option to control access per user(group) on ldap server.

-- 
Cheers,

Dmitriy Shabanov

Re: [Exist-development] LDAP configuration in the security tag in conf.xml

[Dmitriy S. <sha...@gm...>]

On Fri, 2010-06-18 at 10:43 -0500, Loren Cahlander wrote:
> The problem that I have been encountering is
> org.exist.security.UserImpl.authenticate().  I think that we need to
> move the current UserImpl into internal and create a new UserImpl
> under ldap that authenticates against the LDAP server.

Yes, it should be:

SecurityManager have several Realm that create User on authentication,
look at openid implementation.

-- 
Cheers,

Dmitriy Shabanov

Re: [Exist-development] LDAP configuration in the security tag in conf.xml

[Loren C. <lor...@gm...>]

Hello Dmitriy,

The problem that I have been encountering is org.exist.security.UserImpl.authenticate().  I think that we need to move the current UserImpl into internal and create a new UserImpl under ldap that authenticates against the LDAP server.

Loren

On Jun 17, 2010, at 10:45 PM, Dmitriy Shabanov wrote:

> On Thu, 2010-06-17 at 17:59 -0500, Loren Cahlander wrote:
>> org.exist.security.ldap.SecurityManagerImpl
> 
> Can it org.exist.security.ldap.RealmImpl.java? The design is quite simple: one SecurityManager - several Realms attached to it.
> 
> http://exist.svn.sourceforge.net/viewvc/exist/branches/shabanovd/animo/src/org/exist/security/
> 
> on authentication request the method in SecurityManager will be call:
> 
> public Account authenticate(String username, Object credentials) throws ExceptionAuthentication {
>                 Account account = null;
>                 for (Realm realm : realms.values()) {
>                         account = realm.authenticate(username, credentials);
>                         if (account != null)
>                                 return account;
>                 }
>                 throw new ExceptionAuthentication("User [" + username + "] not found");
>         }
> 
> As you can see it will go throw all attached realms & try to get authenticated user account.
> 
> -- 
> Cheers,
> 
> Dmitriy Shabanov

Re: [Exist-development] LDAP configuration in the security tag in conf.xml

[Dmitriy S. <sha...@gm...>]

On Thu, 2010-06-17 at 17:59 -0500, Loren Cahlander wrote:

> org.exist.security.ldap.SecurityManagerImpl


Can it org.exist.security.ldap.RealmImpl.java? The design is quite
simple: one SecurityManager - several Realms attached to it.

http://exist.svn.sourceforge.net/viewvc/exist/branches/shabanovd/animo/src/org/exist/security/

on authentication request the method in SecurityManager will be call:

public Account authenticate(String username, Object credentials) throws
ExceptionAuthentication {
	                Account account = null;
	                for (Realm realm : realms.values()) {
	                        account = realm.authenticate(username,
credentials);
	                        if (account != null)
	                                return account;
	                }
	                throw new ExceptionAuthentication("User [" + username +
"] not found");
	        }

As you can see it will go throw all attached realms & try to get
authenticated user account.

-- 
Cheers,

Dmitriy Shabanov

[Exist-development] LDAP configuration in the security tag in conf.xml

[Loren C. <lor...@gm...>]

Hello folks,

I am working on getting the LDAP security configuration to be easier to setup of eXist.  I am planning on adding a parameter tag within the security tag.  It would be something like the following:

        <security class="org.exist.security.ldap.SecurityManagerImpl">
            <param name="AuthLDAPUrl">ldap://127.0.0.1:389/ou=Users,dc=exist-db,dc=org?uid?sub?(objectclass=posixAccount)</param>
            <param name="AuthLDAPBindDN">cn=admin,dc=exist-db,dc=org</param>
            <param name="AuthLDAPBindPassword">1234</param>
            <param name="AuthLDAPGroupAttributeIsDN">off</param>
            <param name="AuthLDAPGroupAttribute">memberUid</param>
            <param name="Require">valid-user</param>
        </security>

This will centralize the properties for connecting to the LDAP server into conf.xml and no longer require the Java properties.  It also implements the BIND that will have the passwords verified against LDAP.
This would allow the Require to be valid-user, ldap-user, ldap-group, ldap-attribute or ldap-dn.  This would allow the limitation of the access to eXist to a subset of the users within and LDAP server.  A corporate wide LDAP server can contain users that should not have access to eXist.

I am looking at this configuration and also the one that I am recommending for the Jetty LoginModule configuration.  Those entries would be something like:

        <security class="org.exist.security.ldap.SecurityManagerImpl">
            <param name="debug">true</param>
            <param name="useLdaps">false</param>
            <param name="contextFactory">com.sun.jndi.ldap.LdapCtxFactory</param>
            <param name="hostname">127.0.0.1</param>
            <param name="port">389</param>
            <param name="bindDn">cn=admin,dc=exist-db,dc=org</param>
            <param name="bindPassword">1234</param>
            <param name="authenticationMethod">simple</param>
            <param name="forceBindingLogin">true</param>
            <param name="userBaseDn">ou=Users,dc=exist-db,dc=org</param>
            <param name="userRdnAttribute">uid</param>
            <param name="userIdAttribute">uid</param>
            <param name="userPasswordAttribute">userPassword</param>
            <param name="userObjectClass">posixAccount</param>
            <param name="roleBaseDn">ou=Groups,dc=exist-db,dc=org</param>
            <param name="roleNameAttribute">cn</param>
            <param name="roleMemberAttribute">memberUid</param>
            <param name="roleObjectClass">posixGroup</param>
        </security>

I am using the following configuration in  tools/jetty/etc/login.conf:

eXistDB {
org.eclipse.jetty.plus.jaas.spi.LdapLoginModule REQUIRED
    debug="true"
    useLdaps="false"
    contextFactory="com.sun.jndi.ldap.LdapCtxFactory"
    hostname="127.0.0.1"
    port="389"
    bindDn="cn=admin,dc=exist-db,dc=org"
    bindPassword="1234"
    authenticationMethod="simple"
    forceBindingLogin="true"
    userBaseDn="ou=Users,dc=exist-db,dc=org"
    userRdnAttribute="uid"
    userIdAttribute="uid"
    userPasswordAttribute="userPassword"
    userObjectClass="posixAccount"
    roleBaseDn="ou=Groups,dc=exist-db,dc=org"
    roleNameAttribute="cn"
    roleMemberAttribute="memberUid"
    roleObjectClass="posixGroup";
};

I need to implement a Credential subclass that will be something similar to the Password class, but be implemented for LDAP.

Loren

Re: [Exist-development] Additional functions for 'session' and 'response' XQuery modules

[Dannes W. <da...@ex...>]

Hi,

sure, basically all servlet methods could and should be implemented.
for the request object I have some more :-P

D.


2010/6/16 José María Fernández González <jm...@us...>:
> Hi everybody,
>        using 'request', 'session' and 'response' XQuery modules I have missed a few functions on 'session' and 'response' modules. In 'session' module you can know the max inactive interval of the session using get-max-inactive-interval, but you cannot set it. Also, you could know from the HttpSession the last accessed time and the creation time for this session, but there are no functions implementing them. And, in 'response' module, when you create a cookie, you cannot set neither the cookie domain nor the cookie path, needed by code running in eXist instances behind a proxy.
>
>        If there is no rejection, I'm implementing these useful functions tomorrow.

-- 
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624

[Exist-development] Additional functions for 'session' and 'response' XQuery modules

[José M. F. G. <jm...@us...>]

Hi everybody,
	using 'request', 'session' and 'response' XQuery modules I have missed a few functions on 'session' and 'response' modules. In 'session' module you can know the max inactive interval of the session using get-max-inactive-interval, but you cannot set it. Also, you could know from the HttpSession the last accessed time and the creation time for this session, but there are no functions implementing them. And, in 'response' module, when you create a cookie, you cannot set neither the cookie domain nor the cookie path, needed by code running in eXist instances behind a proxy.

	If there is no rejection, I'm implementing these useful functions tomorrow.

	Best wishes,
		José María
-- 
"La violencia es el último recurso del incompetente"
	- Salvor Hardin en "La Fundación" de Isaac Asimov
"Premature optimization is the root of all evil." - Donald Knuth

José María Fernández González
e-mail: jos...@gm...

Re: [Exist-development] XSL PI and REST

[José M. F. G. <jm...@us...>]

It seems core team is very busy these days. I have updated bug #3008137 with some bits from my previous e-mail, so there is more information there when they have a look at the bug report.

On 06/02/10 18:39, Dmitriy Shabanov wrote:
> Core team, where are you?
>

-- 
"La violencia es el último recurso del incompetente"
	- Salvor Hardin en "La Fundación" de Isaac Asimov
"Premature optimization is the root of all evil." - Donald Knuth

José María Fernández González
e-mail: jos...@gm...

[Exist-development] Scheduled jobs

[Evgeny G. <gaz...@gm...>]

Hello!

Just, I'm starting init XQuery so:

        <job name="init"
            period="500" delay="500" repeat="0"
            xquery="/db/init.xql">
            <parameter name="user" value="system"/>
            <parameter name="password" value="password"/>
        </job>


P.S. User "system" is one more DBA user, like admin, with complex
random password.

--
Evgeny

[Exist-development] Scheduled jobs

[Evgeny G. <gaz...@gm...>]

Ops! As I see the class org.exist.scheduler.StartupJob is not implemented!

--
Evgeny

[Exist-development] Scheduled jobs

[Evgeny G. <gaz...@gm...>]

We can check the access rights with "0700" for XQuery script and that admin
is owner of the script or store one in fs.

Think this or equal security is actual for other user type jobs too.
While don't see a big difference between startup and user jobs
and using XQuery for them

--
Evgeny

[Exist-development] Scheduled jobs

[Evgeny G. <gaz...@gm...>]

Hello!

The eXists sheduler module docs says:

"There are two types of jobs that can be scheduled. They are Java and XQuery.
Java jobs can be startup, system or user. XQuery jobs can only be user jobs."

Why not use XQuery jobs at startup too?

We can check the access rights with "0700" for XQuery script and that admin
is owner of the script or store one in fs.

--
Evgeny

Re: [Exist-development] Problem with XQuery URL Rewrite behind reverse proxy

[José M. F. G. <jm...@us...>]

Hi Adam,
	I think HTTP header X-Forwarded-For is not the one you need. It is attached and updated by proxies (it can contain more than one address), and it contains the host names or IP addresses from the sender or senders of the request (the original machine plus the previous crossed proxies in the query journey). <offtopic>But, if the proxy attaches the IP address instead of the DNS name, and multiple DNS names resolve to the same IP address, you are busted.</offtopic>

	As Dannes has written, you should read more on http://httpd.apache.org/docs/2.2/mod/mod_proxy.html . There you can find the header you probably need, which is X-Forwarded-Host . But as I don't know its behavior, I cannot give you more details.

	Good luck!
		José María

On 06/15/10 08:13, Dannes Wessels wrote:
> Hi,
>
> On Tue, Jun 15, 2010 at 12:14 AM, Adam Retter<ad...@ex...>  wrote:
>
>> There may be other aspects of the URL that we may want to make
>> configurable if you are running behind a reverse proxy?
>
> This has been on my list quite some time... good to see that others
> have the same issue as well. I guess the issue is much broader, in the
> 'request' function-namespace there are a few functions affected by the
> same subject... and the webstart functionality as well.
>
> Probably it should be an database wide configuration item.
>
> Please read the 'specs' carefully... there are a few implementations
> that do approximately the same. E.g.
> http://en.wikipedia.org/wiki/X-Forwarded-For
>
> You cannot use the header right away, it must be parsed first (take
> first item of list? or last?)
>
> read more on http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
> (revere proxy headers), there are a few more headers you could
> check...... be aware of that!
>
> cheers
>
> Dannes
>
>
>

-- 
"La violencia es el último recurso del incompetente"
	- Salvor Hardin en "La Fundación" de Isaac Asimov
"Premature optimization is the root of all evil." - Donald Knuth

José María Fernández González
e-mail: jos...@gm...

Re: [Exist-development] Problem with XQuery URL Rewrite behind reverse proxy

[Dannes W. <da...@ex...>]

Hi,

On Tue, Jun 15, 2010 at 12:14 AM, Adam Retter <ad...@ex...> wrote:

> There may be other aspects of the URL that we may want to make
> configurable if you are running behind a reverse proxy?

This has been on my list quite some time... good to see that others
have the same issue as well. I guess the issue is much broader, in the
'request' function-namespace there are a few functions affected by the
same subject... and the webstart functionality as well.

Probably it should be an database wide configuration item.

Please read the 'specs' carefully... there are a few implementations
that do approximately the same. E.g.
http://en.wikipedia.org/wiki/X-Forwarded-For

You cannot use the header right away, it must be parsed first (take
first item of list? or last?)

read more on http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
(revere proxy headers), there are a few more headers you could
check...... be aware of that!

cheers

Dannes



-- 
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624

[Exist-development] Problem with XQuery URL Rewrite behind reverse proxy

[Adam R. <ad...@ex...>]

I am attempting to use XQueryURLRewrite behind a reverse proxy, and
would ideally like to use configuration in controller-config.xml
similar to the following -

<root server-name="www.adamretter.org.uk" pattern="/*"
path="xmldb:exist:///db/adamretter.org.uk/"/>
<root server-name="www.expath.org" pattern="/*"
path="xmldb:exist:///db/expath.org/"/>
<root server-name="www.xquery.org.uk" pattern="/*"
path="xmldb:exist:///db/xquery.org.uk/"/>

However the server-name is evaluated against the request server name
(see lines 121 and 152 of org/exist/http/urlrewrite/RewriteConfig and
line 423 of org/exist/http/urlrewrite/XQueryURLRewrite).

If you are behind a reverse proxy then the server name will always be
localhost, I think we should make a configurable change here so that
the server name can either be taken from
HttpServletRequestWrapper.getServerName() or a http header set by the
reverse proxy - e.g.
HttpServletRequestWrapper.getHeader("X-Forwarded-For").

I would propose that this configurable option needs to go in the
filter config, e.g. -


<filter enabled="yes" path="/*"
class="org.exist.http.urlrewrite.XQueryURLRewrite">
        <param name="config" value="xmldb:exist:///db/controller-config.xml"/>

        <!-- override the server name src -->
        <param name="server-name-header">X-Forwarded-For</param>
</filter>


All seem okay with everyone?

There may be other aspects of the URL that we may want to make
configurable if you are running behind a reverse proxy?

Cheers Adam.


-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

[Exist-development] Fwd: Any progress on the LDAP implementation for eXist trunk?

[Loren C. <lor...@gm...>]

I found the following and am trying it:

http://jetty.codehaus.org/jetty/jetty-6/apidocs/org/mortbay/jetty/plus/jaas/ldap/LdapLoginModule.html

I am using the following configuration in  tools/jetty/etc/login.conf:

eXistDB {
org.eclipse.jetty.plus.jaas.spi.LdapLoginModule REQUIRED
    debug="true"
    useLdaps="false"
    contextFactory="com.sun.jndi.ldap.LdapCtxFactory"
    hostname="127.0.0.1"
    port="389"
    bindDn="cn=admin,dc=exist-db,dc=org"
    bindPassword="1234"
    authenticationMethod="simple"
    forceBindingLogin="false"
    userBaseDn="ou=Users,dc=exist-db,dc=org"
    userRdnAttribute="uid"
    userIdAttribute="uid"
    userPasswordAttribute="userPassword"
    userObjectClass="posixAccount"
    roleBaseDn="ou=Groups,dc=exist-db,dc=org"
    roleNameAttribute="cn"
    roleMemberAttribute="memberUid"
    roleObjectClass="posixGroup";
};


I encountered the following error:

13 Jun 2010 15:09:02,633 [qtp1310725808-27] INFO  (Slf4jLog.java [info]:92) - Searching for users with filter: '(&(objectClass={0})({1}={2}))' from base dn: ou=Users,dc=exist-db,dc=org 
13 Jun 2010 15:09:02,634 [qtp1310725808-27] INFO  (Slf4jLog.java [info]:92) - Found user?: true 
13 Jun 2010 15:09:02,642 [qtp1310725808-27] WARN  (Slf4jLog.java [warn]:124) - EXCEPTION  
javax.security.auth.login.LoginException: Login Failure: all modules ignored
	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:936)
	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
	at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
	at org.eclipse.jetty.plus.jaas.JAASLoginService.login(JAASLoginService.java:203)
	at org.eclipse.jetty.security.authentication.FormAuthenticator.validateRequest(FormAuthenticator.java:174)
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:417)
	at org.eclipse.jetty.server.session.SessionHandler.handle(SessionHandler.java:182)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:933)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:362)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:867)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
	at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:113)
	at org.eclipse.jetty.server.Server.handle(Server.java:334)
	at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:559)
	at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1007)
	at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:747)
	at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:209)
	at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:406)
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:462)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:436)
	at java.lang.Thread.run(Thread.java:636)





On Jun 12, 2010, at 10:46 PM, Loren Cahlander wrote:

> It does not work quite yet.  I will figure it out.
> 
> Loren
> 
> On Jun 12, 2010, at 10:38 PM, Dmitriy Shabanov wrote:
> 
>> Good, does it work for you? I plan to use several authentication services. Can you try:
>> 
>>     <Call name="addBean">
>>       <Arg>
>>         <New class="org.eclipse.jetty.plus.jaas.JAASLoginService">
>>           <Set name="name">JAASLoginService</Set>
>>           <Set name="eXistDBLogin">eXistDB</Set>
>>           <Set name="LDAPLogin">LDAP</Set>
>>         </New>
>>       </Arg>
>>     </Call>
>> 
>> tools/jetty/etc/login.conf:
>> 
>> eXistDB {
>> org.exist.security.internal.EXistDBLoginModule required
>> debug="false";
>> };
>>     LDAP { 
>>          com.sun.security.auth.module.LdapLoginModule REQUIRED
>>              userProvider="ldap://ldap-svr/ou=Users,dc=example,dc=com"
>>              userFilter="(&(uid={USERNAME})(objectClass=inetOrgPerson))"
>>              debug=true;
>>       };
>> 
>> On Sun, Jun 13, 2010 at 5:07 AM, Loren Cahlander <lor...@gm...> wrote:
>> I think that I have figured it out.  I have to test it, but this is what I have found:
>> 
>> tools/jetty/etc/jetty.xml contains:
>> 
>>     <!-- =========================================================== -->
>>     <!-- Configure Authentication Login Service                      -->
>>     <!-- =========================================================== -->
>>     <Call class="java.lang.System" name="setProperty">
>>       <Arg>java.security.auth.login.config</Arg>
>>       <Arg><SystemProperty name="jetty.home" default="." />/etc/login.conf</Arg>
>>     </Call>
>> 
>>     <Call name="addBean">
>>       <Arg>
>>         <New class="org.eclipse.jetty.plus.jaas.JAASLoginService">
>>           <Set name="name">JAASLoginService</Set>
>>           <Set name="LoginModuleName">eXistDB</Set>
>>         </New>
>>       </Arg>
>>     </Call>
>> 
>> 
>> tools/jetty/etc/login.conf contains:
>> 
>> eXistDB {
>> org.exist.security.internal.EXistDBLoginModule required
>> debug="false";
>> };
>> 
>> For LDAP, login.conf should be changed to:
>> 
>>      eXistDB {
>>          com.sun.security.auth.module.LdapLoginModule REQUIRED
>>              userProvider="ldap://ldap-svr/ou=Users,dc=example,dc=com"
>>              userFilter="(&(uid={USERNAME})(objectClass=inetOrgPerson))"
>>              debug=true;
>>      };
>> 
>> 
>> On Jun 11, 2010, at 04:44 PM, Loren Cahlander wrote:
>> 
>>> The ZIP file is 1.6 GB.
>>> 
>>> On Jun 11, 2010, at 04:42 PM, Loren Cahlander wrote:
>>> 
>>>> My VMWare image is available at http://support.syntactica.com/exist.zip
>>>> 
>>>> Ubuntu Login is exist
>>>> Password is vmware
>>>> 
>>>> the LDAP account manager is available at http://localhost/lam/ and the password is 1234 for both admin and lam
>>>> 
>>>> LDAP Administrator
>>>> DN: cn=admin,dc=exist-db,dc=org
>>>> PW: 1234
>>>> 
>>>> eXist Admin user
>>>> DN: uid=admin,ou=Users,dc=exist-db,dc=org
>>>> PW: admin123
>>>> 
>>>> 
>>>> On Jun 11, 2010, at 04:18 PM, Loren Cahlander wrote:
>>>> 
>>>>> Hello Dmitriy,
>>>>> 
>>>>> Are you still working on LDAP for eXist trunk?
>>>>> 
>>>>> I am working on the LEXA stack for eXist.  It includes LDAP for authentication.  I am trying to get eXist talking to my LDAP server and it looks like eXist is not complaining, but when I go to /administration/ it does not work.  I get the following:
>>>>> 
>>>>> 
>>>>> 11 Jun 2010 16:13:33,320 [qtp2133251039-26] INFO  (SecurityManagerImpl.java [getUserByName]:221) - Attempting to get user by: uid=admin,ou=Users,dc=exist-db,dc=org 
>>>>> 11 Jun 2010 16:13:33,328 [qtp2133251039-26] INFO  (SecurityManagerImpl.java [getUser]:353) - User uid=admin,ou=Users,dc=exist-db,dc=org found, attempting to find group and construct... 
>>>>> 11 Jun 2010 16:13:33,328 [qtp2133251039-26] INFO  (SecurityManagerImpl.java [newUserFromAttributes]:283) - Searching for gidNumber=1 in ou=Groups,dc=exist-db,dc=org 
>>>>> 11 Jun 2010 16:13:33,329 [qtp2133251039-26] INFO  (SecurityManagerImpl.java [newUserFromAttributes]:299) - Constructing user admin/1 in group dba 
>>>>> 11 Jun 2010 16:13:33,330 [qtp2133251039-26] INFO  (SecurityManagerImpl.java [newUserFromAttributes]:320) - Finding additional groups... 
>>>>> 11 Jun 2010 16:13:33,333 [qtp2133251039-26] WARN  (Slf4jLog.java [warn]:124) - EXCEPTION  
>>>>> javax.security.auth.login.FailedLoginException: Wrong password for user [admin] 
>>>>> 	at org.exist.security.internal.EXistDBLoginModule.login(EXistDBLoginModule.java:158)
>>>>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>>>> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>> 	at java.lang.reflect.Method.invoke(Method.java:616)
>>>>> 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
>>>>> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
>>>>> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
>>>>> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
>>>>> 	at java.security.AccessController.doPrivileged(Native Method)
>>>>> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
>>>>> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
>>>>> 	at org.eclipse.jetty.plus.jaas.JAASLoginService.login(JAASLoginService.java:203)
>>>>> 	at org.eclipse.jetty.security.authentication.FormAuthenticator.validateRequest(FormAuthenticator.java:174)
>>>>> 	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:417)
>>>>> 	at org.eclipse.jetty.server.session.SessionHandler.handle(SessionHandler.java:182)
>>>>> 	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:933)
>>>>> 	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:362)
>>>>> 	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:867)
>>>>> 	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
>>>>> 	at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
>>>>> 	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:113)
>>>>> 	at org.eclipse.jetty.server.Server.handle(Server.java:334)
>>>>> 	at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:559)
>>>>> 	at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1007)
>>>>> 	at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:747)
>>>>> 	at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:209)
>>>>> 	at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:406)
>>>>> 	at org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:462)
>>>>> 	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:436)
>>>>> 	at java.lang.Thread.run(Thread.java:636)
>>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> 
>> -- 
>> Dmitriy Shabanov
> 

Re: [Exist-development] How 'at-relative' extention of the import clause that will facilitate module sharing

[Dmitriy S. <sha...@gm...>]

On Fri, 2010-06-04 at 13:41 +0100, Thomas White wrote:
> 
> I have tried to find an URL in W3C  web site where I can submit a
> proposition for 'at-relative' so far unsuccessfully.
> Can somebody please point me to URL where I can do so.

Try this one
http://lists.w3.org/Archives/Public/www-ql/

-- 
Cheers,

Dmitriy Shabanov

Re: [Exist-development] How 'at-relative' extention of the import clause that will facilitate module sharing

[Dan M. <dan...@gm...>]

>  For the last two years I made a dramatic shift from XSLT hard code purist
to a XQuery enthusiast who does almost everything in XQuery (Dan I can see
you smiling already!) and I produce the result may be 5 to 10 times quicker.


:-))))))

On Thu, Jun 3, 2010 at 11:26 PM, Thomas White <tho...@gm...> wrote:

> James,
>
> Sorry for the delayed response.
>
>
> On 31 May 2010 10:06, James Fuller <jam...@ex...> wrote:
>
>> Helle Joe,
>> a few ruminations on your last 'at-relative' post:
>>
>> * adding at-relative is a change to xquery e.g. we would no longer be
>> providing XQuery v1.0 and would probably have to give an exist specific
>> version ... in reality I doubt there are any real backwards/forward compat
>> issues but once you start proposing changing foundations of xquery this can
>> lead to worst thing
>>
> ... probably cleaner to provide an exist option defining the default
>> behavior of 'at' (which in the xquery spec is a bit ambiguous and gives us
>> wiggle room to impart lots of different potentially desired behavior)
>> instead of adding to the language. I know others have extended xquery in
>> this fashion (ML, 28msec) but unsure of how safe it is to not have xquery
>> version "1.0"; at the top of my xquery files for now into the future.
>>
>
> I no not think there is a real problem about backwards/forward
> compatibility issues. Other XQuery vendors have chosen to deal with
> the challenges that the real life offer and they offered a solution by
> extending the language. What they did is "implementation is the
> specification" vs "design by committee" and the latter is notorious about
> how slow, inefficient and sometimes even driven by ulterior motives a design
> process could be.  When we offer a good solution that proves its usefulness
> it will be adopted by the others quickly.
>
> To me the inability to create a library that can keep its internal
> structure the way vendor wants or needs and forcing modules to be always
> self contained is a severe limitation and major problem that discourages
> people to share their code. If I have a solution that is separated in a
> number of modules and I want to share it I need to go to the trouble and
> combine all modules into one file and have one version of the code for
> internal use and other for sharing. That is counter productive and may be
> that is why there are not that many XQuery libraries available out there.
>
> Your idea of changing the default behaviour of 'at' is actually what I
> wanted to avoid. The reason I propose 'at-relative' was to add new feature
> and in the same time do not break any existing code.
>
>
>> * generating modules which themselves are interdependent on other modules
>> is creating a dependency graph which will cause probs in any programming
>> language;
>>
>
> As you said "... arguably an xquery developer shouldn't have to worry about
> this". It is done in many other languages and it is not  that complicated to
> be done with XQuere as well if we want to.
>
>
>> I know we want to treat xquery as a programming language but sometimes its
>> limitations should serve as a warning ..
>>
>
> And here is where I am going to take it personally (not really, but just to
> show how passionate I am about what I am doing :-). XQuery is a very
> powerful language that is capable of amazing things. For the last two years
> I made a dramatic shift from XSLT hard code purist to a XQuery enthusiast
> who does almost everything in XQuery (Dan I can see you smiling already!)
> and I produce the result may be 5 to 10 times quicker.
>
> Limitations like this do not serve any good purpose. They are there just
> because a quick and simple approach was needed when the XQuery spec was
> produced. Nothing more.
> May be it is height time to start treating XQuery as a real language. It is
> strange that I need to prove we need something that in any other language is
> a good practice that has proven its advantages for years.
>
> . also I really don't see your problem as something that needs to be solved
>> by eXist e.g. clever source control/CM can mitigate most of the issues on
>> deployment
>>
>
> I do not get this. If I use a library from somebody else how the source
> control will solve anything? It comes as a package.
>
>
>> * 3 levels of importing can be a sign of something bad ... to take an
>> analogy with class inheritance most humans stop grokking things at 2 levels
>>  ... I think its a good goal to make library modules that are standalone if
>> possible and can be understood without having to 'snake' down a complicated
>> set of deps ... better yet if they try to standardize (expath, exquery, etc)
>>
>
> I think we a talking about completely different issues. In XQuery we do
> not have a *vertical *levels of inheritance - we have a *
> horizontal level re-usability*. Consider the case of hotel management
> system where for each main entity like visitor, reservation, room and report
> there is a team that organised their code in number of modules. The problem
> comes when they need to share code across teams. A Booking needs to use some
> functions from Visitor and Room. There is not inheritance here - we just
> need to organise the code in nice relevant manageable chunks for each
> departments and share it. Unfortunately with the current implementation the
> only possible way is to to have huge monolithic modules. In practice if we
> have a single file per team this means we can have only one person working
> on an area at a time.
> I think this is big and very important - inability to import modules
> relative to the importing module does hinders the team work on large
> projects.
>
>
>> * arguably an xquery developer shouldn't have to worry about performance
>> implications of importing unused libraries, we should strive to solve this
>> at a lower level
>>
>
> Good words but when a module is monolithic there is not other chance but to
> create an instance of the whole module.
>
>
>> * OO is a great approach for getting teams of people working together and
>> generating progress with apparently a lot less communication of
>> design/intention, etc  ... functional languages like xquery are not as easy;
>> you may have to discover different ways of scaling up the development
>> process then trying to bolt on expectations set using other approaches.
>>
>
> I think working in teams, collaborating and reusability of code has nothing
> to do with the language or  the programming paradigm. It is all about
> providing mechanisms for assembling the pieces of code behind the scenes
> which is well established in OO programming and it just about to to used
> more in functional languages as well. XSLT is a functional language and it
> offers file import relative to the file that does the importing.
>
>
>> lastly, xquery provides a pretty poor reuse mechanism in the form of
>> import ... its always had probs and as I see from latest draft of v1.1
>> http://www.w3.org/TR/xquery-11/#id-module-import there is no plans to
>> enhance it; perhaps you can suggest this to the xquery WG to consider for
>> v1.1 ?
>>
>
> Yes I agree XQuery provides a pretty poor reuse mechanism.
> But we can change this and make XQuery code much more reusable.
> And one more thing - we do not necessary need to wait another 3 or 5 year
> for a committee to decide it for us :-)
>
> I hope I have convince all of you a little bit more in favour of
> 'at-relative' and the time when we are going to see it implemented came a
> little bit closer.
>
> Thomas White
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>
>


-- 
Dan McCreary
Semantic Solutions Architect
office: (952) 931-9198
cell: (612) 986-1552

Re: [Exist-development] How 'at-relative' extention of the import clause that will facilitate module sharing

[Thomas W. <tho...@gm...>]

James,

I am glad we are on the same page :-)

I do not see any problem when 'at-relative' becomes widely accepted and used
in our XQuery code. There will be no point of trying to be portable for a
feature that is not available in any other implementations. On other hand
this could become easily a 'specification by implementation' and eventually
being adopted by W3C working group.

At this point of time the only feasible option for me is to ask somebody to
do the implementation of 'at-relative'.
Then I will be able to complete the alpha version of my eXe framework and
offer a convenient way to pack and distribute XQuery libraries and
applications.

I have tried to find an URL in W3C  web site where I can submit a
proposition for 'at-relative' so far unsuccessfully.
Can somebody please point me to URL where I can do so.

Regards,
Thomas

------

Thomas White

Mobile:+44 7711 922 966
Skype: thomaswhite
gTalk: thomas.0007
Linked-In:http://www.linkedin.com/in/thomaswhite0007
facebook: http://www.facebook.com/thomas.0007





On 4 June 2010 06:59, James Fuller <jam...@ex...> wrote:

> Hello Thomas,
>
> I push xquery well beyond its intended limits most days, so you are
> preaching to the 'converted' for me and for most folks on this list ;)
>
> As for the functionality of 'at-relative', sure it can be useful and there
> are several ways to implement it. ... I am against any ways that make a new
> language versus staying within the boundaries of xquery as defined by the
> W3C which is why I suggested using options.  If we implement and someone
> uses 'at-relative' then we make a users xquery non portable ... I guess
> thats not a problem for you but it will be a problem for others.
>
> You are right that working groups at the W3C are slow but I feel that
> xquery v1.1 has some momentum and would once again suggest you submit your
> comments ... why not put trust in the people who created the language in the
> first place to get it right a second time ?
>
> I think the issue you have is timing, e.g. you want this functionality now,
> to summarize you can:
>
> 1) the nice thing about open source (versus other vendors who are not open
> source) is you can do it yourself now
>
> 2) ask someone to do it for you
>
> 3) pay someone to do it for you
>
> option 1) depends on you,
> option 2) if I was to do it I would do it the way I think is best
> option 3) all of use exist dev people do paid for work on eXist as well.
>
> Great to see someone showing their passion for the language and just wanted
> to say we are both on the same side!
>
> hth, James Fuller
>
>
>

Re: [Exist-development] How 'at-relative' extention of the import clause that will facilitate module sharing

[James F. <jam...@ex...>]

Hello Thomas,

I push xquery well beyond its intended limits most days, so you are
preaching to the 'converted' for me and for most folks on this list ;)

As for the functionality of 'at-relative', sure it can be useful and there
are several ways to implement it. ... I am against any ways that make a new
language versus staying within the boundaries of xquery as defined by the
W3C which is why I suggested using options.  If we implement and someone
uses 'at-relative' then we make a users xquery non portable ... I guess
thats not a problem for you but it will be a problem for others.

You are right that working groups at the W3C are slow but I feel that xquery
v1.1 has some momentum and would once again suggest you submit your comments
... why not put trust in the people who created the language in the first
place to get it right a second time ?

I think the issue you have is timing, e.g. you want this functionality now,
to summarize you can:

1) the nice thing about open source (versus other vendors who are not open
source) is you can do it yourself now

2) ask someone to do it for you

3) pay someone to do it for you

option 1) depends on you,
option 2) if I was to do it I would do it the way I think is best
option 3) all of use exist dev people do paid for work on eXist as well.

Great to see someone showing their passion for the language and just wanted
to say we are both on the same side!

hth, James Fuller

Re: [Exist-development] How 'at-relative' extention of the import clause that will facilitate module sharing

[Thomas W. <tho...@gm...>]

James,

Sorry for the delayed response.


On 31 May 2010 10:06, James Fuller <jam...@ex...> wrote:

> Helle Joe,
> a few ruminations on your last 'at-relative' post:
>
> * adding at-relative is a change to xquery e.g. we would no longer be
> providing XQuery v1.0 and would probably have to give an exist specific
> version ... in reality I doubt there are any real backwards/forward compat
> issues but once you start proposing changing foundations of xquery this can
> lead to worst thing
>
... probably cleaner to provide an exist option defining the default
> behavior of 'at' (which in the xquery spec is a bit ambiguous and gives us
> wiggle room to impart lots of different potentially desired behavior)
> instead of adding to the language. I know others have extended xquery in
> this fashion (ML, 28msec) but unsure of how safe it is to not have xquery
> version "1.0"; at the top of my xquery files for now into the future.
>

I no not think there is a real problem about backwards/forward compatibility
issues. Other XQuery vendors have chosen to deal with the challenges that
the real life offer and they offered a solution by extending the language.
What they did is "implementation is the specification" vs "design by
committee" and the latter is notorious about how slow, inefficient and
sometimes even driven by ulterior motives a design process could be.  When
we offer a good solution that proves its usefulness it will be adopted by
the others quickly.

To me the inability to create a library that can keep its internal structure
the way vendor wants or needs and forcing modules to be always
self contained is a severe limitation and major problem that discourages
people to share their code. If I have a solution that is separated in a
number of modules and I want to share it I need to go to the trouble and
combine all modules into one file and have one version of the code for
internal use and other for sharing. That is counter productive and may be
that is why there are not that many XQuery libraries available out there.

Your idea of changing the default behaviour of 'at' is actually what I
wanted to avoid. The reason I propose 'at-relative' was to add new feature
and in the same time do not break any existing code.


> * generating modules which themselves are interdependent on other modules
> is creating a dependency graph which will cause probs in any programming
> language;
>

As you said "... arguably an xquery developer shouldn't have to worry about
this". It is done in many other languages and it is not  that complicated to
be done with XQuere as well if we want to.


> I know we want to treat xquery as a programming language but sometimes its
> limitations should serve as a warning ..
>

And here is where I am going to take it personally (not really, but just to
show how passionate I am about what I am doing :-). XQuery is a very
powerful language that is capable of amazing things. For the last two years
I made a dramatic shift from XSLT hard code purist to a XQuery enthusiast
who does almost everything in XQuery (Dan I can see you smiling already!)
and I produce the result may be 5 to 10 times quicker.

Limitations like this do not serve any good purpose. They are there just
because a quick and simple approach was needed when the XQuery spec was
produced. Nothing more.
May be it is height time to start treating XQuery as a real language. It is
strange that I need to prove we need something that in any other language is
a good practice that has proven its advantages for years.

. also I really don't see your problem as something that needs to be solved
> by eXist e.g. clever source control/CM can mitigate most of the issues on
> deployment
>

I do not get this. If I use a library from somebody else how the source
control will solve anything? It comes as a package.


> * 3 levels of importing can be a sign of something bad ... to take an
> analogy with class inheritance most humans stop grokking things at 2 levels
>  ... I think its a good goal to make library modules that are standalone if
> possible and can be understood without having to 'snake' down a complicated
> set of deps ... better yet if they try to standardize (expath, exquery, etc)
>

I think we a talking about completely different issues. In XQuery we do not
have a *vertical *levels of inheritance - we have a *
horizontal level re-usability*. Consider the case of hotel management system
where for each main entity like visitor, reservation, room and report there
is a team that organised their code in number of modules. The problem comes
when they need to share code across teams. A Booking needs to use some
functions from Visitor and Room. There is not inheritance here - we just
need to organise the code in nice relevant manageable chunks for each
departments and share it. Unfortunately with the current implementation the
only possible way is to to have huge monolithic modules. In practice if we
have a single file per team this means we can have only one person working
on an area at a time.
I think this is big and very important - inability to import modules
relative to the importing module does hinders the team work on large
projects.


> * arguably an xquery developer shouldn't have to worry about performance
> implications of importing unused libraries, we should strive to solve this
> at a lower level
>

Good words but when a module is monolithic there is not other chance but to
create an instance of the whole module.


> * OO is a great approach for getting teams of people working together and
> generating progress with apparently a lot less communication of
> design/intention, etc  ... functional languages like xquery are not as easy;
> you may have to discover different ways of scaling up the development
> process then trying to bolt on expectations set using other approaches.
>

I think working in teams, collaborating and reusability of code has nothing
to do with the language or  the programming paradigm. It is all about
providing mechanisms for assembling the pieces of code behind the scenes
which is well established in OO programming and it just about to to used
more in functional languages as well. XSLT is a functional language and it
offers file import relative to the file that does the importing.


> lastly, xquery provides a pretty poor reuse mechanism in the form of import
> ... its always had probs and as I see from latest draft of v1.1
> http://www.w3.org/TR/xquery-11/#id-module-import there is no plans to
> enhance it; perhaps you can suggest this to the xquery WG to consider for
> v1.1 ?
>

Yes I agree XQuery provides a pretty poor reuse mechanism.
But we can change this and make XQuery code much more reusable.
And one more thing - we do not necessary need to wait another 3 or 5 year
for a committee to decide it for us :-)

I hope I have convince all of you a little bit more in favour of
'at-relative' and the time when we are going to see it implemented came a
little bit closer.

Thomas White

Re: [Exist-development] XSL PI and REST

[Dmitriy S. <sha...@gm...>]

Core team, where are you?

-- 
Cheers,

Dmitriy Shabanov

On Wed, 2010-06-02 at 11:35 +0200, José María Fernández González wrote:
> Hi Dmitriy,
> 	but then, which is the meaning of "<serializer enable-xsl='...'" if it is being ignored? AFAIHS currently, at WebDAV level the configuration option is bypassed by module defaults (not to apply/follow XSL PIs, which is reasonable for such protocol), at REST level it is bypassed by its defaults (to apply/follow XSL PIs), at backup level it is obviously forced to not apply/follow XSL PIs (very reasonable), at org.exist.xmldb.LocalCollection level it is bypassed by its defaults (not to apply/follow XSL PIs, again reasonable), ...
> 
> 	So, there are very few key places in eXist code where that configuration option is being taken into account. The documentation of "<serializer enable-xsl='...'" configuration option should be improved, explaining its scope, and from my point of view, it should control the default behavior of REST interface.
> 
> 	Cheers,
> 		José María
> 
> On 06/02/10 06:22, Dmitriy Shabanov wrote:
> > Hi,
> > For now, PI instructions have higher priority than conf.xml settings, I
> > recommend to add option that will control that priority: <serializer
> > master="PI-conf" enable-xsl="no" - mean PI instruction will overwrite
> > conf's one, <serializer master="conf-PI" enable-xsl="no" - PI will be
> > ignored
> > --
> > Dmitriy Shabanov
> > 2010/6/1 José María Fernández González <jm...@us...
> > <mailto:jm...@us...>>
> >
> >     Hi Dmitryi,
> >             the serializer already has that option at conf.xml level for
> >     XSL PIs, and that's the reason about these e-mails: the
> >     configuration option from conf.xml is not honored (i.e. is ignored)
> >     on REST because hardcoded defaults from REST module for this option
> >     (and others) are passed to the serializer, so global defaults are
> >     ignored/bypassed.
> >
> >
> >     On 06/01/10 14:21, Dmitriy Shabanov wrote:
> >
> >         Can we add on option auto-no (auto-yes, yes, no) at serializer
> >         configuration? or something ... for now the behavior is quite
> >         clear -
> >         files' PI instructions have higher priority, so we need on option to
> >         change priority.
> >
> >         2010/5/31 José María Fernández González
> >         <jm...@us... <mailto:jm...@us...>
> >         <mailto:jm...@us...
> >         <mailto:jm...@us...>>>
> >
> >
> >             Hi again,
> >                     I opened bug #3008137 at Sourceforge about this
> >         issue, where
> >             I'm describing the problem, and a quick fix. If there is no
> >             objection, I would like to apply that fix on trunk on Wednesday.
> >
> >                     José María
> >
> >             On 05/27/10 20:02, José María Fernández González wrote:
> >          > Hi everybody,
> >          > I have just realized that RESTServer enables XSL PI processing by
> >          > default, even when it is explicitly disabled in conf.xml through
> >          > '<serializer enable-xsl="no" ...'. Is there some (unknown)
> >         reason for
> >          > this odd behavior? If it is not, I would like to fix it.
> >
> 

Re: [Exist-development] XSL PI and REST

[José M. F. G. <jm...@us...>]

Hi Dmitriy,
	but then, which is the meaning of "<serializer enable-xsl='...'" if it is being ignored? AFAIHS currently, at WebDAV level the configuration option is bypassed by module defaults (not to apply/follow XSL PIs, which is reasonable for such protocol), at REST level it is bypassed by its defaults (to apply/follow XSL PIs), at backup level it is obviously forced to not apply/follow XSL PIs (very reasonable), at org.exist.xmldb.LocalCollection level it is bypassed by its defaults (not to apply/follow XSL PIs, again reasonable), ...

	So, there are very few key places in eXist code where that configuration option is being taken into account. The documentation of "<serializer enable-xsl='...'" configuration option should be improved, explaining its scope, and from my point of view, it should control the default behavior of REST interface.

	Cheers,
		José María

On 06/02/10 06:22, Dmitriy Shabanov wrote:
> Hi,
> For now, PI instructions have higher priority than conf.xml settings, I
> recommend to add option that will control that priority: <serializer
> master="PI-conf" enable-xsl="no" - mean PI instruction will overwrite
> conf's one, <serializer master="conf-PI" enable-xsl="no" - PI will be
> ignored
> --
> Dmitriy Shabanov
> 2010/6/1 José María Fernández González <jm...@us...
> <mailto:jm...@us...>>
>
>     Hi Dmitryi,
>             the serializer already has that option at conf.xml level for
>     XSL PIs, and that's the reason about these e-mails: the
>     configuration option from conf.xml is not honored (i.e. is ignored)
>     on REST because hardcoded defaults from REST module for this option
>     (and others) are passed to the serializer, so global defaults are
>     ignored/bypassed.
>
>
>     On 06/01/10 14:21, Dmitriy Shabanov wrote:
>
>         Can we add on option auto-no (auto-yes, yes, no) at serializer
>         configuration? or something ... for now the behavior is quite
>         clear -
>         files' PI instructions have higher priority, so we need on option to
>         change priority.
>
>         2010/5/31 José María Fernández González
>         <jm...@us... <mailto:jm...@us...>
>         <mailto:jm...@us...
>         <mailto:jm...@us...>>>
>
>
>             Hi again,
>                     I opened bug #3008137 at Sourceforge about this
>         issue, where
>             I'm describing the problem, and a quick fix. If there is no
>             objection, I would like to apply that fix on trunk on Wednesday.
>
>                     José María
>
>             On 05/27/10 20:02, José María Fernández González wrote:
>          > Hi everybody,
>          > I have just realized that RESTServer enables XSL PI processing by
>          > default, even when it is explicitly disabled in conf.xml through
>          > '<serializer enable-xsl="no" ...'. Is there some (unknown)
>         reason for
>          > this odd behavior? If it is not, I would like to fix it.
>

-- 
"La violencia es el último recurso del incompetente"
	- Salvor Hardin en "La Fundación" de Isaac Asimov
"Premature optimization is the root of all evil." - Donald Knuth

José María Fernández González
e-mail: jos...@gm...

Re: [Exist-development] XSL PI and REST

[Dmitriy S. <sha...@gm...>]

Hi,

For now, PI instructions have higher priority than conf.xml settings, I
recommend to add option that will control that priority: <serializer
master="PI-conf" enable-xsl="no" - mean PI instruction will overwrite conf's
one, <serializer master="conf-PI" enable-xsl="no" - PI will be ignored
-- 
Dmitriy Shabanov
2010/6/1 José María Fernández González <jm...@us...>

> Hi Dmitryi,
>        the serializer already has that option at conf.xml level for XSL
> PIs, and that's the reason about these e-mails: the configuration option
> from conf.xml is not honored (i.e. is ignored) on REST because hardcoded
> defaults from REST module for this option (and others) are passed to the
> serializer, so global defaults are ignored/bypassed.
>
>
> On 06/01/10 14:21, Dmitriy Shabanov wrote:
>
>> Can we add on option auto-no (auto-yes, yes, no) at serializer
>> configuration? or something ... for now the behavior is quite clear -
>> files' PI instructions have higher priority, so we need on option to
>> change priority.
>>
>> 2010/5/31 José María Fernández González <jm...@us...
>> <mailto:jm...@us...>>
>>
>>
>>    Hi again,
>>            I opened bug #3008137 at Sourceforge about this issue, where
>>    I'm describing the problem, and a quick fix. If there is no
>>    objection, I would like to apply that fix on trunk on Wednesday.
>>
>>            José María
>>
>>    On 05/27/10 20:02, José María Fernández González wrote:
>>     > Hi everybody,
>>     > I have just realized that RESTServer enables XSL PI processing by
>>     > default, even when it is explicitly disabled in conf.xml through
>>     > '<serializer enable-xsl="no" ...'. Is there some (unknown) reason
>> for
>>     > this odd behavior? If it is not, I would like to fix it.
>>
>