At the moment this post is available in Italian only.
You can see the full presentation on infoQ
A few months ago I joined Free Software Foundation Europe (FSFE) as translator (from English to Italian):
We are a community of people who are committed to Free Software. Please join us in our work! There are many ways to do so and you will find a way that fits your interests and skills.
My interests and motivations to join FSFE were various:
Recently I was asked if I would have been interested in getting commit access to the FSFE web site source repository… of course I was :-)
I quickly realized that such repository has more than 15 years history!!! Thus I started wondering that it would have been nice visualizing such history with Gource. In the past I had already used Gource to visualize Parancoe history, a Java meta-framework developed by some Java User Group Padua (JUG PD) guys, but this time I was curious to see how a web site history was different from a framework one.
So I have recorded a 10 minutes long video about commit activity on FSFE web site source repository from February 2001 to July 2016.
Since 1872 it was clear that writing by mechanical means would have become obsolete the laborious and unsatisfactory performance of the pen.
I was asked to add an extra-encryption to json formatted data exchanged between clients and a RESTful web service.
This is the second monitoring about the post campaign Free Software PDF Readers, launched by Free Software Foundation Europe (FSFE) in 2009.
The first monitoring is available in the post “adoption of Free Software PDF readers in Italian Regional Public Administrations”.
I was adding declarative transaction management support to a Spring 3.1.1 based web application when I got the error:
28-apr-2016 9.38.15 org.apache.catalina.core.StandardContext listenerStart GRAVE: Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'myService' defined in file [...\myProject\service\MyService.class]: Initialization of bean failed; nested exception is org.springframework.aop.framework.AopConfigException: Cannot proxy target class because CGLIB2 is not available. Add CGLIB to the class path or specify proxy interfaces. at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:527) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:913) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:464) at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:385) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:284) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3972) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4467) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:637) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:563) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:498) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:722) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:593) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) Caused by: org.springframework.aop.framework.AopConfigException: Cannot proxy target class because CGLIB2 is not available. Add CGLIB to the class path or specify proxy interfaces. at org.springframework.aop.framework.DefaultAopProxyFactory.createAopProxy(DefaultAopProxyFactory.java:67) at org.springframework.aop.framework.ProxyCreatorSupport.createAopProxy(ProxyCreatorSupport.java:104) at org.springframework.aop.framework.ProxyFactory.getProxy(ProxyFactory.java:112) at org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.createProxy(AbstractAutoProxyCreator.java:476) at org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.wrapIfNecessary(AbstractAutoProxyCreator.java:362) at org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessAfterInitialization(AbstractAutoProxyCreator.java:322) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsAfterInitialization(AbstractAutowireCapableBeanFactory.java:407) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1461) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519) ... 35 more
It is warmly suggested to perform the migration on a case-sensitive file system, otherwise the migration process might end up in a not correctly transformed git repository, as reported from the following discussions.
Most of the Free Software and OpenSource consists of both new written source code and reused 3rd parties “binary” code. When we write a new software we usually make it depend on lots of 3rd parties libraries (such dependent libraries are also called dependencies).
In order to give an idea about how complex and deep the dependencies graph could be let’s suppose our new software has a direct dependency on the 3rd party library
rampart-core-1.3 (on the left in the figure above). Such library itself depends on other 3rd party libraries. This second level of 3rd party libraries, with respect of our new software, includes libraries called transitive dependency. Now think that our new software might have lots of direct dependencies and figure out how many 3rd part dependencies its consist of.
Thanks to some Ready To Use Java Static Code Analyzers we know how to discover some bugs in source code, but what about bugs and vulnerabilities in 3rd parties dependencies?
Exploratory Refactoring consists in a series of small changes to source code which are made by the programmer in order to better reflect his/her comprehension of explored code.
As exploration is a way to discover places by walking throughout them and by drawing a map, likewise Exploratory Refactoring is a way to discover what a piece of code does by reading it and by rewriting little part of it.
Exploratory Refactoring is a technique a developer, who works on a legacy codebase, might use to understand the codebase logic before actually starting with the actual refactoring.