git migration!
Efraim Feinstein
The Open Siddur git repository is now set up at
https://github.com/opensiddur
1. Mostly because of the sheer size of the download, and other issues
like #5 below, I nuked the history. Most of the code was mine, but there
are a few files that aren't (more would be good!). If you have any files
that are still around that don't have a copyright header on them, be
sure to speak up and take credit ;-) The Google Code repository will
continue to provide the history for earlier releases.
2. If you want to hack opensiddur code publicly, you no longer have to
be registered in any way with the project. Just get a github account and
fork the project. Github has a system of pull requests that allow you to
send changes back to the central repository. If you think you'll be
doing a lot of work on some part of the project (c'mon, you know you
want to), let me know and I'll hand over commit access. I suggest
working on major changes in a branch (or on your own forked repository!).
3. Issue tracking will also be moving to github. I have no special love
for Google Code's issue tracker, and putting the issue tracker and the
repository on the same server allows us to do things like get automatic
linking between the issues in commit messages and the issue tracker. Now
could be a good time to inventory the existing issues and figure out if
any of them should be copied over, and close the ones that are not
relevant to 0.4.1. It shouldn't be hard to do, and it would be quite
helpful. If the issue is about UI, checking it out doesn't even require
source, because the source in master == 0.4.1, the source served by the VPS.
4. There have been a few changes to the build process and the docs/wiki
aren't updated yet. I hope to get to that between now and this weekend
(and anyone who wants to can help out...). Notably:
- move of issue tracker links
- move of repository links
- change instructions for obtaining source from subversion
- change system requirements
- former svn externals are now managed in the makefile (see below)
- eXist is now built instead of being packaged as a binary.
- As a result, you now need to set the JAVA_HOME variable in
Makefile.local in order to compile eXist. JAVA_HOME is the directory
containing the bin directory which contains the javac executable.
- The TEI tools are now the equivalent of externals, instead of being
repackaged as source. As a side benefit of the process, JLPTEI schema
compilation is now working again, so it should be possible to (1) hack
the XML schema and give it the care it needs and (2) test any JLPTEI
files that are generated against the schema.
The discussion groups will remain on Google Groups and the wiki will
stay put.
5. Don't throw away your svn clients yet. I couldn't find a good, easy
way to replace svn externals in the code (although there are a bunch of
suggestions on the 'net, listed on the wiki's "Git migration" page ), so
I now have the makefile running svn checkout and svn update on some
repositories it pulls. This may change in the future.
I'm still figuring out what I'm doing with git. If you know better than
me, and see me doing something stupid, let me know :-)
Thanks for all the links before; they were quite helpful!
--
---
Efraim Feinstein
Lead Developer
Open Siddur Project
http://opensiddur.net
http://wiki.jewishliturgy.org
Marc Stober
http://shop.github.com/products/open-source-nerd-merit-badge
--
You received this message because you are subscribed to the Google Groups "opensiddur-tech" group.
To post to this group, send email to opensid...@googlegroups.com.
To unsubscribe from this group, send email to opensiddur-te...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensiddur-tech?hl=en.
--
marcs...@gmail.com ~ www.marcstober.com ~ twitter: marcstober
Ze'ev Clementson
Does this page: http://wiki.jewishliturgy.org/Intro_to_hacking still
have up-to-date instructions for building everything?
Ze'ev
Efraim Feinstein
On 05/10/2011 11:55 AM, Ze'ev Clementson wrote:
> Does this page: http://wiki.jewishliturgy.org/Intro_to_hacking still
> have up-to-date instructions for building everything?
I did make an attempt at updating it. Between that page and
http://wiki.jewishliturgy.org/Mirroring_the_database you should be set.
I can't play with all platforms, so it's possible that I used Linux-isms
that aren't supported in BSD (aka OS X). I do know that build support on
Cygwin is broken and won't be fixed until someone who uses it wants to
maintain it. Cygwin + Java is a royal PITA, and I'm already stretching
hand-written Makefiles beyond what they should be doing.
Let me know if you have any issues.
Ze'ev Clementson
On Tue, May 10, 2011 at 9:10 AM, Efraim Feinstein
<efraim.f...@gmail.com> wrote:
> Hi,
>
> On 05/10/2011 11:55 AM, Ze'ev Clementson wrote:
>>
>> Does this page: http://wiki.jewishliturgy.org/Intro_to_hacking still
>> have up-to-date instructions for building everything?
>
> I did make an attempt at updating it. Between that page and
> http://wiki.jewishliturgy.org/Mirroring_the_database you should be set.
>
> I can't play with all platforms, so it's possible that I used Linux-isms
> that aren't supported in BSD (aka OS X). I do know that build support on
> Cygwin is broken and won't be fixed until someone who uses it wants to
> maintain it. Cygwin + Java is a royal PITA, and I'm already stretching
> hand-written Makefiles beyond what they should be doing.
>
> Let me know if you have any issues.
Ok, thanks. It'll be a few days before I get around to building but
I'll let you know how it goes.
- Ze'ev
Benjamin Fleischer
git replace might be what you need.
Efraim Feinstein
In the end, I decided to just not port the history from subversion. It
will still exist on Google Code, so it's not a huge deal.
The next git question I'm pondering is how to import other projects'
source trees.
In the latest incarnation, Hebmorph's repository is a submodule and I'm
following it on github to pull in any changes to my forked repository.
That one's easy.
The other source dependencies we have (eXist, XSpec, XSLTforms, TEI) are
all stored on svn (Google Code or Sourceforge). I used to bring them in
as svn:externals. As of now, they're just downloaded/updated using svn
in the Makefile. AFAICT, git has no exact equivalent of submodules when
deriving from a svn repository. The closest I could find was:
1. Use git-svn clone -r HEAD to make a new local repository,
2. push it to github
3. Use the github repository as a git submodule
4. every once in a while, rebase the github repository to upstream, pull
the changes into my local repository, recommit the opensiddur repository.
I'm keeping really slowly moving dependencies (like IzPack, which is a
dependency of eXist's installer build) as binary copies in our repository.
As a side effect, some of these are now patched on the fly in the
Makefile. I could probably store modified versions in our repository and
get rid of that step.
I'm aiming for eXist 1.6, which is now under development as eXist 1.5,
so it's a fast moving target.
XSLTForms is under rapid development too (a copy of it is in the eXist
source tree, but it always lags behind its trunk, and I'm a regular bug
reporter over there ;-) ).
XSpec and TEI are slow-moving targets.
The problem is essentially what
On 05/10/2011 02:34 PM, Benjamin Fleischer wrote:
> https://github.com/bf4/git-svn-mirror
is trying to solve (interesting link!).
> git clone --depth 1
> I think Scott Chacon mentions in here how to make that the repository
> default
> http://confreaks.net/videos/471-rubyconf2010-classy-git
Once we've reset the history, I'm not sure that we want to make depth 1
the default.
Thanks,
Ze'ev Clementson
On Tue, May 10, 2011 at 9:10 AM, Efraim Feinstein
<efraim.f...@gmail.com> wrote:
> Hi,
>
> On 05/10/2011 11:55 AM, Ze'ev Clementson wrote:
>>
>> Does this page: http://wiki.jewishliturgy.org/Intro_to_hacking still
>> have up-to-date instructions for building everything?
>
> I did make an attempt at updating it. Between that page and
> http://wiki.jewishliturgy.org/Mirroring_the_database you should be set.
>
> I can't play with all platforms, so it's possible that I used Linux-isms
> that aren't supported in BSD (aka OS X). I do know that build support on
> Cygwin is broken and won't be fixed until someone who uses it wants to
> maintain it. Cygwin + Java is a royal PITA, and I'm already stretching
> hand-written Makefiles beyond what they should be doing.
>
> Let me know if you have any issues.
I did a build on Mac OS X. Basically, everything built ok following
the Intro to hacking instructions. Here were the only issues I
encountered:
1. Although eXist is automatically retrieved from svn, HebMorph is not
automatically retrieved from git. I had to manually clone it in the
opensiddur/lib directory.
2. The admin and userman password prompts should probably occur at the
beginning of the make process so that the make can run unattended.
However, the entire make db-install && make db-install-wlc together
takes less than 10 minutes so it's not such a hardship.
I then ran eXist with: /usr/local/eXist/bin/startup.sh
To test, I went to the links you indicated in
http://wiki.jewishliturgy.org/Mirroring_the_database:
with the following results:
http://localhost:8080/ : Displays a local eXist page describing
Overview/Community/License
http://localhost:8080/code/apps/compiler : HTTP ERROR 404
http://localhost:8080/code/apps/builder : HTTP ERROR 404
http://localhost:8080/code/api : HTTP ERROR 404
Any ideas as to why it's not working for me?
- Ze'ev
Efraim Feinstein
Thanks for trying it out!
On 05/12/2011 04:17 PM, Ze'ev Clementson wrote:
> I did a build on Mac OS X. Basically, everything built ok following
> the Intro to hacking instructions. Here were the only issues I
> encountered:
>
> 1. Although eXist is automatically retrieved from svn, HebMorph is not
> automatically retrieved from git. I had to manually clone it in the
> opensiddur/lib directory.
OK... that's probably me not grokking git submodules. I need to add the
"other developer" stuff in
https://git.wiki.kernel.org/index.php/GitSubmoduleTutorial somewhere in
the Makefile
> 2. The admin and userman password prompts should probably occur at the
> beginning of the make process so that the make can run unattended.
Do you see an easy way to make it work? (it's around like 240 in the
Makefile)
> However, the entire make db-install&& make db-install-wlc together
> takes less than 10 minutes so it's not such a hardship.
>
> I then ran eXist with: /usr/local/eXist/bin/startup.sh
>
> To test, I went to the links you indicated in
> http://wiki.jewishliturgy.org/Mirroring_the_database:
>
> with the following results:
>
> http://localhost:8080/ : Displays a local eXist page describing
> Overview/Community/License
> http://localhost:8080/code/apps/compiler : HTTP ERROR 404
> http://localhost:8080/code/apps/builder : HTTP ERROR 404
> http://localhost:8080/code/api : HTTP ERROR 404
>
> Any ideas as to why it's not working for me?
Looks like you just discovered one of the problems with using eXist
directly from svn, unqualified by a revision number. The
controller-config.xml file changed in the eXist source so the textual
hook that patch uses to position the changes no longer worked. I
committed a new controller-config patch, and it seems to work now.
Ze'ev Clementson
On Thu, May 12, 2011 at 2:00 PM, Efraim Feinstein
<efraim.f...@gmail.com> wrote:
> Hi,
>
> Thanks for trying it out!
>
> On 05/12/2011 04:17 PM, Ze'ev Clementson wrote:
>>
>> I did a build on Mac OS X. Basically, everything built ok following
>> the Intro to hacking instructions. Here were the only issues I
>> encountered:
>>
>> 1. Although eXist is automatically retrieved from svn, HebMorph is not
>> automatically retrieved from git. I had to manually clone it in the
>> opensiddur/lib directory.
>
> OK... that's probably me not grokking git submodules. I need to add the
> "other developer" stuff in
> https://git.wiki.kernel.org/index.php/GitSubmoduleTutorial somewhere in the
> Makefile
>
>> 2. The admin and userman password prompts should probably occur at the
>> beginning of the make process so that the make can run unattended.
>
> Do you see an easy way to make it work? (it's around like 240 in the
> Makefile)
Why not just move these 2 lines to somewhere near the top of the makefile:
@read -p "Set the password for admin database user: " ADMPASS && \
read -p "Set the password for userman database user (enter for none):
" APASS && \
You could add another makefile tag conditioned on EXIST_INSTALL_JAR
that only prompts for the passwords.
>> However, the entire make db-install&& make db-install-wlc together
>> takes less than 10 minutes so it's not such a hardship.
>>
>> I then ran eXist with: /usr/local/eXist/bin/startup.sh
>>
>> To test, I went to the links you indicated in
>> http://wiki.jewishliturgy.org/Mirroring_the_database:
>>
>> with the following results:
>>
>> http://localhost:8080/ : Displays a local eXist page describing
>> Overview/Community/License
>> http://localhost:8080/code/apps/compiler : HTTP ERROR 404
>> http://localhost:8080/code/apps/builder : HTTP ERROR 404
>> http://localhost:8080/code/api : HTTP ERROR 404
>>
>> Any ideas as to why it's not working for me?
>
> Looks like you just discovered one of the problems with using eXist directly
> from svn, unqualified by a revision number. The controller-config.xml file
> changed in the eXist source so the textual hook that patch uses to position
> the changes no longer worked. I committed a new controller-config patch, and
> it seems to work now.
Ok, so I did a git pull and re-ran the 2 make's. I now get the
opensiddur application page coming up but I get some errors when I
press the compile button (which I've attached in case they give you
any clues). I'll do a make clean and rebuild (in case something got
messed up).
- Ze'ev
Efraim Feinstein
On 05/12/2011 05:37 PM, Ze'ev Clementson wrote:
> Why not just move these 2 lines to somewhere near the top of the makefile:
> @read -p "Set the password for admin database user: " ADMPASS&& \
> read -p "Set the password for userman database user (enter for none):
> " APASS&& \
>
> You could add another makefile tag conditioned on EXIST_INSTALL_JAR
> that only prompts for the passwords.
Not all make targets require the passwords, so putting them at the top
will make any use of make harder.
If I put the password reading under a tag, I think the variable
definitions will be taken to be commands and won't be globally accessible.
> Ok, so I did a git pull and re-ran the 2 make's. I now get the
> opensiddur application page coming up but I get some errors when I
> press the compile button (which I've attached in case they give you
> any clues). I'll do a make clean and rebuild (in case something got
> messed up).
I've never tested it on Safari, so I have no idea whether XSLTForms has
any issues there.
Do you see similar errors using the released 0.4.1 application? What
about using a different browser?
Ze'ev Clementson
(Line: 35) TRIGGER: document-uri.xql called: update on
/db/cache/code/transforms/data-compiler/tests-with-document-uri/standoff-relationship-notes.xml
restored standoff-relationship-notes.xml
shutting down database...
/usr/local/eXist/bin/client.sh -qls -u admin -F ././setup/setup.xql
-qls -u admin -F ././setup/setup.xql
Using locale: .UTF-8
eXist version 1.5.0dev, Copyright (C) 2001-2011 Wolfgang Meier
eXist comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; for details read the license file.
Connection to database failed; message: Wrong password for user [admin]
org.xmldb.api.base.XMLDBException: Wrong password for user [admin]
at org.exist.xmldb.DatabaseImpl.getUser(DatabaseImpl.java:270)
at org.exist.xmldb.DatabaseImpl.getLocalCollection(DatabaseImpl.java:186)
at org.exist.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:156)
at org.exist.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:151)
at org.xmldb.api.DatabaseManager.getCollection(Unknown Source)
at org.exist.client.InteractiveClient.connect(InteractiveClient.java:302)
at org.exist.client.InteractiveClient.connectToDatabase(InteractiveClient.java:2303)
at org.exist.client.InteractiveClient.run(InteractiveClient.java:2389)
at org.exist.client.InteractiveClient.main(InteractiveClient.java:281)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.exist.start.Main.invokeMain(Main.java:137)
at org.exist.start.Main.run(Main.java:463)
at org.exist.start.Main.main(Main.java:59)
rm -f ././setup/setup.xql
Done.
touch /usr/local/eXist/EXIST.AUTOINSTALLED
~/opensiddur $
Ze'ev Clementson
On Thu, May 12, 2011 at 2:54 PM, Efraim Feinstein
<efraim.f...@gmail.com> wrote:
> Hi,
>
> On 05/12/2011 05:37 PM, Ze'ev Clementson wrote:
>>
>> Why not just move these 2 lines to somewhere near the top of the makefile:
>> @read -p "Set the password for admin database user: " ADMPASS&& \
>> read -p "Set the password for userman database user (enter for
>> none):
>> " APASS&& \
>>
>> You could add another makefile tag conditioned on EXIST_INSTALL_JAR
>> that only prompts for the passwords.
>
> Not all make targets require the passwords, so putting them at the top will
> make any use of make harder.
>
> If I put the password reading under a tag, I think the variable definitions
> will be taken to be commands and won't be globally accessible.
It doesn't really matter - leave it as it is.
>> Ok, so I did a git pull and re-ran the 2 make's. I now get the
>> opensiddur application page coming up but I get some errors when I
>> press the compile button (which I've attached in case they give you
>> any clues). I'll do a make clean and rebuild (in case something got
>> messed up).
>
> I've never tested it on Safari, so I have no idea whether XSLTForms has any
> issues there.
>
> Do you see similar errors using the released 0.4.1 application? What about
> using a different browser?
When I access the released 0.4.1 application using Safari, I can
compile the texts without any problem. Attached is a screenshot of
generated output in Safari. So, the browser isn't the problem.
Ze'ev
Efraim Feinstein
make clean doesn't uninstall the existing database, it just cleans
generated files from the source tree. You need to remove the old
database (rm -fr /usr/local/eXist) or it will still have the old
password, which is unknown at the time of the install.
(I guess that should be in the docs somewhere)
On 05/12/2011 05:56 PM, Ze'ev Clementson wrote:
> After make clean&& make db-install, this is the last bit of output I get:
Efraim Feinstein
On 05/12/2011 06:06 PM, Ze'ev Clementson wrote:
> When I access the released 0.4.1 application using Safari, I can
> compile the texts without any problem. Attached is a screenshot of
> generated output in Safari. So, the browser isn't the problem.
I just tried it on my own in Chrome/Linux and I can't reproduce either
error.
The first one is saying that you got some kind of error from the server
and XSLTForms failed trying to parse XPath from an error that came back
from the server. The second one means that something in the db can't be
read while trying the transform. It could be file not found or a
permissions/login issue. The trick is going to be figuring out what file
it is.
You might be able to get some information by looking for exception
traces in /usr/local/eXist/webapp/WEB-INF/logs/exist.log . Just before
any exception, there should be a file reference. I sometimes find it
helpful to run tail -f on the log file while I'm debugging the error.
Does Safari have a web developer tool, like Firebug or Chrome Dev Tools?
If so, a record of what was transmitted/received would definitely help.
Ze'ev Clementson
On Thu, May 12, 2011 at 3:24 PM, Efraim Feinstein
<efraim.f...@gmail.com> wrote:
> I changed the topic...
Ok, so I've copied over part of your text from the other thread
instead of replying to that message:
On Thu, May 12, 2011 at 3:15 PM, Efraim Feinstein
<efraim.f...@gmail.com> wrote:
> Hi,
>
> make clean doesn't uninstall the existing database, it just cleans generated
> files from the source tree. You need to remove the old database (rm -fr
> /usr/local/eXist) or it will still have the old password, which is unknown
> at the time of the install.
>
> (I guess that should be in the docs somewhere)
That looked like it might be the problem as I built eXist once before
so it made sense that I might be getting errors related to having an
old version of the db. So, I did:
rm -fr /usr/local/eXist
make db-install
make db-install-wlc
/usr/local/eXist/bin/startup.sh
Then, I clicked on the http://localhost:8080/code/apps/builder link.
Then, in the demo app, I:
1. Clicked on 'Start new siddur' link in the sidebar
2. Clicked on 'Create an account' link
3. Entered User 'test' with password 'test' and pressed 'Create new user' button
4. Clicked on 'My Siddurim' link in the sidebar
5. Clicked on 'Start a new siddur' link
6. Entered a title of 'test' and pressed the 'Start new siddur' button
7. Clicked on 'Edit Content' link
8. Clicked on the 'Add' button next to אִיּוֹב ג
9. Pressed the 'Compile' button
At this point, I got the (attached) error dialog. However, I then
activated the Safari Error Console (part of the Safari development
tools) and pressed the 'Compile' button again. This time, it worked!
Unfortunately, it sometimes works and sometimes doesn't.
However, I then tried the same steps in Firefox and it worked
perfectly every time. So, it does seem to be Safari related.
>> When I access the released 0.4.1 application using Safari, I can
>> compile the texts without any problem. Attached is a screenshot of
>> generated output in Safari. So, the browser isn't the problem.
>
> I just tried it on my own in Chrome/Linux and I can't reproduce either
> error.
>
> The first one is saying that you got some kind of error from the server and
> XSLTForms failed trying to parse XPath from an error that came back from the
> server. The second one means that something in the db can't be read while
> trying the transform. It could be file not found or a permissions/login
> issue. The trick is going to be figuring out what file it is.
>
> You might be able to get some information by looking for exception traces in
> /usr/local/eXist/webapp/WEB-INF/logs/exist.log . Just before any exception,
> there should be a file reference. I sometimes find it helpful to run tail -f
> on the log file while I'm debugging the error.
I had a look at this log file and the following lines do show up when
I'm using Safari but do not show up when I'm using Firefox to display
the eXist content:
2011-05-12 16:27:21,305 [eXistThread-108] DEBUG
(HttpRequestWrapper.java [<init>]:129) - Retrieved 0 parameters.
2011-05-12 16:27:21,306 [eXistThread-108] DEBUG (XQuery.java
[execute]:249) - Execution took 1 ms
2011-05-12 16:27:21,306 [eXistThread-108] DEBUG (HTTPUtils.java
[addLastModifiedHeader]:61) - mostRecentDocumentTime: 0
2011-05-12 16:27:21,306 [eXistThread-108] DEBUG (RESTServer.java
[doGet]:331) - stylesheet = null
2011-05-12 16:27:21,306 [eXistThread-108] DEBUG (RESTServer.java
[doGet]:332) - query = null
2011-05-12 16:27:21,306 [eXistThread-108] DEBUG
(HttpRequestWrapper.java [<init>]:129) - Retrieved 0 parameters.
2011-05-12 16:27:21,308 [eXistThread-108] DEBUG (NativeSerializer.java
[serializeToReceiver]:107) - serializing document 385
(/db/code/common/common.xsl2) to SAX took 1 msec
2011-05-12 16:27:21,309 [eXistThread-207] WARN
(ReentrantReadWriteLock.java [release]:306) - Possible lock problem:
thread Thread[eXistThread-207,5,main] released a lock on
/db/code/common it didn't hold. Either the
thread was interrupted or it never acquired the lock. The lock was
owned by: null
> Does Safari have a web developer tool, like Firebug or Chrome Dev Tools?
> If so, a record of what was transmitted/received would definitely help.
Yes, Safari does have a web developer debugger; however, I didn't come
across anything that provided more clues.
Ze'ev
Ze'ev Clementson
conversation thread that you've opened.
Efraim Feinstein
There's a potentially huge hint in the attached image.
The course of events is:
The application sends a HTTP POST request. This is going to the right
place and its content is empty.
XSLTForms receives: NETWORK_ERR: XMLHttpRequest Exception 101
(I wish I knew what that meant -- Google?)
The failure results in a xforms-submit-error event being sent within
XForms, of type resource-error
XSLTForms then fails trying to display the error (Safari-weirdness?)
You're looking at a bug in either Safari or XSLTForms. If we can make a
minimum working example, I can submit the bug.
Ze'ev Clementson
<efraim.f...@gmail.com> wrote:
> There's a potentially huge hint in the attached image.
>
> The course of events is:
> The application sends a HTTP POST request. This is going to the right place
> and its content is empty.
> XSLTForms receives: NETWORK_ERR: XMLHttpRequest Exception 101
> (I wish I knew what that meant -- Google?)
According to this:
http://www.w3.org/TR/2007/WD-XMLHttpRequest-20070227/#exceptions
"exception is thrown when a network error occurs in synchronous requests"
If the 'compile' action has not returned data when the 'send' is
executed, that could potentially be the cause of the error message.
> The failure results in a xforms-submit-error event being sent within XForms,
> of type resource-error
> XSLTForms then fails trying to display the error (Safari-weirdness?)
>
> You're looking at a bug in either Safari or XSLTForms. If we can make a
> minimum working example, I can submit the bug.
Why do you think it's related to XSLTForms? Couldn't it also be eXist?
Presumably, the compilation phase retrieves the texts from eXist prior
to formatting the texts using XSLTForms?
- Ze'ev
Efraim Feinstein
Firefox)? Can you see if anything at all was transmitted or returned by
pressing compile? My suspicion is that nothing was ever transmitted, and
it's a bug in XSLTForms, but I could be wrong.
I'm extrapolating from the resource-error. It usually happens before
eXist ever sees
Ze'ev Clementson
<efraim.f...@gmail.com> wrote:
> Does Safari's web dev tool have a network watcher (like the Net panel in
> Firefox)? Can you see if anything at all was transmitted or returned by
> pressing compile? My suspicion is that nothing was ever transmitted, and
> it's a bug in XSLTForms, but I could be wrong.
I haven't been able to find anything like that in the Safari developer
tool. However, I'm not a Safari web developer so somebody may be able
to recommend some way of doing this.
- Ze'ev
Ze'ev Clementson
Do these eXist/XQuery errors make any sense to you?
(Line: 38) <vars from="main controller.xql">
<path>/code/transforms/format/xhtml/relationship.xsl2</path>
<resource>relationship.xsl2</resource>
<controller/>
<prefix>/db</prefix>
<root>xmldb:exist:///db</root>
<mapped-resource/>
<redirected-resource/>
</vars>
12 May 2011 18:27:41,261 [eXistThread-37] WARN (Slf4jLog.java
[warn]:50) - /code/api/data/original/group/test/673d4ee6-73a0-4053-85f0-afc184213a32
javax.servlet.ServletException: Error while serializing xml:
javax.xml.transform.TransformerException:
org.eclipse.jetty.io.EofException
at org.exist.http.servlets.EXistServlet.doPost(EXistServlet.java:580)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:534)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:476)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:517)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:934)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:404)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:184)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:869)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:240)
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:116)
at org.exist.http.urlrewrite.Forward.doRewrite(Forward.java:47)
at org.exist.http.urlrewrite.XQueryURLRewrite.doRewrite(XQueryURLRewrite.java:525)
at org.exist.http.urlrewrite.XQueryURLRewrite.doFilter(XQueryURLRewrite.java:344)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1323)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:474)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:480)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:934)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:404)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:184)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:869)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:151)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:346)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:581)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1057)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:807)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:220)
at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:526)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:41)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:528)
at java.lang.Thread.run(Thread.java:680)
Caused by: org.exist.http.BadRequestException: Error while serializing
xml: javax.xml.transform.TransformerException:
org.eclipse.jetty.io.EofException
at org.exist.http.RESTServer.writeResults(RESTServer.java:1945)
at org.exist.http.RESTServer.executeXQuery(RESTServer.java:1394)
at org.exist.http.RESTServer.doPost(RESTServer.java:626)
at org.exist.http.servlets.EXistServlet.doPost(EXistServlet.java:559)
... 39 more
Caused by: javax.xml.transform.TransformerException:
org.eclipse.jetty.io.EofException
at org.exist.util.serializer.SAXSerializer.endElement(SAXSerializer.java:363)
at org.exist.util.serializer.ReceiverToSAX.endElement(ReceiverToSAX.java:119)
at org.exist.storage.serializers.XIncludeFilter.endElement(XIncludeFilter.java:185)
at org.exist.memtree.DocumentImpl.endNode(DocumentImpl.java:1349)
at org.exist.memtree.DocumentImpl.streamTo(DocumentImpl.java:1274)
at org.exist.memtree.NodeImpl.streamTo(NodeImpl.java:704)
at org.exist.storage.serializers.Serializer.serializeToReceiver(Serializer.java:1003)
at org.exist.storage.serializers.Serializer.serializeToReceiver(Serializer.java:994)
at org.exist.storage.serializers.Serializer.toSAX(Serializer.java:947)
at org.exist.http.RESTServer.writeResults(RESTServer.java:1938)
... 42 more
(Line: 65) <authenticate>
<uri>/code/apps/builder/compile.xql</uri>
<header>false</header>
<attribute>test true</attribute>
<cookie>false</cookie>
<hdr>false</hdr>
<user-param>false</user-param>
<return>
<user>test</user>
<password>test</password>
</return>
</authenticate>
12 May 2011 18:28:14,334 [eXistThread-36] WARN (Slf4jLog.java
[warn]:50) - /code/apps/builder/compile.xql
java.lang.IllegalArgumentException: Invalid URI: xmldb URI scheme does
not start with xmldb:: safari-extension:.xml
at org.exist.xmldb.XmldbURI.create(XmldbURI.java:181)
at org.exist.xmldb.XmldbURI.lastSegment(XmldbURI.java:493)
at org.exist.storage.NativeBroker.getXMLResource(NativeBroker.java:1786)
at org.exist.xquery.functions.util.BinaryDoc.eval(BinaryDoc.java:98)
at org.exist.xquery.BasicFunction.eval(BasicFunction.java:68)
at org.exist.xquery.InternalFunctionCall.eval(InternalFunctionCall.java:55)
at org.exist.xquery.DynamicCardinalityCheck.eval(DynamicCardinalityCheck.java:72)
at org.exist.xquery.functions.fn.FunNot.evalBoolean(FunNot.java:160)
at org.exist.xquery.functions.fn.FunNot.eval(FunNot.java:143)
at org.exist.xquery.InternalFunctionCall.eval(InternalFunctionCall.java:55)
at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
at org.exist.xquery.PathExpr.eval(PathExpr.java:243)
at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
at org.exist.xquery.OpAnd.eval(OpAnd.java:77)
at org.exist.xquery.DebuggableExpression.eval(DebuggableExpression.java:56)
at org.exist.xquery.DebuggableExpression.eval(DebuggableExpression.java:63)
at org.exist.xquery.LetExpr.eval(LetExpr.java:210)
at org.exist.xquery.BindingExpression.eval(BindingExpression.java:156)
at org.exist.xquery.ConditionalExpression.eval(ConditionalExpression.java:100)
at org.exist.xquery.DebuggableExpression.eval(DebuggableExpression.java:56)
at org.exist.xquery.ConditionalExpression.eval(ConditionalExpression.java:102)
at org.exist.xquery.LetExpr.eval(LetExpr.java:155)
at org.exist.xquery.LetExpr.eval(LetExpr.java:208)
at org.exist.xquery.BindingExpression.eval(BindingExpression.java:156)
at org.exist.xquery.DebuggableExpression.eval(DebuggableExpression.java:56)
at org.exist.xquery.ConditionalExpression.eval(ConditionalExpression.java:102)
at org.exist.xquery.ConditionalExpression.eval(ConditionalExpression.java:100)
at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
at org.exist.xquery.PathExpr.eval(PathExpr.java:243)
at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:70)
at org.exist.xquery.XQuery.execute(XQuery.java:246)
at org.exist.xquery.XQuery.execute(XQuery.java:201)
at org.exist.http.urlrewrite.XQueryURLRewrite.runQuery(XQueryURLRewrite.java:679)
at org.exist.http.urlrewrite.XQueryURLRewrite.doFilter(XQueryURLRewrite.java:248)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1323)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:474)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:480)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:934)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:404)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:184)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:869)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:151)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:346)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:581)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1040)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:592)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214)
at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:526)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:41)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:528)
at java.lang.Thread.run(Thread.java:680)
Ze'ev Clementson
I've found the cause of the Safari issues - Safari Extensions. Safari
Extensions are similar to Greasemonkey scripts in Firefox. If I turn
off Safari Extensions, I don't have any problems running compile.xql.
So, it's probably one of the Safari Extensions that I normally have
loaded that is causing the problem. Since Safari Extensions and
Firefox Greasemonkey scripts can both inject arbitrary code into an
HTML page, I guess this could also potentially be a problem with
Firefox as well. It might be worthwhile to add a comment somewhere
that if you are having problems running the opensiddur app, you should
try turning off Safari Extensions and Firefox Greasemonkey scripts.
- Ze'ev