AstroGrid registry bug with namespaces

We've recently upgrade our WFAU publishing registry to version Version
2006.3.03r. This has introduced a bug where previously registered
entries cannot be edited. When you submit the edits you get a:

env:ServerServer Error: No namespace defined for prefix vororg.exist.xmldb.LocalXPathQueryService.compile(LocalXPathQueryService.java:213) org.exist.xmldb.LocalXPathQueryService.doQuery(LocalXPathQueryService.java:280) org.exist.xmldb.LocalXPathQueryService.query(LocalXPathQueryService.java:112) org.exist.xmldb.LocalXPathQueryService.query(LocalXPathQueryService.java:103) org.astrogrid.xmldb.client.XMLDBServiceImpl.queryXQuery(XMLDBServiceImpl.java:235) org.astrogrid.registry.server.xmldb.XMLDBRegistry.query(XMLDBRegistry.java:71) org.astrogrid.registry.server.admin.AuthorityListManager.getManagedAuthorities(AuthorityListManager.java:118) org.astrogrid.registry.server.admin.AuthorityListManager.populateManagedMaps(AuthorityListManager.java:106) org.astrogrid.registry.server.admin.RegistryAdminService.updateResource(RegistryAdminService.java:282) org.apache.jsp.admin.addResourceEntry_jsp._jspService(addResourceEntry_jsp.java:488) org.apache.jasper.runtime.HttpJspBase.service(H
ttpJspBase.java:94) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapp
Valve.java:214) org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) org.apache.catal
ina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:540) org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) org.apache.c
atalina.core.ContainerBase.invoke(ContainerBase.java:929) org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) java.lang.Thread.run(Thread.java:595)

The fix is to copy the
xmlns:vr="http://www.ivoa.net/xml/VOResource/v0.10" from the
vor:Resource into the root vor:VOResources element.

VOMon - the VO service monitor has been released:

VOMon - the VO service monitor has been released:

http://vomon.sourceforge.net

VOMon is a mashup of the Astro Runtime
<http://www2.astrogrid.org/desktop/astro-runtime> and MARS
<http://leapfrog-mars.sourceforge.net/>, glued together with Python.
VOMon uses the Astro Runtime to query a Registry to obtain all the
services that match an admin-specified query. By default it queries the
central AstroGrid registry, but can be configured to query any
IVOA-compliant registry. This list of services is updated every hour or
so, so that VOMon will always have a reasonably up to date list of
services to monitor. The services are passed to MARS which does the
actual monitoring. Currently this monitoring consists of simply
pinging the accessURL and checking the response. Some services such as
Cone and SIAP, have default parameters appended to the accessURL to
ensure they do not fail. Once the VOSI interface is widely supported,
VOMon will be upgraded to use that. VOMon can either output a report to
be hosted on a web server, or present the user with a GUI interface.

An instance has been deployed at:
http://thor.roe.ac.uk/vomon/status.xml

Weekly Summary

* Prepared proposal for JISC CoP participation
* Plastic Website maintenance http://plastic.sourceforge.net and
general email business
* Finally, published IVOA Plastic Note:
http://ivoa.net/Documents/latest/PlasticDesktopInterop.html

Weekly update 15/11/06

* Submitted ADASS paper
* Currently moving the fastem algorithm off hempriggs. In the process
I'm upgrading to a new version supplied by CMU that doesn't require user
intervention when things go wrong, thus making the web service more
reliable. Unfortunately, this new version has a slightly different
interface, so it's not a straight drop in replacement.
* Given access to all CMU's algorithms
* Tony has asked me to lead a bid to join the U&I CofP. Email
attached. Deadline is next week, shouldn't take too much work.
Co-conspirators are Elizabeth A and Norman.
* Upgraded the Workbench Plastic library and made some fixes

Cygwin/X - logging into remote linux machines from Windows

Logging into linux machines from Windows can be done in various ways,
such as using ssh via PuTTY. In alternative is to use Cygwin, which not
only gives you a fairly complete Linux emulation on your windows box,
but also makes it easy to use X-forwarding, and thus use remote
GUI-based applications.

Step 1) Install Cygwin. The installer will give you a choice of
packages to install. Make sure you install the x11 packages
Step 2) Start the x server by running [cygwin
installation]\usr\X11R6\bin\startxwin.bat
Step 3) From the resulting xterm window, log into the remote machine
with ssh -X (remote machine name)
Any remotely started GUI apps should now magically appear on your
Windows box.

If you get an error of the form
warning, error event received:
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 18 (X_ChangeProperty)
Atom id in failed request: 0x1b3
Serial number of failed request: 944
Current serial number in output stream: 946

when you try to start the GUI app, try using -Y instead of -X.

Increasing the memory available to Eclipse.

To increase the memory allocated to the JVM for Eclipse, edit the
eclipse.ini file in your Eclipse directory to be something like:
-vmargs -Xms40m -Xmx512m

Weekly Summary

AG@WFAU Operations
=================
* Helped test ukidss
* Suggested compression as a solution to the large metadoc file problem.
* Moved test-registry
* China-AGVO operational
Datamining
=======
* Swotting up on datamining
* Been in touch with Andrew Moore about fastem - applied for access to
software

Plastic
====
* ADASS followup
* Been in touch with Ruby people
* TKH unavailable
* Contacted Jason about site spruce up but heard nothing yet

Other
=====
* Preparing Eclipse lecture
* Setting up my Eclipse to do C++

AOB
deadline for adass manuscripts is Monday

Setting up C++ in Eclipse on Windows

Although Eclipse works most naturally as a Java IDE, it doesn't do too
badly for other languages, and has the advantage that you don't need to
learn multiple IDEs and can keep all your code together in a single
environment.
Steps in setting up C++ in Eclipse, on Windows:
* If it's not already installed, get the CDT plugin - this is available
as part of the standard Callisto bundle from the Eclipse website.
(help/software updates/find and install/add new remote site
http://download.eclipse.org/tools/cdt/releases/callisto)
* The CDT doesn't come with its own compilers etc - you'll need to
download them separately. One option is to install Cygwin, making sure
that you're ticked all the boxes to get make and gcc. Important: don't
forget to add cygwin/bin to your windows path. The problem is, that any
executables you then make will need the cygwin1.dll to be bundled with
them, which is hardly ideal.
* An alternative, mentioned in
http://wiki.fredlackey.com/pmwiki.php?n=HelpfulInfo.DevelopmentEclipseCppCofnig
and others is to install MinGW from
http://prdownloads.sourceforge.net/mingw/MinGW-5.0.3.exe?download which
will produce exes with no dependencies. Again, make sure it's on your path.
* Managed vs Standard projects. If you create a managed project then
Eclipse will generate a simple makefile for you, otherwise you are
expected to create a makefile yourself, and will spend many happy hours
hitting the "build" button and wondering why nothing happens.

xml-rpc from C++ on Windows pt I

As part of the Plastic http://plastic.sourceforge.net project I'm
looking at making xml-rpc calls from different languages. Current focus
is on C/C++ since it opens up the possibility of using SWIG to get
Plastic access from a large range of other languages "for free".

My setup:
OS: Windows XP
IDE: Eclipse, with the CDT plugin
Tools: g++ and make, as part of the MinGW and MSYS systems

The most promising xml-rpc library is this one:
http://xmlrpcpp.sourceforge.net/links.html. Promising because a) I've
got it working before b) It has no dependencies c) It does client and
server (necessary for a fully-fledged plastic application).

Steps
1) Download and install the xml-rpc library files into a suitable folder.
2) Add this folder to the list of source folders in project
properties/c++ build/Tool settings/compiler/directories
3) Add the _WINDOWS flag to the compiler/preprocessor
If you hit build now, you'll get linker errors as listed below. The
problem is that although you get the winsock header files included on
the path automatically, you need to explicitly specify the corresponding
library to the linker. The library in question is probably called
something like: libws2_32.a and can be found in the MinGW/lib folder.
4) project properties/c++ build/Tool settings/linker/libraries/ add
library ..... and here's the real doozy....you add ws2_32 (!!!not!!!
libws2_32.a .... the linker prepends the lib and adds the .a for you).

Hit build, and you're away. All the above assumes that you have already
written your xml-rpc client of course....

=================================================================
The linker errors (for google's benefit):
E:/jdt/data/experiments/PlasticListener2/Debug/../xmlrpc/XmlRpcSocket.cpp:45:
undefined reference to `WSAStartup@8'
./xmlrpc/XmlRpcSocket.o(.text+0x5d): In function
`ZN6XmlRpc12XmlRpcSocket6socketEv':
E:/jdt/data/experiments/PlasticListener2/Debug/../xmlrpc/XmlRpcSocket.cpp:80:
undefined reference to `socket@12'
./xmlrpc/XmlRpcSocket.o(.text+0x8e): In function
`ZN6XmlRpc12XmlRpcSocket5closeEi':
E:/jdt/data/experiments/PlasticListener2/Debug/../xmlrpc/XmlRpcSocket.cpp:89:
undefined reference to `closesocket@4'
./xmlrpc/XmlRpcSocket.o(.text+0xbc): In function
`ZN6XmlRpc12XmlRpcSocket14setNonBlockingEi':
E:/jdt/data/experiments/PlasticListener2/Debug/../xmlrpc/XmlRpcSocket.cpp:103:
undefined reference to `ioctlsocket@12'
./xmlrpc/XmlRpcSocket.o(.text+0x10b): In function
`ZN6XmlRpc12XmlRpcSocket12setReuseAddrEi':
E:/jdt/data/experiments/PlasticListener2/Debug/../xmlrpc/XmlRpcSocket.cpp:115:
undefined reference to `setsockopt@20'
./xmlrpc/XmlRpcSocket.o(.text+0x157): In function
`ZN6XmlRpc12XmlRpcSocket4bindEii':
E:/jdt/data/experiments/PlasticListener2/Debug/../xmlrpc/XmlRpcSocket.cpp:126:
undefined reference to `htonl@4'
./xmlrpc/XmlRpcSocket.o(.text+0x16b):E:/jdt/data/experiments/PlasticListener2/Debug/../xmlrpc/XmlRpcSocket.cpp:127:
undefined reference to `htons@4'
./xmlrpc/XmlRpcSocket.o(.text+0x18c):E:/jdt/data/experiments/PlasticListener2/Debug/../xmlrpc/XmlRpcSocket.cpp:128:
undefined reference to `bind@12'
./xmlrpc/XmlRpcSocket.o(.text+0x1bc): In function
`ZN6XmlRpc12XmlRpcSocket6listenEii':
E:/jdt/data/experiments/PlasticListener2/Debug/../xmlrpc/XmlRpcSocket.cpp:136:
undefined reference to `listen@8'
./xmlrpc/XmlRpcSocket.o(.text+0x1fa): In function
`ZN6XmlRpc12XmlRpcSocket6acceptEi':
E:/jdt/data/experiments/PlasticListener2/Debug/../xmlrpc/XmlRpcSocket.cpp:151:
undefined reference to `accept@12'
./xmlrpc/XmlRpcSocket.o(.text+0x23a): In function
`ZN6XmlRpc12XmlRpcSocket7connectEiRSsi':
E:/jdt/data/experiments/PlasticListener2/Debug/../xmlrpc/XmlRpcSocket.cpp:164:
undefined reference to `gethostbyname@4'
./xmlrpc/XmlRpcSocket.o(.text+0x290):E:/jdt/data/experiments/PlasticListener2/Debug/../xmlrpc/XmlRpcSocket.cpp:169:
undefined reference to `htons@4'
./xmlrpc/XmlRpcSocket.o(.text+0x2b1):E:/jdt/data/experiments/PlasticListener2/Debug/../xmlrpc/XmlRpcSocket.cpp:173:
undefined reference to `connect@12'
./xmlrpc/XmlRpcSocket.o(.text+0x383): In function
`ZN6XmlRpc12XmlRpcSocket6nbReadEiRSsPb':
E:/jdt/data/experiments/PlasticListener2/Debug/../xmlrpc/XmlRpcSocket.cpp:191:
undefined reference to `recv@16'
./xmlrpc/XmlRpcSocket.o(.text+0x49e): In function
`ZN6XmlRpc12XmlRpcSocket7nbWriteEiRSsPi':
E:/jdt/data/experiments/PlasticListener2/Debug/../xmlrpc/XmlRpcSocket.cpp:223:
undefined reference to `send@16'
./xmlrpc/XmlRpcSocket.o(.text+0x517): In function
`ZN6XmlRpc12XmlRpcSocket8getErrorEv':
E:/jdt/data/experiments/PlasticListener2/Debug/../xmlrpc/XmlRpcSocket.cpp:248:
undefined reference to `WSAGetLastError@0'

--
------------------------------------------------------------------------
AstroGrid/VOTech
&
WFAU, Institute for Astronomy, Edinburgh
Skype:johndavidtaylor <skype:johndavidtaylor?chat>

------------------------------------------------------------------------
*Gratuitous advertising:*
Plastic - http://plastic.sourceforge.net | AstroRuntime -
http://www2.astrogrid.org/desktop
AstroGrid - http://www.astrogrid.org | WFAU -
http://www.roe.ac.uk/ifa/wfau/

Weekly Summary 1/11/06

• Debate about coverage in registry and possible solutions
• Visit to Cambridge to cover Taverna
• Link to Guy's summary
• Side debate on merits of SourceForge over managing our own code
• Discovered that with the exception of 2MASS, our cone searches aren't showing in AstroScope - should do soon following redeploy
  
• Discovered many missing services from AstroGrid's registry...Kevin fixing....
  
• Swotting up on Data Mining
• Downloaded VOTechBroker
• Following up ADASS

Weasl - Wfau Edinburgh Astro Service Locator

At the last IVOA meeting in Russia, David Schade argued that "position
is the least important attribute of an object". He was talking about
astronomical objects of course, but it's probably true of VO services
too. Nevertheless, I wrote this:

http://thor.roe.ac.uk/weasl/index.html

It's built from the Astro Server Runtime, a google map, a GeoEncoder
service and some sticky tape.

It's not particularly slick at the moment - the server just writes out a webpage with all the javascript required to place the points on the map. It would be far better to make it more AJAXy and have the webpage request the points. Could make it a lot more dynamic then.

Gotchas
=======
None really. The ASR made it very easy, and Google is, of course, wonderful.
Registry Access
---------------
All done through the ASR. The trick was to check the type of all the returned Resources to see if it's a Service. Only then do you get access to the attributes you need.
Goole Map
---------
The map javascript is pretty good, though it gets a bit unresponsive above a hundred or so points. One gotcha is that the <div> that contains the
map worked fine as
<div id="map" height="" width=""></div>
but if you compressed the tag into
<div id="map" height="" width=""/>
the browser nested any following divs inside it, with hilarious consequences.

Getting Java Server Pages up and running in Tomcat

Trying to get JSF up and running to use as a front end to WEASL (coming
soon). Huge problems with missing classes when running the latest JSF
(1.2) in Tomcat 5.0.28, so fallen back to 1.1. Apparently 1.2 requires
a version of JSP that Tomcat doesn't yet support. Trying out the
examples in Core JSF (http://www.horstmann.com/corejsf/)
but got an NPE;
27-Oct-2006 00:30:41 org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Allocate exception for servlet Faces Servlet
java.lang.NullPointerException
at javax.faces.webapp.FacesServlet.init(FacesServlet.java:165)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:757)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:130)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)

The solution to this is simply to remove the working directory from
under Tomcat and restart the webapp. All will then be well.

Two weekly summary

* ADASS
* 6DF database problem (see bugzilla
http://www.astrogrid.org/bugzilla/show_bug.cgi?id=1913)
* Upgraded Plastic library in AstroWeka, got the code into SVN and fixed
the Ant build script
--
------------------------------------------------------------------------
AstroGrid/VOTech
&
WFAU, Institute for Astronomy, Edinburgh
Skype:johndavidtaylor <skype:johndavidtaylor?chat>

------------------------------------------------------------------------
*Gratuitous advertising:*
Plastic - http://plastic.sourceforge.net | AstroRuntime -
http://www2.astrogrid.org/desktop
AstroGrid - http://www.astrogrid.org | WFAU -
http://www.roe.ac.uk/ifa/wfau/

(Two) Weekly Summary 11/10/06

* Started trying to collate all the apps we do in DS6 here:
http://wiki.eurovotech.org/twiki/bin/view/VOTech/DS6Software and
chivvy people along into having a proper release process.
* Looked at Maven 2.1-SNAPSHOT in the hope that it has solved the many
bugs in Maven 2.0.4 that are stopping me getting _my_ software into shape
* Maven is still a disaster for site generation. Refactored the Plastic
site to remove as many subprojects as possible in the hope that this
will help.
* In depth look at Mirage
* Installed STILTS-1.3 and got authorityId changed to Starlink, which we
manage here at ROE.
* Checked all our dbs except usnob, conesearch and adql through workbench.
* Created bugzilla entries for all our components to keep on top of
issues. See
http://www.astrogrid.org/bugzilla/editproducts.cgi?action=edit&product=WFAU
* Released PAM - the Plastic Application Monitor plastic.sourceforge.net/tupperware/plastic-application-monitor/
* Continued drafting Plastic Note
* ADASS preparation.

Maven site generation still buggered

I'd hoped that some of the issues with maven site generation
http://jontayler.wordpress.com/2006/07/26/porting-the-plastic-site-over-to-maven-2/
might be fixed by now. There seems to be no hurry to release the next
version of Maven
(see http://www.mail-archive.com/users@maven.apache.org/msg51783.html)
so I ventured into bleeding-edge territory and downloaded the latest
SNAPSHOT from
http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/

Neither the site:staging bug nor the
windows-maven-site-ignores-settings.xml bug appear fixed. Admittedly,
these are bugs in plugins, rather than the core, so perhaps I just need
to force it to use the latest plugins. How hard can that be?

--

It's reassuring that I'm not the only one losing patience with the whole Maven endeavour:
http://www.ctoforaday.com/archives/000050.html

Recursive IFRAME IIb

Even trying to use two pages to do the recursion doesn't fool Firefox.

Recursive IFRAME II

IFrames

Inspired by this:
http://communitygrids.blogspot.com/2006_03_01_communitygrids_archive.html
which is an interesting blog in its own right. I was tempted to see if you can do a recursive IFrame.




Quite sensibly - Firefox spots the recursion and just presents a white box.

Animated GIFS for WFAU

Mark has been working on some rather neat animated GIFS for WFAU. Hope to embed these in our registry entries - that should blow CASU off the page in AstroScope.
http://eurovotech.org/wfau/logos/wfau_logos.htm

Will get similar done for Plastic....

Evaluating Skype's security

http://www.skype.com/security/files/2005-031%20security%20evaluation.pdf