tag:blogger.com,1999:blog-89188500535175433372024-03-13T03:12:14.838+01:00Carlo's BlogMy personal thoughts.Anonymoushttp://www.blogger.com/profile/09487362803560166542noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-8918850053517543337.post-90807744385957156462010-08-19T17:42:00.002+02:002010-08-19T18:01:04.490+02:00Unwrap your LVM partitionToday I ran out of disk space on my root partition. Since I still had some disk space left my hard disk I booted up GParted Live-CD to start resizing. Unfortunately this is not possible with a LVM partition (which is default on Fedora). Personally I think this is a bit of a bummer.<br /><br />Although LVM only has a very small overhead with remapping requests to the right sector, I would rather have an ext partition on my laptop. It serves little purpose to split up mount points over a lot of logical volumes (don't want/need live volume management).<br /><br />Since the physical volume contains only one volume group with only one logical volume I thought let's unwrap the ext3 filesystem hidden in there.<br /><br />Note: make backups first and verify them, because this procedure hacks a new partition offset.<br /><br />Because LVM is only a remapping of requests to the right sector, the data itself is on a regular ext3 filesystem. If your logical volume is splattered across multiple extents the ext3 is no longer continuous, abort at this point. For multiple logical volumes, all with 1 extent, the procedure could work as long as everything fits in a msdos partition table.<br /><br />With the assumption of just 1 logical volume and 1 extent it's easy to find the start of the ext3 filesystem by doing: pvs -o+pe_start. This will show a column '1st PE'. That's where your ext3 filesystem is. For me it said '192.00K', with a block size of 512 bytes this would put the offset at 384 blocks.<br /><br />Now go into fdisk and enter the expert menu. You now have the option to change the beginning of data on the lvm partition. Add the offset to the block number and change the partition type to Linux. After saving the partition you'll have a working ext3 partition instead of lvm.Anonymoushttp://www.blogger.com/profile/09487362803560166542noreply@blogger.com0tag:blogger.com,1999:blog-8918850053517543337.post-85832629749898689962010-04-27T09:37:00.003+02:002010-04-27T09:46:11.062+02:00Don't hide the key under a rockThis project is about a little critique I have on the mini guide for Maven password encryption.<br /><br /><a href="http://maven.apache.org/guides/mini/guide-encryption.html">http://maven.apache.org/guides/mini/guide-encryption.html</a><br /><br />The guide under-states the security ramification of these measures. Which I think should be explicitly stated for a reader to attain the desired effect.<br /><br />The article should stress that the 'encrypted' master password must be stored on a removable drive to attain a secure environment.<br /><br />Why do I put encrypted within quotes? Because fact of the matter is that the master password is not encrypted, but simply encoded.<br /><pre> @Test<br /> public void test1() throws Exception<br /> {<br /> String master = "{WR51wo2sI1QHlQM0MhI7AULqJXRZvtoppQsqdg74p08=}";<br /><br /> DefaultPlexusCipher cipher = new DefaultPlexusCipher();<br /><br /> String result = cipher.decryptDecorated(master, "settings.security");<br /> assertEquals("Doh!", result);<br /> }</pre><br />This means that putting the master password in .m2/settings-security.xml would make your server password perfectly readable again.<br /><pre> @Test<br /> public void test2() throws Exception<br /> {<br /> String master = "Doh!";<br /> String pwd = "{fB3b7bF6RKUHOTcOH790i8jm4C4fIBM4BZ5UvXSTODk=}";<br /><br /> DefaultPlexusCipher cipher = new DefaultPlexusCipher();<br /><br /> String result = cipher.decryptDecorated(pwd, master);<br /> assertEquals("Eeek!", result);<br /> }</pre><br />So without introducing an external factor (like an USB key) the mechanism is just as secure as your plain password in .m2/settings.xml.<br /><br />To try this out on your own passwords, simply clone <br />git://github.com/wolfc/plexus-cipher-test.git [1], mvn assembly:assembly and do:<br /><pre>$ java -jar target/jboss-plexus-cipher-test-full.jar {WR51wo2sI1QHlQM0MhI7AULqJXRZvtoppQsqdg74p08=}<br />$ java -jar target/jboss-plexus-cipher-test-full.jar {fB3b7bF6RKUHOTcOH790i8jm4C4fIBM4BZ5UvXSTODk=} Doh\!</pre><br />In short: take the rock with you (in which case you don't need the rock anyway ;-) ).<br /><br />[1] <a href="http://github.com/wolfc/plexus-cipher-test">http://github.com/wolfc/plexus-cipher-test</a>Anonymoushttp://www.blogger.com/profile/09487362803560166542noreply@blogger.com0tag:blogger.com,1999:blog-8918850053517543337.post-76379616401719303642010-02-12T15:49:00.004+01:002010-02-12T15:58:21.933+01:00E.T. phone homeUsing some extra facilities it should be possible to call EJBs deployed on JBoss 4 from JBoss 5 (or calling 5 from 6, and even calling WebSphere from JBoss). The end result should be: <pre>InitialContext ctx = new InitialContext();<br />GreeterRemote bean = (GreeterRemote) ctx.lookup("java:externalContext/Greeter");<br />String result = bean.sayHi("testPositive");</pre>Now the first step should be to be able to have complete isolation of the outgoing calls, so that any existing class in the application server doesn’t collide with any client class.<br /><br /><pre>// we want the client classes of the receiving application server<br />URL clientUrl = new URL(jbossHomeDir.toURI().toURL(), "client/jbossall-client.jar");<br />// don't set a parent, so we run in complete isolation.<br />URLClassLoader urlCl = new URLClassLoader(urls, null);<br />// since we're running in isolation my own interface needs to be added.<br />ClassLoader cl = new AluniteClassLoader(urlCl, ClassLoader.getSystemClassLoader());<br />ClassLoader previous = Thread.currentThread().getContextClassLoader();<br />Thread.currentThread().setContextClassLoader(cl);<br />try<br />{<br /> InitialContext ctx = new InitialContext();<br /> GreeterRemote bean = (GreeterRemote) ctx.lookup("Greeter");<br /> String result = bean.sayHi("testPositive");<br /> assertEquals("Hi testPositive", result);<br />}<br />finally<br />{<br /> Thread.currentThread().setContextClassLoader(previous);<br />}</pre>The most important bit is the <a href="http://github.com/wolfc/jboss-alunite/blob/master/classloading/src/main/java/org/jboss/alunite/classloading/AluniteClassLoader.java" target="_blank">AluniteClassLoader</a> which has no parent class loader and delegates to the given class loaders in turn. Thus can the above code work out.<br /><br />As Jaikiran correctly pointed out, the current bean proxy needs to be called within the correct context class loader. So we would also need a specialized external context which return wrappers to allow setting the thread context class loader at the right moment.<br /><br />Lastly it needs code to correctly setup and install the external context in the local JNDI.<br /><br />The code so far can be found <a href="http://github.com/wolfc/jboss-alunite" target="_blank">here</a>.Anonymoushttp://www.blogger.com/profile/09487362803560166542noreply@blogger.com5tag:blogger.com,1999:blog-8918850053517543337.post-63987229887924452662010-01-20T10:12:00.002+01:002010-01-20T10:20:26.881+01:00Visualizing code changesVisualizing data can be an effective way to spot things that are usually hidden behind the scenes.<br /><br />In that respect I like to visualize code in different ways and with Gource we have one way to visualize code changes. So using '<a href="http://www.jboss.org/feeds/post/animating_jboss_projects_with_gource">Animating JBoss projects with Gource</a>' as a guide I made the following video:<br /><br /><object height="344" width="425"><param name="movie" value="http://www.youtube.com/v/w1q-vtcYYWE&hl=en_US&fs=1&"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed src="http://www.youtube.com/v/w1q-vtcYYWE&hl=en_US&fs=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" height="344" width="425"></embed></object><br /><br />Although it's a beautiful video, I fail to find any data points in it that might be useful.<br /><br />But maybe after you've seen the video you can spot some?Anonymoushttp://www.blogger.com/profile/09487362803560166542noreply@blogger.com0tag:blogger.com,1999:blog-8918850053517543337.post-74577078497391983562009-11-25T13:49:00.003+01:002009-11-25T13:54:16.392+01:00My shell keeps quitingSo I was writing a little shell script to setup some environment variables and out of habit it became:<br /><pre>#!/bin/bash<br />set -e<br />export X=Y</pre>First mistake: to take in environment variables from a script I need to include it, not execute it. But whatever and moved on. And did the inclusion.<br /><br />All of a sudden whenever a command return an error my shell would terminate.<br /><br />Yep, second mistake (very silly) by including I had set my shell options to exit on error.<br /><br />Ah well, it brought a smile to face. ;-)Anonymoushttp://www.blogger.com/profile/09487362803560166542noreply@blogger.com0tag:blogger.com,1999:blog-8918850053517543337.post-91454253639055337412009-11-16T11:08:00.002+01:002009-11-16T11:48:35.928+01:00Maven parent snapshotAnother case where Maven just won't listen to me. This time I want to release an artifact which has a snapshot parent dependency.<br /><pre> <parent><br /> <groupId>org.jboss.jpa</groupId><br /> <artifactId>jboss-jpa-build</artifactId><br /> <relativePath>../build/pom.xml</relativePath><br /> <version>1.0.1-SNAPSHOT</version><br /> </parent></pre><br />So first of all, why have the snapshot?<br />Because I want to have continuous integration runs on my Hudson instance.<br /><br />Now I want to change the snapshot during release to 1.0.1. This is slightly bending the previous requirement where I want CI to happen. The reason is that during the lifetime of this component jboss-jpa-build will continue to evolve, while this component might remain static. So after some time this component will have a dependency on a stale snapshot. (I really want to have [0,) or latest.integration, but that's another story.)<br /><pre>$ mvn -DdryRun=true release:prepare<br />[INFO] Scanning for projects...<br />[INFO] Searching repository for plugin with prefix: 'release'.<br />WAGON_VERSION: 1.0-beta-2<br />[INFO] ------------------------------------------------------------------------<br />[INFO] Building JBoss Container Managed JPA Deployers<br />[INFO] task-segment: [release:prepare] (aggregator-style)<br />[INFO] ------------------------------------------------------------------------<br />[INFO] [release:prepare]<br />[INFO] Verifying that there are no local modifications...<br />[INFO] Executing: svn --non-interactive status<br />[INFO] Working directory: /tmp/deployers<br />[INFO] Checking dependencies and plugins for snapshots ...<br />There are still some remaining snapshot dependencies.: Do you want to resolve them now? (yes/no) no: : <b>yes</b><br />Dependency type to resolve,: specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: : <i>enter</i><br />Resolve Project Dependency Snapshots.: 'org.jboss.jpa:jboss-jpa-build' set to release? (yes/no) yes: : <i>enter</i><br />What is the next development version? (1.0.2-SNAPSHOT) 1.0.2-SNAPSHOT: : <b>1.0.1</b><br /><br />What is the next development version? (1.0.2-SNAPSHOT) 1.0.2-SNAPSHOT: : </pre>Snif...<br />Okay, let it ride until the end by specifying the default versions. Now we can change release.properties to match what we want:<br /><pre>dependency.dependency.org.jboss.jpa\:jboss-jpa-build.development=<b>1.0.1</b></pre><br />And tell the release plugin to restart: <pre>completedPhase=<b>map-development-versions</b></pre>Then execute <pre>mvn -DdryRun=true release:prepare</pre> again.<br /><br />And come to the conclusion that we encounter a bug <a href="http://jira.codehaus.org/browse/MRELEASE-449">http://jira.codehaus.org/browse/MRELEASE-449</a>.Anonymoushttp://www.blogger.com/profile/09487362803560166542noreply@blogger.com0tag:blogger.com,1999:blog-8918850053517543337.post-63215642912381809972009-11-09T13:40:00.001+01:002009-11-09T13:42:13.730+01:00Error writing workspace state fileTodays maven problem is a m2eclipse problem. Somehow I get 'Error writing workspace state file' which leaves me in a workspace which doesn't properly update anymore.<br /><br /><pre>org.eclipse.core.runtime.CoreException: Could not read maven project<br /> at org.maven.ide.eclipse.internal.project.MavenProjectFacade.getMavenProject(MavenProjectFacade.java:190)<br /> at org.maven.ide.eclipse.internal.project.WorkspaceStateWriter.mavenProjectChanged(WorkspaceStateWriter.java:52)<br /> at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.notifyProjectChangeListeners(MavenProjectManagerImpl.java:698)<br /> at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.refresh(MavenProjectManagerImpl.java:366)<br /> at org.maven.ide.eclipse.internal.project.MavenProjectManagerRefreshJob.run(MavenProjectManagerRefreshJob.java:95)<br /> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)<br />Contains: Cannot resolve pre-scanned extension artifact: org.apache.maven.wagon:wagon-scm: Failed to resolve extension: org.apache.maven.wagon:wagon-scm:jar:1.0-beta-6<br />org.apache.maven.extension.ExtensionScanningException: Cannot resolve pre-scanned extension artifact: org.apache.maven.wagon:wagon-scm: Failed to resolve extension: org.apache.maven.wagon:wagon-scm:jar:1.0-beta-6<br /> at org.apache.maven.extension.DefaultBuildExtensionScanner.checkModelBuildForExtensions(DefaultBuildExtensionScanner.java:369)<br /> at org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(DefaultBuildExtensionScanner.java:187)<br /> at org.apache.maven.extension.DefaultBuildExtensionScanner.scanForBuildExtensions(DefaultBuildExtensionScanner.java:120)<br /> at org.apache.maven.embedder.MavenEmbedder.readProject(MavenEmbedder.java:377)<br /> at org.apache.maven.embedder.MavenEmbedder.readProjectWithDependencies_aroundBody0(MavenEmbedder.java:416)<br /> at org.apache.maven.embedder.MavenEmbedder.readProjectWithDependencies_aroundBody1$advice(MavenEmbedder.java:304)<br /> at org.apache.maven.embedder.MavenEmbedder.readProjectWithDependencies(MavenEmbedder.java:1)<br /> at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl$MavenProjectReader.execute(MavenProjectManagerImpl.java:1117)<br /> at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.execute(MavenProjectManagerImpl.java:986)<br /> at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.readProjectWithDependencies(MavenProjectManagerImpl.java:967)<br /> at org.maven.ide.eclipse.internal.project.MavenProjectFacade.getMavenProject(MavenProjectFacade.java:180)<br /> at org.maven.ide.eclipse.internal.project.WorkspaceStateWriter.mavenProjectChanged(WorkspaceStateWriter.java:52)<br /> at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.notifyProjectChangeListeners(MavenProjectManagerImpl.java:698)<br /> at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.refresh(MavenProjectManagerImpl.java:366)<br /> at org.maven.ide.eclipse.internal.project.MavenProjectManagerRefreshJob.run(MavenProjectManagerRefreshJob.java:95)<br /> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)<br />Caused by: org.apache.maven.extension.ExtensionManagerException: Failed to resolve extension: org.apache.maven.wagon:wagon-scm:jar:1.0-beta-6<br /> at org.apache.maven.extension.DefaultExtensionManager.init$_aroundBody2(DefaultExtensionManager.java:352)<br /> at org.apache.maven.extension.DefaultExtensionManager.init$_aroundBody3$advice(DefaultExtensionManager.java:384)<br /> at org.apache.maven.extension.DefaultExtensionManager.addExtension(DefaultExtensionManager.java:352)<br /> at org.apache.maven.extension.DefaultExtensionManager.addExtension(DefaultExtensionManager.java:148)<br /> at org.apache.maven.extension.DefaultBuildExtensionScanner.checkModelBuildForExtensions(DefaultBuildExtensionScanner.java:365)<br /> ... 15 more<br /></pre>Anonymoushttp://www.blogger.com/profile/09487362803560166542noreply@blogger.com1tag:blogger.com,1999:blog-8918850053517543337.post-28659571979820715192009-10-30T12:15:00.002+01:002009-10-30T13:10:10.788+01:00Constraint violated, transaction rolled backWhen using bean validation on JPA entities within an EJB 3 bean you would actually get an EJBTransactionRolledbackException if there is a constraint violation.<pre>javax.ejb.EJBTransactionRolledbackException: Invalid object at persist time for groups [javax.validation.groups.Default, ]<br />Caused by: javax.validation.ConstraintViolationException: Invalid object at persist time for groups [javax.validation.groups.Default, ]</pre>This is all nicely according to specification, but not really interesting information. You don't really want to know what happened, you want to know what went wrong.<br /><br />So I recommend adding the following to your ejb-jar.xml:<pre><?xml version="1.0" encoding="UTF-8"?><br /><ejb-jar<br /> xmlns="http://java.sun.com/xml/ns/javaee"<br /> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<br /> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee<br /> http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"<br /> version="3.0"><br /> <assembly-descriptor><br /> <application-exception><br /> <exception-class>javax.validation.ConstraintViolationException</exception-class><br /> <rollback>true</rollback><br /> </application-exception><br /> </assembly-descriptor><br /></ejb-jar></pre>That way you can directly access your violations.Anonymoushttp://www.blogger.com/profile/09487362803560166542noreply@blogger.com0tag:blogger.com,1999:blog-8918850053517543337.post-68846469049634357942009-10-30T11:45:00.003+01:002009-10-30T12:03:48.611+01:00Exceptions should tell a storySo I was happily plumbing along to get bean validation to work in AS 5.2, when I got this client side:<br /><pre>org.jboss.serial.exception.SerializationException: Could not create instance of org.hibernate.validator.engine.ConstraintViolationImpl - org.hibernate.validator.engine.ConstraintViolationImpl<br />Caused by: java.lang.InstantiationException: org.hibernate.validator.engine.ConstraintViolationImpl</pre>For some reason jboss-serialization was looking for a default constructor, which obviously wasn't there.<br /><br />Now the most recent release showed ConstraintViolationImpl implementing Serializable, so I crossed that out as a problem. (I didn't realize at this point that I was using an old version, but that's not the point of this post. :-) )<br /><br />Using the JDK serializer gave it away:<pre>java.io.NotSerializableException: org.hibernate.validator.engine.ConstraintViolationImpl</pre>At which point it was obvious that I was using the wrong version.<br /><br />At the end of the day I only have a complaint about the exception in jboss-serialization. If it said something in lines of: "class is not serializable and has no default constructor" I would have been a happy camper.<br /><br />So the moral is: always let an exception tell a story.Anonymoushttp://www.blogger.com/profile/09487362803560166542noreply@blogger.com0tag:blogger.com,1999:blog-8918850053517543337.post-48519167779081372032009-10-27T13:51:00.005+01:002009-10-27T14:01:02.209+01:00Remember: MC == Necromancer Magic<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirTexpl7Q48sPVIs4zBLhX-Ts4NqZscySCqLiW5_CeHYH4b0_ymLdWdPT2WLGS6DL2l0qeG4PI-aAACP-B8pfCCtRFb7IKJrGpTx2I9rk8TyGWiH0fHfsnGEiCu1d3vb1WUp8FtfCVmko/s1600-h/MCBean.png"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 131px; height: 320px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirTexpl7Q48sPVIs4zBLhX-Ts4NqZscySCqLiW5_CeHYH4b0_ymLdWdPT2WLGS6DL2l0qeG4PI-aAACP-B8pfCCtRFb7IKJrGpTx2I9rk8TyGWiH0fHfsnGEiCu1d3vb1WUp8FtfCVmko/s320/MCBean.png" alt="" id="BLOGGER_PHOTO_ID_5397261813702014370" border="0" /></a>While working on EJBTHREE-1889 I stumbled right into an assumption boobytrap. In my mind I figured that a MicroContainer bean would have a state diagram as shown on the left side. In reality MC bean instances can be 'destroyed' and then 'created', because for MC it's just a state change with no additional semantics.<br /><br />"Specifically the beans named in the @Depends or <depends> values will reach their CREATE states before the bean declaring the dependencies reaches its CREATE state. The same is true for the START, STOP and DESTROY states." <a id="d0e1907">[MC 12.3]</a><br /><br />So MC <span style="font-weight: bold;">is</span> voodoo magic, it will resurrect your bean. :-)<br /></depends>Anonymoushttp://www.blogger.com/profile/09487362803560166542noreply@blogger.com0