Push not permitted at Github

I like to use EGit to manage my Git repositories. EGit is the Eclipse Git tooling.
I find it much more convenient than the command line.

This afternoon, I created a new organization at Github, with new repositories. However, I encountered a problem when I tried to push my modifications. A dialog showed up in Eclipse, with an error message ending with “Push not permitted”.

I double-checked my configuration and found no error.
I eventually tried a git push in the command line. It gave a more detailed error message. In fact, Github changed the way it manages SSH keys. The SSH key I was using had been created by myself a long time ago, and in a third-application. The shell indicated an URL to follow at Github to authorize my key to be used within the new organization.

It fixed the problem.
It was also possible to allow this new organization to use third-party SSH keys. This error would then have not ocurred.

Validating a HTML page with Java

Hi,

This is a quick article to give you some hints about validating HTML pages in Java.
I first found JCabi’s library to validate documents against the W3C validators. This library submits a HTML document to the online W3C validator. However, I got several issues to make it work. I could fix some of them, but not all. My unit tests were working in Eclipse, but not in Maven. And depending on the JDK I was using, it was not always working (some errors with XPath factories).

I then found an open source projet on GitHub, w3cValidator.
It looked promising, but there was an ambiguity with the license. Besides, I realized it was not a good idea to validate automatically too many pages on the online W3C validator. I then checked how I could install locally a W3C validator. If I succeeded in installing it on Ubuntu, it was only after a lot of efforts. To be realistic, it was not possible to automate such an installation on Travis CI. So, I definitely dropped the idea of relying on W3C validators. I had to find some library.

I tried JTidy, but I found it quite limited. It was validating things that were valid XML but invalid HTML.

I eventually discovered Nu HTML checker.
This project describes itself as follows…

The Nu Html Checker (v.Nu) is a name for the backend of html5.validator.nu, validator.w3.org/nu, and the HTML5 facet of the legacy W3C Validator.

It is Java. It is available in Maven repositories. And no license issue for my project. It looked great, except there is no documentation about how to use it as a library. Instead, it aims at being used as a stand-alone Java process.

I could have used the project’s main class to validate my HTML pages, but it is full of System.exit() statements. So, not a good idea. By digging the classes, I finally extracted some piece of code to use it. You can find it in this Gist.

I duplicated it here, in this article.
First, update your POM will the following dependency.

<dependency>
	<groupId>nu.validator</groupId>
	<artifactId>validator</artifactId>
	<version>15.3.14</version>
	<scope>test</scope>
	<exclusions>
		<exclusion>
			<groupId>org.eclipse.jetty</groupId>
			<artifactId>*</artifactId>
		</exclusion>
	</exclusions>
</dependency>

And here is a Java snippet to validate the content of a HTML page.

/**
 * Verifies that a HTML content is valid.
 * @param htmlContent the HTML content
 * @return true if it is valid, false otherwise
 * @throws Exception
 */
public boolean validateHtml( String htmlContent ) throws Exception {

	InputStream in = new ByteArrayInputStream( htmlContent.getBytes( "UTF-8" ));
	ByteArrayOutputStream out = new ByteArrayOutputStream();

	SourceCode sourceCode = new SourceCode();
	ImageCollector imageCollector = new ImageCollector(sourceCode);
	boolean showSource = false;
	MessageEmitter emitter = new TextMessageEmitter( out, false );
	MessageEmitterAdapter errorHandler = new MessageEmitterAdapter( sourceCode, showSource, imageCollector, 0, false, emitter );
	errorHandler.setErrorsOnly( true );

	SimpleDocumentValidator validator = new SimpleDocumentValidator();
	validator.setUpMainSchema( "http://s.validator.nu/html5-rdfalite.rnc", new SystemErrErrorHandler());
	validator.setUpValidatorAndParsers( errorHandler, true, false );
	validator.checkHtmlInputSource( new InputSource( in ));

	return 0 == errorHandler.getErrors();
}

And it works.

I also thought about a last option this monrning.
Now that I found the Nu checker, I will not change for it, but I think it could work too. It relies on using the JDK validator. Validating a HTML page can be done by validating the XML against the HTML’s XML schema. In some way, I think it is what JTidy does, but I am not sure.

Anyway, I hope this article will have brought some ideas to you.

Probes conflicts with PAX-Exam 4

Edit: this bug is even worst than what I was thinking.
The explaination below is incomplete. The bug occurred randomly. And probe names were a wrong lead. In fact, I have a race condition when loading bundles. I limited its impact by defining an Import-Package header in my probe.

// Force the use of the AgentMessagingInterface from the agent's bundle.
probe.setHeader( "Import-Package", "net.roboconf.agent" );

It imports the package that was conflicting. This way, I am sure my probe does not inject its own version of the package. But still, this is a very curious bug.

Here is the original post…

I have just lived an unexpected thing while adding a new integration test on Roboconf. “Just lived” is a little bit exagerated. I spent two hours to understand and try to solve it. Anyway, these tests are run with PAX-Exam 4. They allow us to verify our OSGi bundles work as expected in an OSGi environment.

So, here is what happened.
I have one test called AgentInitializationTest. And I added DelayedAgentInitializationTest. Run individually in Eclipse, they both worked. Run in a single row with Maven, the last one was failing.

I had an @Inject annotation which was failing.
There was an IllegalArgumentException thrown by Field.java:741. I did not understand why I had this. I tested a workaround by injecting the bundle context and retrieving my service reference by hand. But I still had errors when casting my service to its interface.

ServiceReference serviceReference = context.getServiceReference( AgentInterface.class );
AgentInterface itf = (AgentInterface) context.getService( serviceReference );

That was not working, while context.getService() returned an instance of AgentInterface. As reminded on Oracle’s web site, there are two reasons for such a thing to happen. Either both objects have no relation (which is not the case here, one implements the other), or theirs definitions come from different class loaders.

And indeed: my service and its interface came from different class loaders. The Agent class was exported by its bundle whereas the AgentInterface interface was exported by a PAX-Exam probe. This was not normal at all, since my new test was not adding agent classes in its probe. Said differently, both tests had different probes configurations. Besides, my tests were all annotated with the PerMethod reactor strategy to isolate my tests.

Eventually, I @ignored AgentInitializationTest and run my tests with Maven. Miracle, DelayedAgentInitializationTest was now working. I eventually renamed my new test in AgentWithDelayedInitializationTest and now, everything is working fine.

Clearly, the probe from a previous test was injected into my new test. And this is most likely related to the test names. My intuition is that if they are wrongly chosen, there can be conflicts in probes injection. So, if you encounter the same issue one day, just make sure all your tests have different names and that no one prefixes another test name.