Welcome to CODE3's Techchat
Using TDC’s Columbine with modern browsers
Published Thursday, April 14th, 2011 by ANOn columbine.tdc.dk there is a gui with tools for resellers of TDC eBSA products. These tools are crucial for interacting with the TDC systems, but unfortunately they only work in Internet Explorer right now. They seem pretty old and they made with hand-coded javascript. TDC seems to have plans to update the site to work with all browsers and if they ask me, I think they should just update the site to use a modern framework like jQuery.
I took a look at what seemed to be the problem. If I keep open the Firefox “Error Console” while browsing I see these two errors
Warning: Element referenced by ID/NAME in the global scope. Use W3C standard document.getElementById() instead.
Source File: https://columbine.tdc.dk/komik/SessionServer?code=wsess&pseudonym=wxvis
Line: 545
and
Error: MAINFORM is not a function
Source File: https://columbine.tdc.dk/komik/SessionServer?code=wsess&pseudonym=wxvis
Line: 545
Referencing by name in the global scope seems to be very old bad practice in form access. I can’t even find descriptions of it on the net. This and this are the closest mentions I can find.
Anyway, this seemed like a problem that should be easy to fix with a userscript / greasemonkey script. So I went ahead and made one and put it on github. I’ve only used it on “Vis eksisterende BB” and “Net-info” so it is only enabled for those two pages, and it might need changes to work on other pages (patches/forks welcome).
https://github.com/andersnorgaard/columbine-greasmonkey
It’s pretty simple. It uses the content script injection hack to create the required reference to “MAINFORM” in the global scope.
Enjoy.
Groovy CPE
Published Thursday, February 3rd, 2011 by ANI’ve been working quite a lot on a TR069 AutoConfigurationServer. As part of the prototyping I created a client emulator to more quickly and easily test out different parts of the TR069 spec. I called the program GroovyCPE and it can be found on Google Code hosting. Hopefully it will be useful for others in initial bringup of TR069 servers, regression testing and performance testing. The code written in Groovy and it is licensed under the GPLv3.
The TR069 schemas which can be found at http://www.broadband-forum.org/cwmp.php define the communication. Unfortunately the CWMProtocol uses ancient technology – namely XML-RPC. One can find old libraries for XML-RPC on the web, but they look old and crusty. We decided to go with JAXB ( https://jaxb.dev.java.net ) to get Java classes from the schemas. However, JAXB doesn’t seem to handle the old XML-RPC ideas perfectly, so we have to apply some band-aid (more on the server side than on the client side, though). I’ll blog about this separately.
To get the JAXB processing to work at all I have deleted fixed="1" from the soapenv:mustUnderstand attributes.
The HTTP communication of GroovyCPE is done with the help of the Apache HttpComponents v3 which is a pretty OK library for HTTP communication.
The initial configuration content in testfiles/parameters_tg784/get*.txt is from a Thomson TG784 box.
GroovyCPE is built around a central store of the parameters it reads in. And as much as possible it uses the configuration parameters it self – eg. for the ManagementServer URL and the PeriodicInformInterval.
What it can do:
- Immediately send Inform messages with all event types
- Run a thread that sends scheduled Inform messages according to the PeriodicInformInterval
- Listen for connection requests on the ConnectionRequestURL (and send an Inform if requested
- Accept a DownloadRequest and initiate an HTTP download session according to the contents
- Respond to GetParameter{Names,Values,Attributes} requests.
- Accept SetParameter{Values,Attributes} and set the values
- Accept AddObject requests and add objects (but only if the object layout is known from the configuration parameters)
I don’t have any immediate plans for improvements to GroovyCPE. At some point I will probably look at fixing the JAXB classes at generation time with a JAXB plugin.
Testing JBoss 6
Published Thursday, January 27th, 2011 by ANSo, JBoss 6.0.0 is out. And so far it looks pretty good.
Last year I was working on an JEE5 app that runs with Seam 2 and Richfaces 3.3 on JBoss 4.2. Just for fun I tried to deploy it on JBoss 6. To make it deploy cleanly I had to fix some minor things.
- Only the latest Seam 2.2.1 CR3 is advertised to run on JBoss 6. So I grabbed that.
- commons-httpclient, which I use in my app, was on my classpath on the JBoss 4.2 I used, but was missing on JBoss 6. But I just grabbed the one from the Seam /lib folder.
- My app is a .ear file with a .war file inside. And the files have the same name which makes it look something like this when exploded myapp.ear/myapp.war. JBoss 6 doesn’t seem to like this, complaining that the war has already been deployed during the deployment. Renaming the .war to myappweb.war fixed it.
As expected, startup is somewhat slower than JBoss 4.2.3 at around 21 secs to start JBoss 6 with my app deployed and 14 secs on JBoss 4.2.3.
So, to sum up; if I get the chance to do another release of the app and run it on JBoss 6 then, it is definitely possible. And I wouldn’t hesitate to do so. Taking advantage of EJB 3.1 on JBoss 6 to get rid of the silly EJB interfaces would really clean up the app.
Creating, consuming and testing SOAP webservices on Grails
Published Friday, February 12th, 2010 by ANWe are currently making a backend system, that has its services exposed as webservices. Since making web applications in Grails is pretty nice, we decided to try it for webservices.
Getting up and running was certainly a breeze.
grails create-app ...
grails install-plugin cxf
Grails is a plugin-based framework. And the cxf plugin seems to be the best plugin for webservices right now. Exposing the services was then as simple as adding a
static expose=['cxf']
to the the grails service classes. We wante to allow our service interfaces to operate with complex objects. And to do that best we decided to use the DTO plugin and specify our interfaces in terms of DTOs mostly generated from our domain objects. This was only a semi-good idea, I think, as the conversion to/from complex domain objects was not great out of the box (more on that in another post).
To consume webservices, the most straighforward way is to simply dump the minimal jar of the GroovyWS module in the lib folder of the project. Since we already had all the dependencies included by the cxf plugin the minimal jar is all that is needed.
To test the services, most of our test were simply the usual integration tests of the service classes. But for functional tests we used the functional-tests plugin and the GroovyWS client we already had installed.
class MyServiceFunctionalTests extends functionaltestplugin.FunctionalTestCase {
def myServicePort
protected void setUp() {
super.setUp();
myServicePort = new WSClient("http://localhost:9091/myservice/services/my?wsdl", this.class.classLoader)
myServicePort.initialize()
}
public void testAMethod(){
final List resultVals = myServicePort.aMethod();
assertEquals(4, resultVals.size());
}
}
It feels a bit wrong to work with old and crufty technology like SOAP with shiny new technology like Groovy on Grails. But with that in mind it works surprisingly well. Points where I found the greatest room for improvement were.
- Grails has great support for Controllers as entrypoints, with interceptors for logging and authorization. For Services this seems harder if not impossible. I haven’t succeeded in using either groovys invokeMethod or the built-in spring support for aspect-oriented-programing.
- As mentioned above, the DTO plugin could use a more flexible mapping tool than the one it has.
- With code that has no immediate GUI feedback, testing is extremely important. But the Grails test run so slow that it is annoying.
Still, would I recommend Grails for a large SOAP project. Yes, I would.
My first patch to Grails accepted
Published Monday, November 23rd, 2009 by milI recently wrote a patch for Grails to support dateCreated and lastUpdated when using mockDomain in unit tests.
This patch has now been applied to 1.2-SNAPSHOT.
http://jira.codehaus.org/browse/GRAILS-4540
The mockDomain method makes it possible to test code that uses GORMs dynamic methods, without having to use a real database.
IBM Developerworks has a great article on mock testing in Grails here.
How to debug grails run-app loop
Published Wednesday, November 11th, 2009 by milI recently had a problem where grails run-app would start
the server, then immediately recompile 1 class, then restart… and
repeat.
Google told me that the problem probably was an empty Java file in my
project and to look in the
~/.grails/1.2-M4/projects/myproject/classes directory to
see which file kept changing timestamp.
However, no files did that. The solution was to modify
$GRAILS_HOME/scripts/_GrailsCompile.groovy and add
listFiles:true to the compile target:
ant.groovyc(destdir:classesDirPath, classpathref:classpathId, encoding:"UTF-8", listFiles:true, compilerPaths.curry(classpathId, false))
And it turned out Google was right, I had a Java file with only the
package specification in it.
Console output from Grails tests
Published Thursday, September 24th, 2009 by ANFor casual testing in Grails, it would be nice to be able to just have the output of the tests dumped to the console that the tests were run from. This doesn’t seem possible in the default setup, but adding these lines
if(argsMap['no-reports']){
println testRunner.out.toString()
println testRunner.err.toString()
}
should do the trick, if you add them to $GRAILS_HOME/script/_GrailsTest.groovy in the “runTests” closure, right after ” def result = testRunner.runTests(testSuite)”
With those lines in place you can run your test like
grails -Dserver.port=9090 test-app -integration -no-reports MyController
Specifying the name of the class to test is important since only the output from the last test class will be printed. So we might as well only run one.
Dependent dropdowns in Grails
Published Friday, September 18th, 2009 by ANIt does really seem to be a very common problem with the dependend or chained drop-downs. At least it was one of the first problems I faced in the Grails app I’m working on now.
The solution is not really more or less elegant than the one for Seam and Richfaces. I followed the guide on Grails.org but decided to make the solution a bit more general. So I pass the name of the select-element-to-update as a string to the update function. This way I can also put the function in a separate file for inclusion (updateselect.js).
function updateSelect(e, elemId) {
// The response comes back as a bunch-o-JSON
var values = eval("(" + e.responseText + ")") // evaluate JSON
if (values) {
updateSelectFromJSON(values, elemId);
}
}
function updateSelectFromJSON(values, elemId) {
var rselect = document.getElementById(elemId)
// Clear all previous options
rselect.options.length = 0
// Rebuild the select
for (var i=0; i < values.length; i++) {
var opt = document.createElement('option');
opt.text = values[i].name
opt.value = values[i].id
try {
rselect.add(opt, null) // standards compliant; doesn't work in IE
} catch(ex) {
rselect.add(opt) // IE only
}
}
}
Which is then called like this
...
<form>
optionKey="id" optionValue="name" name="country.name" id="country.name" from="${Country.list()}"
onchange="${remoteFunction(
controller:'country',
action:'ajaxGetCities',
params:''id=' + escape(this.value)',
onComplete:'''updateSelect(e, 'city')''')}"
>
</form>
One thing is missing from this solution, though. Unlike the solution on grails.org, the chained select is not updated based on the default value of the previous select. This can be fixed by inserting the following in the head element of the .gsp page.
function init() {
document.cityform['country.name'].onchange();
}
window.onload = init;
Grails bash completion
Published Monday, September 7th, 2009 by ANI’ve started doing some Grails development. So far it seems great. Here are a couple of notes to start with.
Grails is not packaged officially for Ubuntu yet. And the packages that can be downloaded from grails.org don’t have bash completion. This guy however packaged grails for Debian/Ubuntu, and it include a bash completion script. The package seems to work great, and for one of my machines where I already installed grails from the usual tar.gz download, I pulled out the bash completion from the deb-package. To make it work completely with the tar.gz dowload I just had to modify the location of the grails installation (to use $GRAILS_HOME). Ahhhh.
Somewhat less useful (but fun), I also added the Ubuntu “notify-send” notification feature described here. I feel all set for Grails development.
Automated documentation and ODFDOM
Published Tuesday, July 7th, 2009 by ANEveryone hates out-of-date documentation. Unfortunately most people hate keeping documentation updated even more. So Paul Duvall has written a nice piece on developerWorks about automatically generated documentation.
The tools used in Pauls piece don’t exactly fit my project however. I use Guice, and since that can be a bit confusing it would be nice to have some overview of how Guice binds the app together. With Guice 2.0 however there is a nice Guice plugin to generate diagrams. The only problem is that the Seam/Guice integration is not updated to Guice 2.0 yet. So I guess I’ll postpone this.
An important part of any application is the data model. So I would like to have entity diagrams generated. Since I use hibernate/JPA I thought that there would be an ant task to have entity diagram generated directly. However, lots of searching on google brought me nowhere. Linguine maps would have been a solution back in the days when one used “.hbm.xml” files to configure entity classes. But noone does that anymore. So I asked a question on Stackoverflow but that didn’t help. Finally I tried a workaround that involves starting a database deploying the entities and then letting SchemaSpy generate diagrams from the database. This could definitely be more elegant.
I usually don’t program with deep or advanced class hierachies so I don’t see the point in doing inheritance graphs. Others do, however, and the tool API viz does a nice and easy job of creating them, so I might as well include that. I could presumably also have used UMLJGraph or UMLGraph (like in the developerworks article).
The really fun part begins if I were to write a small ant task that could process an ODF document with ODFDOM and automatically insert the graphs in the right place. I attended the ODFDOM hands-on-lab at JavaOne, and while the api is a bit rough now, it should actually not be too much work I think (especially if I use Groovy). I guess the first version would just replace some placeholder string in the document with the appropriate diagram. This way it should not be too difficult to use with the different documentation template documents one encounters. Poor mans LaTeX, yay! I’ll blog it when I get it running.
+++++++++++++++++++++++++++++++++++++
The AntTask for ApiViz just requires the apiviz jar file which I put in a folder “buildlib”:
<target name="javadoc"> <javadoc destdir="docs/api" author="true" version="true" use="true" windowtitle="TACS API" classpathref="class.build.path" doclet="org.jboss.apiviz.APIviz" docletpath="buildlib/apiviz-1.3.0.GA.jar" additionalparam="-author -version"> <fileset dir="src"/> </javadoc> </target>
The not very elegant integration of SchemaSpy involves the buildtarget below which starts two tasks in parallel. The top one just executes a class that programatically start an HSQLDB and then loads a datasource which points to that database. This then causes Hibernate to create the tables specified by the entity classes. When the database is started and the datasource loaded it sleeps 20 secs to allow the schemaspy task to connect. The bottom parallel task then sleeps 10 secs (to allow the datasource to load) and then runs schemaspy.
<target name="db-diagram" depends="db-start"> <parallel> <daemons> <java dir="build/classes/test" classname="TestEntityManagerProvider" fork="true"> <classpath> <pathelement location="build/classes/test"/> <path refid="class.test.path"/> </classpath> </java> </daemons> <sequential> <sleep seconds="10"/> <java jar="buildlib/schemaSpy_4.1.1.jar" output="docs/output.log" error="docs/error.log" fork="true"> <arg line="-t hsqldb"/> <arg line="-host localhost"/> <arg line="-db tacs"/> <arg line="-u sa"/> <arg line="-s PUBLIC"/> <arg line="-cp buildlib/hsqldb.jar"/> <arg line="-o docs/api"/> </java> </sequential> </parallel> </target>
public class TestEntityManagerProvider {
public static void main(String[] args) throws InterruptedException {
System.out.println("Starting hsqldb");
new Thread(new Runnable(){
public void run() {
Server s = new Server();
s.setDatabaseName(0, "tacs");
s.setDatabasePath(0, "mem:test;sql.enforce_strict_size=true");
s.start();
}
}).start();
Thread.sleep(2000);
final Map props = new HashMap();
props.put("javax.persistence.jtaDataSource", "");
final EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory("tacs-diagram", props);
final EntityManager entityManager = entityManagerFactory.createEntityManager();
entityManager.getTransaction().begin();
entityManager.persist(new Cpe());
Query q = entityManager.createQuery("from Cpe");
System.out.println("Results from cpe" + q.getResultList());
System.out.println("Sleeping 20 sec");
Thread.sleep(200000 );
System.out.println("Done sleeping");
}
}
Using TDC’s Columbine with modern browsers
Groovy CPE
