<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Java on technocracy</title><link>https://www.ericsimmerman.com/tags/java/</link><description>Recent content in Java on technocracy</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 05 Jul 2011 00:00:00 +0000</lastBuildDate><atom:link href="https://www.ericsimmerman.com/tags/java/index.xml" rel="self" type="application/rss+xml"/><item><title>MindTouch SSO using HttpClient 4.1 with Java</title><link>https://www.ericsimmerman.com/blog/2011/07/05/mindtouch-sso-using-httpclient-4.1-with-java/</link><pubDate>Tue, 05 Jul 2011 00:00:00 +0000</pubDate><guid>https://www.ericsimmerman.com/blog/2011/07/05/mindtouch-sso-using-httpclient-4.1-with-java/</guid><description>&lt;div class='post'&gt;
&lt;p&gt;Most of the &lt;a href="http://www.mindtouch.com/"&gt;MindTouch&lt;/a&gt; sample code available in the wild is in PHP or C# so integrating with a Java stack can be painful. Here's a snip of the code we used to support SSO with our Java-based SaaS platform. The HttpClient framework is version 4.1 of &lt;a href="http://hc.apache.org/"&gt;Apache's HttpClient&lt;/a&gt;&lt;/p&gt;</description></item><item><title>Select max value of numeric CollectionOfElements with Hibernate</title><link>https://www.ericsimmerman.com/blog/2010/02/23/select-max-value-of-numeric-collectionofelements-with-hibernate/</link><pubDate>Tue, 23 Feb 2010 00:00:00 +0000</pubDate><guid>https://www.ericsimmerman.com/blog/2010/02/23/select-max-value-of-numeric-collectionofelements-with-hibernate/</guid><description>&lt;div class='post'&gt;
Consider a numeric CollectionOfElements held by a class Product such as:&lt;div class="CodeRay"&gt; &lt;div class="code"&gt;&lt;pre&gt;@Entity(name=&amp;quot;Product&amp;quot;)public class Product {protected Set serialNumbers = new HashSet();@CollectionOfElements@JoinTable(name=&amp;quot;product_serialnumbers&amp;quot;)public Set getSerialNumbers() { return serialNumbers;}public void setSerialNumbers(Set serialNumbers) { this.serialNumbers = serialNumbers;}}&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;You can use a NamedQuery to determine the maximum SerialNumber held by any Product like this:&lt;div class="CodeRay"&gt; &lt;div class="code"&gt;&lt;pre&gt;@Entity(name=&amp;quot;Product&amp;quot;)@NamedQueries ({ @NamedQuery( name = &amp;quot;maxSerialNumber&amp;quot;, query = &amp;quot;select max(elements(p.serialNumbers)) as value from Product p&amp;quot; )})public class Product {protected Set serialNumbers = new HashSet();@CollectionOfElements@JoinTable(name=&amp;quot;product_serialnumbers&amp;quot;)public Set getSerialNumbers() { return serialNumbers;}public void setSerialNumbers(Set serialNumbers) { this.serialNumbers = serialNumbers;}}&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;</description></item><item><title>Eclipse Galileo unable to read Subversion repository</title><link>https://www.ericsimmerman.com/blog/2010/01/18/eclipse-galileo-unable-to-read-subversion-repository/</link><pubDate>Mon, 18 Jan 2010 00:00:00 +0000</pubDate><guid>https://www.ericsimmerman.com/blog/2010/01/18/eclipse-galileo-unable-to-read-subversion-repository/</guid><description>&lt;div class='post'&gt;
After a clean Snow Leopard install on a new machine, I fired up a fresh Galileo Eclipse and pointed it at a copy of my old workspace.&amp;nbsp; I first encountered and resolved the missing Mac OS X JRE issue described in my last post, only to then find that my existing subversion repositories were inaccessible in the new Eclipse install. I hopefully added "-clean" as the first parameter of my eclipse.ini file and restarted but the situation remained unchanged. Undeterred, I launched eclipse from the command line with a -clean startup parameter and this did the trick:/Applications/&amp;lt;your install dir/Eclipse.app/Contents/MacOS/eclipse -clean&lt;/div&gt;</description></item><item><title>Missing MacOS X VM in Eclipse Galileo on Snow Leopard</title><link>https://www.ericsimmerman.com/blog/2010/01/18/missing-macos-x-vm-in-eclipse-galileo-on-snow-leopard/</link><pubDate>Mon, 18 Jan 2010 00:00:00 +0000</pubDate><guid>https://www.ericsimmerman.com/blog/2010/01/18/missing-macos-x-vm-in-eclipse-galileo-on-snow-leopard/</guid><description>&lt;div class='post'&gt;
I recently encountered an issue where I was unable to add a JVM to my Eclipse install on Snow Leopard. There was no MacOS X VM option under Installed JREs -&amp;gt; Add and attempting to use the Standard VM resulted in an error. After digging around in Eclipse bug reports, I discovered this is a known issue with the Cocoa build of Galileo with PDT pre-installed.&amp;nbsp; The easy fix is to install Eclipse without PDT (just install the Eclipse IDE for Java - Cocoa 64 bit) and add PDT plugin later. When you take this route, the MacOS X VM will be configured automagically.&lt;/div&gt;</description></item><item><title>Resolving a 'CA key usage check failed: keyCertSign bit is not set' error in Tomcat</title><link>https://www.ericsimmerman.com/blog/2009/10/22/resolving-a-ca-key-usage-check-failed-keycertsign-bit-is-not-set-error-in-tomcat/</link><pubDate>Thu, 22 Oct 2009 00:00:00 +0000</pubDate><guid>https://www.ericsimmerman.com/blog/2009/10/22/resolving-a-ca-key-usage-check-failed-keycertsign-bit-is-not-set-error-in-tomcat/</guid><description>&lt;div class='post'&gt;
After installing a new GoDaddy SSL certificate in Tomcat 5.5.x my web browsers were able to properly negotiate SSL connections, but when back-end code attempted (specifically when CAS attempted to validate a ticket through Cas20ServiceTicketValidator) to connect using SSL the "CA key usage check failed: keyCertSign bit is not set" error was being thrown. &lt;p /&gt;My tomcat server is fronted by Apache2 and Apache handles SSL negotiation. I discovered that I had improperly installed the intermediate certificate for GoDaddy and while modern browsers just ignored the resulting misconfiguration, Java was complaining.&lt;p /&gt;I had set the SSLCertificateChainFile directive to point to the "cert-chain.crt" file. The mistake is understandable given the near identical naming of the directive and the file...but alas that intuitive connection is erroneous. The directive instead needs to point to the gd_intermediate.crt file that GoDaddy also provides. Here's what my correct config looks like on RHEL5: &lt;p /&gt;&lt;div class="CodeRay"&gt; &lt;div class="code"&gt;&lt;pre&gt;SSLCertificateChainFile /etc/pki/tls/certs/gd_intermediate.crt&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;</description></item><item><title>Compiling mod_caucho on RHEL 5.3</title><link>https://www.ericsimmerman.com/blog/2009/09/14/compiling-mod_caucho-on-rhel-5.3/</link><pubDate>Mon, 14 Sep 2009 00:00:00 +0000</pubDate><guid>https://www.ericsimmerman.com/blog/2009/09/14/compiling-mod_caucho-on-rhel-5.3/</guid><description>&lt;div class='post'&gt;
&lt;p&gt;There is &lt;a href="http://mail-archives.apache.org/mod_mbox/apr-dev/200410.mbox/%3C20041022090014.GA9117@redhat.com%3E"&gt;a known issue with APR&lt;/a&gt; that &lt;a href="http://maillist.caucho.com/pipermail/resin-interest/2007-April/000969.html"&gt;prevents the compilation of mod_caucho on RHEL 5.3&lt;/a&gt; out of the box. Additionally, for some reason my installation of APR uses the name "apr-1-config" instead of "apr-config" so that to compile mod_caucho I had to do the following:&lt;/p&gt;</description></item><item><title>Spring Security ACL intercept-methods with transaction advice</title><link>https://www.ericsimmerman.com/blog/2009/08/13/spring-security-acl-intercept-methods-with-transaction-advice/</link><pubDate>Thu, 13 Aug 2009 00:00:00 +0000</pubDate><guid>https://www.ericsimmerman.com/blog/2009/08/13/spring-security-acl-intercept-methods-with-transaction-advice/</guid><description>&lt;div class='post'&gt;
I recently used Spring to configure a manager to use Spring Security ACL method-level authorization. Here's a snip of my initial manager bean config:&lt;div class="CodeRay"&gt; &lt;div class="code"&gt;&lt;pre&gt;&amp;lt;bean id=&amp;quot;clientManager&amp;quot; class=&amp;quot;com.acme.service.impl.ClientManagerImpl&amp;quot;&amp;gt; &amp;lt;sec:intercept-methods access-decision-manager-ref=&amp;quot;accessDecisionManager&amp;quot;&amp;gt; &amp;lt;sec:protect method=&amp;quot;get&amp;quot; access=&amp;quot;AFTER_ACL_READ&amp;quot;/&amp;gt; &amp;lt;sec:protect method=&amp;quot;save&amp;quot; access=&amp;quot;ROLE_ADMIN,ACL_WRITE&amp;quot;/&amp;gt; &amp;lt;/sec:intercept-methods&amp;gt; &amp;lt;constructor-arg ref=&amp;quot;clientDao&amp;quot;/&amp;gt; &amp;lt;property name=&amp;quot;mutableAclService&amp;quot; ref=&amp;quot;aclService&amp;quot;/&amp;gt;&amp;lt;/bean&amp;gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;With this configuration, my unit tests verified that the method-level authorization was working as expected. Next, I applied some declarative transaction management to the same manager:&lt;div class="CodeRay"&gt; &lt;div class="code"&gt;&lt;pre&gt;&amp;lt;aop:config&amp;gt; &amp;lt;aop:advisor id=&amp;quot;managerTx&amp;quot; advice-ref=&amp;quot;txAdvice&amp;quot; pointcut=&amp;quot;execution(* *..service.*Manager.*(..))&amp;quot; order=&amp;quot;0&amp;quot;/&amp;gt;&amp;lt;/aop:config&amp;gt;&amp;lt;tx:advice id=&amp;quot;txAdvice&amp;quot;&amp;gt; &amp;lt;tx:attributes&amp;gt; &amp;lt;tx:method name=&amp;quot;get*&amp;quot; read-only=&amp;quot;true&amp;quot;/&amp;gt; &amp;lt;tx:method name=&amp;quot;save*&amp;quot; rollback-for=&amp;quot;DuplicateNameException,UserExistsException&amp;quot; /&amp;gt; &amp;lt;tx:method name=&amp;quot;*&amp;quot;/&amp;gt; &amp;lt;/tx:attributes&amp;gt;&amp;lt;/tx:advice&amp;gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;After adding this transaction advice, my unit tests failed method-level authorization checks. I never traced the issue to its absolute root cause, but based upon some open tickets against Spring I believe the error was due to a "double-proxy" type issue. The short story is that proxies are final, and Spring can't proxy a proxy...&lt;p /&gt;Regardless of the root cause, I found a reasonable workaround was to revert to one of the "old" (more verbose) methods of transaction demarcation. Here's what my final working configuration looks like:&lt;div class="CodeRay"&gt; &lt;div class="code"&gt;&lt;pre&gt;&amp;lt;bean id=&amp;quot;baseTransactionProxy&amp;quot; abstract=&amp;quot;true&amp;quot; class=&amp;quot;org.springframework.transaction.interceptor.TransactionProxyFactoryBean&amp;quot;&amp;gt; &amp;lt;property name=&amp;quot;transactionManager&amp;quot; ref=&amp;quot;transactionManager&amp;quot;/&amp;gt; &amp;lt;property name=&amp;quot;transactionAttributes&amp;quot;&amp;gt; &amp;lt;props&amp;gt; &amp;lt;prop key=&amp;quot;get*&amp;quot;&amp;gt;PROPAGATION_REQUIRED,readOnly&amp;lt;/prop&amp;gt; &amp;lt;prop key=&amp;quot;save*&amp;quot;&amp;gt;PROPAGATION_REQUIRED,-DuplicateNameException,-UserExistsException&amp;lt;/prop&amp;gt; &amp;lt;prop key=&amp;quot;*&amp;quot;&amp;gt;PROPAGATION_REQUIRED&amp;lt;/prop&amp;gt; &amp;lt;/props&amp;gt; &amp;lt;/property&amp;gt;&amp;lt;/bean&amp;gt;&amp;lt;bean id=&amp;quot;clientManager&amp;quot; parent=&amp;quot;baseTransactionProxy&amp;quot;&amp;gt; &amp;lt;property name=&amp;quot;target&amp;quot;&amp;gt; &amp;lt;bean class=&amp;quot;com.acme.service.impl.ClientManagerImpl&amp;quot;&amp;gt; &amp;lt;sec:intercept-methods access-decision-manager-ref=&amp;quot;accessDecisionManager&amp;quot;&amp;gt; &amp;lt;sec:protect method=&amp;quot;get&amp;quot; access=&amp;quot;AFTER_ACL_READ&amp;quot;/&amp;gt; &amp;lt;sec:protect method=&amp;quot;save&amp;quot; access=&amp;quot;ROLE_ADMIN,ACL_WRITE&amp;quot;/&amp;gt; &amp;lt;/sec:intercept-methods&amp;gt; &amp;lt;constructor-arg ref=&amp;quot;clientDao&amp;quot;/&amp;gt; &amp;lt;property name=&amp;quot;mutableAclService&amp;quot; ref=&amp;quot;aclService&amp;quot;/&amp;gt; &amp;lt;/bean&amp;gt; &amp;lt;/property&amp;gt;&amp;lt;/bean&amp;gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;By leveraging the TransactionProxyFactoryBean directly instead of relying upon the tx:advice and aop:config tags, I was able to wrap my Spring ACL secured methods with declarative transactions. Nice.&lt;/div&gt;</description></item><item><title>Resolve foreign key constraint error/conflict with DBUnit CLEAN_INSERT operation (MySQLIntegrityConstraintViolationException)</title><link>https://www.ericsimmerman.com/blog/2009/06/17/resolve-foreign-key-constraint-error/conflict-with-dbunit-clean_insert-operation-mysqlintegrityconstraintviolationexception/</link><pubDate>Wed, 17 Jun 2009 00:00:00 +0000</pubDate><guid>https://www.ericsimmerman.com/blog/2009/06/17/resolve-foreign-key-constraint-error/conflict-with-dbunit-clean_insert-operation-mysqlintegrityconstraintviolationexception/</guid><description>&lt;div class='post'&gt;
&lt;p&gt;If DBUnit starts throwing MySQLIntegrityConstraintViolationException while performing a CLEAN_INSERT you can lose quite a bit of sleep attempting to resolve it or you can cheat and get back to work. The shortcut is to simply disable constraints for the INSERT operation by disabling constraints for DBUnit altogether. You can do that by adding sessionVariables=FOREIGN_KEY_CHECKS=0 to your JDBC connection string to MySQL. I use maven and in pom.xml my configuration for the dbunit plugin looks like this&lt;/p&gt;</description></item><item><title>Spring MVC's checkboxes tag and support for enum</title><link>https://www.ericsimmerman.com/blog/2009/02/21/spring-mvcs-checkboxes-tag-and-support-for-enum/</link><pubDate>Sat, 21 Feb 2009 00:00:00 +0000</pubDate><guid>https://www.ericsimmerman.com/blog/2009/02/21/spring-mvcs-checkboxes-tag-and-support-for-enum/</guid><description>&lt;div class='post'&gt;
Using Spring MVC's checkboxes (or radiobuttons) tag to render form inputs for an enum property is easy and clean...once you know how. After a little gnashing of teeth, due to the fact that I needed a specific display order for all options, I found the following solution:&lt;p /&gt;Here's the tag in my jsp&lt;div class="CodeRay"&gt; &lt;div class="code"&gt;&lt;pre&gt;&amp;lt;form:checkboxes itemValue=&amp;quot;value&amp;quot; itemLabel=&amp;quot;label&amp;quot; path=&amp;quot;user.degrees&amp;quot; items=&amp;quot;${degreeLabels }&amp;quot; /&amp;gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;&lt;br /&gt;Here's the way I populated my model map to retain ordering. (I placed this code in my FormController's referenceData method)&lt;div class="CodeRay"&gt; &lt;div class="code"&gt;&lt;pre&gt;List labelValues = new ArrayList&amp;lt;LabelValue&amp;gt;(); for (Degree d : Degree.values()) { labelValues.add(new LabelValue(d.name(), d.name())); } Map model = new HashMap(); model.put(&amp;quot;degreeLabels&amp;quot;, labelValues);&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;FYI, I ripped the LabelValue class used above from Matt Riable's excellent Appfuse project. The constructor takes two arguments which are mapped to the properties "value" and "label" and these properties have the typical pojo getters and setters.&lt;br /&gt;You can see from the path on my tag that degrees is a property on my User object...which is the target of my form. Here's what that looks like...I threw in my Hibernate annotations for the curious:&lt;div class="CodeRay"&gt; &lt;div class="code"&gt;&lt;pre&gt;private Set&amp;lt;Degree&amp;gt; degrees = new HashSet&amp;lt;Degree&amp;gt;(); @CollectionOfElements @Enumerated(EnumType.STRING) public Set&amp;lt;Degree&amp;gt; getDegrees() { return degrees; } public void setDegrees(Set&amp;lt;Degree&amp;gt; degrees) { this.degrees = degrees; }&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;It's probably obvious, but here's what the Degree enum looks like:&lt;div class="CodeRay"&gt; &lt;div class="code"&gt;&lt;pre&gt;public enum Degree { BA,BS,BN,BSW,MA,MS,MBA,MSN,MSW,MD,JD,PhD,PharmD,PsyD,Other;}&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;</description></item><item><title>Hibernate Annotations - IdentifierGenerationException: attempted to assign id from null one-to-one property</title><link>https://www.ericsimmerman.com/blog/2009/02/18/hibernate-annotations-identifiergenerationexception-attempted-to-assign-id-from-null-one-to-one-property/</link><pubDate>Wed, 18 Feb 2009 00:00:00 +0000</pubDate><guid>https://www.ericsimmerman.com/blog/2009/02/18/hibernate-annotations-identifiergenerationexception-attempted-to-assign-id-from-null-one-to-one-property/</guid><description>&lt;div class='post'&gt;
While using Hibernate annotations to implement a @OneToOne relationship where the entities are joined by primary key (@PrimaryKeyJoinColumn) I kept encountering a relatively infamous Exception:&lt;div class="CodeRay"&gt; &lt;div class="code"&gt;&lt;pre&gt;IdentifierGenerationException: attempted to assign id from null one-to-one property&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;I discovered that my issue could easily be resolved by adding "optional=false" to the dependent side of the relation. Here's a brief summary of the relevant related code.&lt;div class="CodeRay"&gt; &lt;div class="code"&gt;&lt;pre&gt;@Entitypublic class Profile implements Serializable { @OneToOne(mappedBy=&amp;quot;profile&amp;quot;, optional=false, fetch=FetchType.LAZY) public Hospital getHospital() { return hospital; } @Id @GeneratedValue(generator=&amp;quot;foreign&amp;quot;) @GenericGenerator(name=&amp;quot;foreign&amp;quot;, strategy = &amp;quot;foreign&amp;quot;, parameters={ @Parameter(name=&amp;quot;property&amp;quot;, value=&amp;quot;hospital&amp;quot;) }) public Long getId() { return this.id; }}@Entitypublic class Hospital implements Serializable { @OneToOne(cascade = CascadeType.ALL,fetch=FetchType.LAZY) @PrimaryKeyJoinColumn public Profile getProfile() { return profile; } @Id @GeneratedValue(strategy=GenerationType.AUTO) public Long getId() { return id; }}&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;</description></item><item><title>Spring JMS Remoting support for async calls and methods with void return types</title><link>https://www.ericsimmerman.com/blog/2008/05/28/spring-jms-remoting-support-for-async-calls-and-methods-with-void-return-types/</link><pubDate>Wed, 28 May 2008 00:00:00 +0000</pubDate><guid>https://www.ericsimmerman.com/blog/2008/05/28/spring-jms-remoting-support-for-async-calls-and-methods-with-void-return-types/</guid><description>&lt;div class='post'&gt;
I've submitted a patch to the Spring Framework to give their &lt;a href="http://jira.springframework.org/browse/SPR-4427"&gt;JMS remoting feature support for async calls and methods with void return types&lt;/a&gt;. The associated Jira ticket (&lt;a href="http://jira.springframework.org/browse/SPR-4427"&gt;SPR-4427&lt;/a&gt;) could use a few votes if you are so inclined.&lt;/div&gt;</description></item><item><title>Java webbrowser plugin for AMD64 Ubuntu</title><link>https://www.ericsimmerman.com/blog/2007/10/29/java-webbrowser-plugin-for-amd64-ubuntu/</link><pubDate>Mon, 29 Oct 2007 00:00:00 +0000</pubDate><guid>https://www.ericsimmerman.com/blog/2007/10/29/java-webbrowser-plugin-for-amd64-ubuntu/</guid><description>&lt;div class='post'&gt;
There is now (finally) a fix for Java applet support on AMD64 Ubuntu. Try the following:&lt;div class="CodeRay"&gt; &lt;div class="code"&gt;&lt;pre&gt;sudo apt-get build-dep icedtea-java7-pluginsudo apt-get -b source icedtea-java7-plugin icedtea-java7-bin icedtea-java7-jre icedtea-java7-jdksudo dpkg -i icedtea-java7-*deb&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;Thanks to Fabien Lusseau for the tip in his comment &lt;a href="https://bugs.launchpad.net/ubuntu/+source/icedtea-java7/+bug/152362"&gt;here&lt;/a&gt;&lt;/div&gt;</description></item></channel></rss>