Here’s a way to do it:

1) Since solr.war is not yet available on public maven repo (SOLR-1218) make sure you deploy the solr.war file in any of your maven repo. In this post I’ll assume that solr.war is found inder org.apache.solr:solr-webapp:1.4.0 of you maven repo.

2) Use the maven webapp archetype to create an empty web project:

mvn archetype:generate

choose the maven-archetype-webapp option.

3) Change the pom.xml to:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.moreover</groupId>
  <artifactId>ubersearch</artifactId>
  <packaging>war</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>ubersearch Maven Webapp</name>
  <url>http://maven.apache.org</url>
  <dependencies>
      <dependency>
        <groupId>org.apache.solr</groupId>
        <artifactId>solr-webapp</artifactId>
        <version>1.4.0</version>
        <type>war</type>
      </dependency>
  </dependencies>
  <build>
    <plugins>
       <plugin>
          <groupId>org.mortbay.jetty</groupId>
          <artifactId>maven-jetty-plugin</artifactId>
          <version>6.1.15.rc4</version>
       </plugin>
    </plugins>
  </build>
</project>

4) Copy the solr config files in the folder src/main/resources of the project. This will allow you to change them especifically for your project

$ ls src/main/resources/
elevate.xml            protwords.txt            solrconfig.xml            stopwords.txt
mapping-ISOLatin1Accent.txt    schema.xml            spellings.txt            synonyms.txt

5) Copy solr’s standard web.xml to the src/main/webapp/WEB-INF/ folder

6) Launch solr by calling the jetty plugin:

mvn jetty:run-exploded

7) Access Solr at http://localhost:8080/<artifactId>/admin/


mvn compile exec:java -Dexec.mainClass=com.mycompany.scala.App


Uma opção ao uso da distribuição do GWT, é o uso de um archetype maven que faz todo o trabalho de gestão das diferenças entres os vários sitemas operacionais, além de oferecer a possibilidade de criar um WAR com uma linha de comando. Para  criar o projeto, basta chamar o archetype:


mvn archetype:create -DarchetypeGroupId=com.totsp.gwt \
-DarchetypeArtifactId=maven-googlewebtoolkit2-archetype \
-DarchetypeVersion=1.0.3 \
-DremoteRepositories=http://gwt-maven.googlecode.com/svn/trunk/mavenrepo \
-DgroupId=br.com.dominio \
-DartifactId=app-gwt


Para executar o projeto, use o goal gwt:

mvn gwt:gwt

Antes de gerar o WAR, é preciso descomentar a linha “<!– <webXml>target/web.xml</webXml>–>” no plugin war e a linha ” <!–mergewebxml–>” do plugin maven-googlewebtoolkit2-plugin, tudo isso no pom.xml gerado. Isso porque o GWT no modo “hosted” utiliza um xml (chamado Application.gwt.xml) para declara configurações client-side E server-side. Caso você esteja utilizando RPC, o plugin maven fará um merge do Application.gwt.xml para um web.xml, migrando todas as declarações de servlet.

E finalmente para gerar o WAR, basta:

mvn package

I hoped that after the disastrous failures of applets and java web start, Sun would finally get it right, coming up with something that could be a real option to Flash and Ajax, something that could allow us, developers, to write and distribute reliable and fast desktop applications using Java on the Internet.

But it seems that I’ll have to wait some more time

I went to javafx.com to see the new demos, and received a very cryptic error whenever I clicked in one of them:

To solve this, it’s necessary to go to java console and do some changes in the temporary storage of files (!),  as described here.

I don’t remember having any problems  installing Flash on any operational system, and that includes Linux, Windows, PalmOS, Pocket PC and Symbian, using several browsers such as Internet Explorer, Opera, Firefox, Chrome and Safari.  Flash just works! You go to a page and Flash runs.  If you  don’t  have Flash, it get installed in a matter of seconds.  It works flawlessly and equally everywhere.

That’s  why things like YouTube uses Flash.  Because if a user has to figure out how to solve errors like that, he’ll simply go away.

In order to add new (visual) functionality to confluence, it’s common to use XWork to create new actions or replacing the existent actions to add new behavior. I particularly don’t like Xwork and in one of the moments to avoid boredom in these two projects I decided to somehow try to do wicket development inside confluence. The advantage would be avoiding completely XWork, possibility to use wicket advanced features and possibility to run the feature outside confluence (more testable).

So I started giving a look at the Confluence PDK (Plug in development kit), and see that it was already possible to define a servlet as part of a plugin

I then started declaring the wicket servet in atlassian-plugin.xml:

And creating the WicketApplication that simply loads my page:

That will use the Confluence API in order to do a paginated ajax table with the names of the plugins available on confluence.

After that, confluence will load the servlet and will make it available on the /plugins/servlet/sampleplugin/  URL.

ISSUES

1. The first problem is that the output will be strictly the page output, without confluence headers and menus. There’s an issue describing that bug, but while it is not fixed commenting the line 16 in the WEB-INF/decorators.xml in your confluence installation will suffice:

<url-pattern>/plugins/*</url-pattern>

That line when uncommented tells that for the URLs starting with “/plugins”, no decorator will be used. So, It’s enough to comment it.

2. The second problem is that confluence does not destroys the servlet when the plugin is uninstalled using maven PDK tool. There is another issue describing that problem. Basically, wicket creates its session object using one classloader. When the plugin is removed and reinstalled, it’ll gain another classloader. So nasty ClassCastExcetions occurs on trying to obtain the wicket session. The workaround for now is to restart the server on reinstall of the plugin.

Here we can see the final result: The standard confluence header and footer, and the wicket page in the center.

Download here the zip file containing the maven project for this example plugin.

Support for FUSE was added to linux kernel from the 2.6.14 version. To enable it:
File systems  --->
<*> Filesystem in Userspace support


After recompiling and booting the kernel, it’s necessary to install NTFS-3G. In gentoo linux this means issuing a “emerge sys-fs/ntfs3g”

To mount the driver:

ntfs-3g /dev/sda2 /mnt/win

It happens that the jetty web server, by default, does not handle URLs that contains double slashes “//”, that is, calling http://host/mycontext/media//img/a.gif is not the same as calling http://host/mycontext/media/img/a.gif, and brings a 404 error (as described in http://jira.codehaus.org/browse/JETTY-386)

To enable url compactation in the jetty through maven plug-in, and thus enabling the same behaviour as tomcat:

<plugins>
           ...
           <plugin>
                      <groupId>org.mortbay.jetty</groupId>
                      <artifactId>maven-jetty-plugin</artifactId>
                      <configuration>
                                <scanIntervalSeconds>10</scanIntervalSeconds>
                                <connectors>
                                       <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
                                               <port>8080</port>
                                               <maxIdleTime>60000</maxIdleTime>
                                       </connector>
                                </connectors>
                                <webAppConfig>
                                       <contextPath>/mycontext</contextPath>
                                       <compactPath>true</compactPath>
                                </webAppConfig>
                    </configuration>
           </plugin>
           ...
</plugins>

It happens that devware is composed of heterogeneous 3rd party tools, and obviously each one uses a different kind of authentication and security schema.

That’s where comes to scene CAS (Central Authentication Service) a very neat solution for single sign on for the web.

Luntbuild, which is a great and full featured build automation server is the first software that was “Casified”. Luntbuild, fortunately, was created using Spring and Acegi, which in turn supports CAS integration. So, this is how I Casified luntbuild:

1. Install and make sure that CAS is working

Install CAS is as hard as drop a WAR inside your favourite web container. The not-so-obvious part are the SSL issues: you and everyone must access cas using a name, and not and IP, and SSL is obligatory. And you must have a certificate (can be self signed) that reflects this name. After that, make sure that you can login in CAS accessing https://<server>/cas/login.

2. Make sure luntbuild is installed and running

The version of luntbuild that I casified was 1.5.5. This process will not work on previous versions, such as 1.3.x ones. Make sure that luntbuild is installed and that it’s possible to do a login using it’s own security scheme.

3. Changing luntbuild’s web.xml

No change is needed! luntbuild’s web.xml declares a filterToBean proxy that allows to make all filtering stuff inside spring’s application context.

4. Changing applicationContext.xml

This is where luntbuild’s spring appcontext lies.

Locate the bean “authenticationManager” and add to the list (as the first one) the CAS authentication provider:

<bean id="authenticationManager" class="com.luntsys.luntbuild.security.AuthenticationProviderManager">
                <property name="providers">
                        <list>
                                <ref local="casAuthenticationProvider" />

                                <!-- authentication provider which uses declarative security -->
                                <ref local="inMemoryAuthenticationProvider" />

                                <!-- authentication provider for remember me -->
                                <ref local="rememberMeAuthenticationProvider" />

                                <!-- authentication provider which validates users again internal db -->
                                <ref local="luntbuildAuthenticationProvider" />

                                <!-- authentication provider which validates users again Ldap -->
                                <ref local="ldapAuthenticationProvider" />
                        </list>
                </property>
        </bean>

Search and coment the bean id “exceptionTranslationFilter”:

<!--<bean id="exceptionTranslationFilter" class="org.acegisecurity.ui.ExceptionTranslationFilter">
             <property name="authenticationEntryPoint"><ref local="authenticationProcessingFilterEntryPoint"/></property>
</bean> -->

Locate the bean “filterChainProxy” and change the URL matching rules to:

<bean id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy">
     <property name="filterInvocationDefinitionSource">
        <value>
            PATTERN_TYPE_APACHE_ANT
            /*.do=httpSessionContextIntegrationFilter,casProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor
            /j_acegi_cas_security_check=httpSessionContextIntegrationFilter,casProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor
            /casProxy/receptor=httpSessionContextIntegrationFilter,casProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor
       </value>
    </property>
</bean>

And then add the beans of the CASAuthenticationProvider:

<bean id="casAuthenticationProvider" class="org.acegisecurity.providers.cas.CasAuthenticationProvider">
               <property name="casAuthoritiesPopulator">
                        <ref bean="casAuthoritiesPopulator" />
                </property>
                <property name="casProxyDecider">
                        <ref bean="casProxyDecider" />
                </property>
                <property name="ticketValidator">
                        <ref bean="casProxyTicketValidator" />
                </property>
                <property name="statelessTicketCache">
                        <ref bean="statelessTicketCache" />
                </property>
                <property name="key">
                        <value>my_password_for_this_auth_provider_only</value>
                </property>
</bean>

<bean id="casProxyDecider" class="org.acegisecurity.providers.cas.proxy.RejectProxyTickets" />

<bean id="statelessTicketCache" class="org.acegisecurity.providers.cas.cache.EhCacheBasedTicketCache">
                <property name="cache">
                        <ref local="ticketCacheBackend" />
                </property>
</bean>

<bean id="ticketCacheBackend" class="org.springframework.cache.ehcache.EhCacheFactoryBean">
                <property name="cacheManager">
                        <ref local="cacheManager" />
                </property>
                <property name="cacheName">
                        <value>ticketCache</value>
                </property>
</bean>
   <bean id="casProxyTicketValidator" class="org.acegisecurity.providers.cas.ticketvalidator.CasProxyTicketValidator">
                <property name="casValidate">
                        <value>https://devware/cas/proxyValidate</value>
                </property>
                <property name="proxyCallbackUrl">
                        <value>https://devware/luntbuild/casProxy/receptor</value>
                </property>
                <property name="serviceProperties">
                        <ref bean="serviceProperties" />
                </property>
</bean>

<bean id="casAuthoritiesPopulator" class="com.luntsys.luntbuild.security.LuntbuildCasAuthoritiesPopulator">
                <property name="authenticationDao">
                        <ref bean="luntbuildAuthenticationDAO" />
                </property>
</bean>

<bean id="serviceProperties" class="org.acegisecurity.ui.cas.ServiceProperties">
                <property name="service">
                        <value>https://devware/luntbuild/j_acegi_cas_security_check</value>
                </property>
                <property name="sendRenew">
                        <value>false</value>
                </property>
</bean>

<bean id="casProcessingFilter" class="org.acegisecurity.ui.cas.CasProcessingFilter">
                <property name="authenticationManager">
                        <ref bean="authenticationManager" />
                </property>
                <property name="authenticationFailureUrl">
                        <value>/casfailed.jsp</value>
                </property>
                <property name="defaultTargetUrl">
                        <value>/</value>
                </property>
                <property name="filterProcessesUrl">
                        <value>/j_acegi_cas_security_check</value>
                </property>
</bean>

<bean id="exceptionTranslationFilter" class="org.acegisecurity.ui.ExceptionTranslationFilter">
                <property name="authenticationEntryPoint">
                        <ref local="casProcessingFilterEntryPoint" />
                </property>
</bean>

<bean id="casProcessingFilterEntryPoint" class="org.acegisecurity.ui.cas.CasProcessingFilterEntryPoint">
                <property name="loginUrl">
                        <value>https://devware/cas/login</value>
                </property>
                <property name="serviceProperties">
                        <ref bean="serviceProperties" />
                </property>
</bean>

Replace “https://devware” with your cas host.

The final piece of the puzzle is the casAuthoritiesPopulator declared above. This is necessary to populate the luntbuild user’s credentials accordingly after the user has logged on, and to create the user in the luntbuild database it does not exist already, similar to what happens when integration luntbuild with LDAP. I’ve submitted a patch to luntbuild’s tracker with this class

5. Final remarks

After this procedure, if one logins into cas, and after that enters luntbuild, a second login will not be necessary. If someone tries to enter luntbuild directly, it’ll redirect to CAS login page. And the same happens with every other applications that is “Casified”. Without changing the source code of luntbuild at all (just changing XML and adding one more class), it was possible to change a major application behavior, and that’s the beauty of spring based projects. They are so decoupled that nearly every aspect of an application instantly becomes an extension point!

And the use of CAS allows to have SSO and not depend on things like proprietary realms, intrusive server configurations, and obscure plugins that are target to a certain version of a certain application server maker. CAS is very portable, the only requisite is an application container that support servlets.

What you’ll need:

• an Ipod classic 160 Gb, with enough free space
• a burned ISO of Ghost for Linux (g4l)
• a burned ISO of Gentoo Live CD
• a running vmware server on another machine.

Prepare the kernel for vmware

Since the existing physical gentoo installation will run on vmware after the backup, it doesn’t hurt to enable in the kernel support for the “hardware” it’ll encounter. These are the features that must be enabled on the kernel to support vmware server 1.0.x:

Support for vmware NIC:

Device Drivers --->

     [*] Network device support  --->
        [*]  Ethernet (10 or 100Mbit)  --->
                 [*]   EISA, VLB, PCI and on board controllers
                 <*>     AMD PCnet32 PCI support

Support for vmware SCSI:

Device Drivers --->
         SCSI device support  --->
               <*> SCSI disk support
                [*] SCSI low-level drivers  --->
                      <*>   BusLogic SCSI support

Doing the backup

1. Connect the ipod via USB and boot the gentoo machine with the g4l CD. In the kernel list, choose the latest RELEASED one.

2. After booting, the ipod should be detected as a general USB storage device. In my machine it is seen as /dev/sdb1. To be sure, a simple mount will suffice to discover:

mount /dev/sdb1  /mnt/local

3. Type ‘g4l’ to enter the ‘graphical interface’. In the main menu, choose “RAW Mode”

4. Then choose “Local use”

5. In the local use screen, configure the following values:
A: Pick the drive: choose the ipod device, or (X) sdb1
B: Config filename: I’ve chosen vaio_bkp.img
C: Toogle split: (X) On. This is very important. Ipod is formatted as FAT32 under windows, and does not support files larger than 4Gb
D: Toogle compression: I’ve chosen (X) None, since I have plenty of free space in my ipod and thus the process can be faster and less cpu intensive
E: Backup: choose the partition on the machine to be backed up, (X) sda4, for example.

After that, G4l will show all the choices made before starting the process:

6. Several 1Gb files will be created in the ipod root folder. The backup speed was about 18 Mb/s in my environment, so, to backup 80Gb it took aprox. 70 min.

Creating the vm

1. In another machine that has vmware server instaled, create a new virtual machine (File -> New -> Virtual Machine), choose “custom” -> “Linux” -> “Other Linux 2.6.x kernel”, and when prompted for “I/O Adpater type” choose “BusLogic”. When prompted for “Disk type”, choose “SCSI”. In the “Disk capacity” choose the same size of the partition in the original machine. Keep “allocate disk now” unchecked, to save space. In the vmware server console, add to the virtual machine a USB Controller (menu VM -> Settings) and then “Add -> USB Controller”
2. Boot the virtual machine with g4l live CD, with the ipod plugged in. Run “fdisk” and make sure that the partition layout is the same of the original gentoo, that is, if the partition was called /dev/sda4 in the source machine, create in the virtual machine the same partition name. Don’t forget to toggle the bootable flag in this partition.
3. The vm should see the ipod in the USB. If not go to menu VM -> Removable Devices -> USB Devices and mark “Apple Computer USB Device”.

Restoring the backup

1. In ghost for linux, go to the menus:
RAW Mode -> Local Use
2. Choose the options:
A: sdb1 (or where the ipod was mounted)
B: the same name used to backup
C: Toogle split (On)
D: Toogle compression (None) if compression was not used
F: Restore: choose the partition created in vmware, matching the original partition name. G4l will show a resume before restoring:

The restore will take longer than the backup, since vmware server 1.0.x still does not support high speed USB (the support is coming in vmware server 2, still in beta stage). In my environment, I could get a 2.4 Mb/s speed.

Fixing the bootloader

Now that you have a clone of the physical machine under vmware, chances are that it still not bootable. This may occurs if the partition backed-up was not where the bootloader was installed. In my case, the backup was made from /dev/sda4, and the bootloader was installed in /dev/sda alongside with windows, to enable dual boot. To fix this, boot the virtual machine with gentoo install CD, and install grub again:

# mount the partition
mount /dev/sda4 /mnt/gentoo

# Remount /dev/ inside the partition
mount -o bind /dev/ /mnt/gentoo/dev

# Chroot into the partition
chroot /mnt/gentoo /bin/bash

# mount proc
mount -t proc proc /proc

# Populate /etc/mtab, so that grub-install does not get angry
cat /proc/mount >> /etc/mtab

# Install grub on the disk
grub-install /dev/sda

Now the virtual machine is bootable!

Fixing X and network

After booting, eth0 is not available, thanks to udev. As the MAC Address of the NIC changed, udev allocates eth1 and wipes eth0. To fix this, simply:

rm  /etc/udev/rules.d/70-persistent.net.rules

and reboot the system.

To fix the X server, run the command ‘xorgconfig’. Choose the following options:

Mouse Protocol:  1
Emulate3Buttons: Y
Mouse device: /dev/input/mouse0
card  database:  choose 30 (vmware)

And that’s all! Now we have a perfect running clone of the physical machine, with network and X support, in a relative easy manner.