J2EE

If you are doing signature generation via a hardware token (for instance 3Skey) then, for large files it is impractical to send the file to the hardware token. Instead you send a hash (SHA256), get a detached PKCS#7 signature and you need to re-attach the payload in java code. For once this was easier to do with plain JCE code instead of my favorite BouncyCastle provider. However for really large files BC does provide the streaming mechanism required....

These last days I had to tinker with openssl a lot and this is a short memory reminder of the params. PKCS#7 manipulation Verify pkcs#7 signature #the -noverify means do not verify the certificate chain, this will only verify the signature not the originating certificate openssl smime -inform DER -verify -noverify -in signature.p7s Show the structure of the file (applies to all DER files) #for debuging openssl asn1parse -inform DER -i -in signature....

It’s been a long time since I felt such satisfaction debuging something so I decided to write about it. Let’s assume that you need to store (cache) in memory a large object tree during some operations. In practice this happens because some regulatory constraints so you end up having to parse a very large file and store the resulting object tree. Actually you have a single entry cache. You parse your object, store it in memory for search and processing while the current object tree is used....

Multicast might seem like a great idea for 2 problems: iptv and discovery. In my case it seemed like a very good idea for cluster node auto-discovery: no need to configure each node with all the other nodes, no need to know the number of nodes beforehand, use a single node configuration. However it seems that more and more nodes are discovered you can fall into some very dark pitfalls which could eat days and nights of your time until either you find a solution, either you revert to tcp or udp unicast....

At first replicating EhCache seems a very easy task, just need to configure ehcache.xml with RMI and you are ready. Is it so? RMI At the beginning it seems so, the cache seems to be replicated, everything works. However at some point you notice in the log something like: Exception on replication of putNotification. Error unmarshaling return header; nested exception is: java.net.SocketTimeoutException: Read timed out. Continuing... java.rmi.UnmarshalException: Error unmarshaling return header; nested exception is: java....

This is a continuation of the previous article regarding some migration points (1, 2) from JBoss 4.2.2-GA to JBoss 7.1.1 and, presumably, Tomcat 7. 3. Quartz Quartz migration has been the simplest of all, by far. 3.1 JBoss 4.2.2 In JBoss 4.2.2 Quartz was configured using a MBean with a simple configuration: <pre lang="xml"> <?xml version="1.0" encoding="UTF-8"??> <server> <mbean code="org.quartz.ee.jmx.jboss.QuartzService" name="user:service=QuartzService,name=QuartzService"> <depends>jboss.jca:service=DataSourceBinding,name=XOracleDS</depends> <depends>jboss.web.deployment:war=/X</depends> <attribute name="Properties"> org.quartz.scheduler.instanceName = DefaultQuartzScheduler org.quartz.scheduler.rmi.export = false org....

This is a continuation of the previous article regarding some migration points from JBoss 4.2.2-GA to JBoss 7.1.1 and, presumably, Tomcat 7. 2. The HAR archive The HAR archive was a nice mechanism which allowed hibernate integration. A ${name}.har file was created, containing all the mappings (*.hbm.xml) and data classes (*.class), allong with a hibernate-service.xml (later renamed to service-hibernate.xml in JBoss 5). This took care of creating the SessionFactory and making it accessible through JNDI....

I have spent a lot of time lately trying to create a migration plan for an application currently running on JBoss 4.2.2. Since this application development started a few migration attempts to newer versions of JBoss have been done (see for 5.1) but as it seems each version has different style configuration files and this application is expected to have a long lifetime the work seems a bit futile so in parallel of...

I was a big fan of Flex. The code was clean, object-oriented, re-usable. We even had the bonus of E4X. We’ve wrote the interface of a huge project using it and I know there was no way we could have had such a rich client other than using native code. We developed multiplatform and the client ran multiplatform without a bit of change. The deployment was easy and the administration on the client side minimal....

This is not a guide, nor intended to help, it’s a steam valve for my efforts to migrate an application to jboss 7 as each exception can take minutes or hours to solve without altering the original code. Caused by: org.jboss.jca.common.metadata.ParserException: IJ010061: Unexpected element: local-tx-datasource at org.jboss.jca.common.metadata.ds.DsParser.parseDataSources(DsParser.java:183) at org.jboss.jca.common.metadata.ds.DsParser.parse(DsParser.java:119) at org.jboss.jca.common.metadata.ds.DsParser.parse(DsParser.java:82) at org.jboss.as.connector.deployers.processors.DsXmlDeploymentParsingProcessor.deploy(DsXmlDeploymentParsingProcessor.java:80) at org.jboss.as.ee.metadata.MethodAnnotationAggregator.runtimeAnnotation Information(MethodAnnotationAggregator.java:58) at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.ha ndleAnnotations(InterceptorAnnotationProcessor.java:85) at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.pr ocessComponentConfig(InterceptorAnnotationProcessor.java:70) at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.de ploy(InterceptorAnnotationProcessor.java:55) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] ... 5 more Caused by: java....