Programming and So

Quartz is a job scheduler for java. Execution periods can be expressed using the same expressions used in cron. Jobs are lauched by Quartz as static classes outside in a standalone way.

If a Quartz job uses a bean from inside a webapp, applicationContext from Spring must be shared with the job. I’ve found two resources in order to perform this operation:

• Quartz official documentation
• Spring Forums

Both articles explain the same. However, I must force my imagination to understand the first one and I can read the second one naturally. Curious.

Spring Security allows applications to include authentication features in J2EE applications with a very few effort. However, configuration in previous versions, like Acegi Security, was a hard task to perform by a newcomer. Spring people talks about a difference of a hundred of configuration lines between Acegi 1.0 (120 lines for configuration) and Security 2.0 (just only 16 lines). So, it’s highly advisable to use Spring Security 2.0.

These links can help in developing a small sample:

• 5 minute guide to Spring Security
• What’s new in Spring Security 2?

In our case, form based authentication via user/password in a webapp, we’ve include two minor adjustments in web.xml (webapp container configuration) and applicationContext.xml (Spring configuration).

web.xml

<filter>
    <filter_name>springSecurityFilterChain</filter_name>
    <filter_class>org.springframework.web.filter.DelegatingFilterProxy</filter_class>
</filter>
<filter_mapping>
  <filter_name>springSecurityFilterChain</filter_name>
  <url_pattern>/*</url_pattern>
</filter_mapping>

* I’ve replaced – character for _ character in this XML file

applicationContext.xml

< ?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:security="http://www.springframework.org/schema/security"
	     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	     xsi:schemaLocation="http://www.springframework.org/schema/beans
	                         http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
	                         http://www.springframework.org/schema/security
	                         http://www.springframework.org/schema/security/spring-security-2.0.xsd">
<security__http>
    <security__intercept_url pattern="/**.sdf" access="ROLE_USER" />
<security__anonymous />
<security__http_basic />
    <security__form_login login_page="/login.jsp" />
</security__http>
<security__authentication_provider>
    <security__password_encoder hash="md5"/>
    <security__user_service>
        <security__user name="admin" password="21232f297a57a5a743894a0e4a801fc3" authorities="ROLE_USER, ROLE_ADMIN" />
    </security__user_service>
</security__authentication_provider>
[...]
</beans>

* I’ve replaced – character for _ character and : character for __ characters in this XML file to get a suitable visualization

Development of login.jsp page is detailed in several resources, such as here.

It could be wonderful, but there is one important point for us which is poorly documented. Spring Security 2.0 only works with Spring 2.0.8. And we are using BEA Weblogic 10. And BEA Weblogic 10 only certifies the use of Spring 2.0.2. 

So we have now a dangerous decision: shall we use Spring Security 2.0 and Spring 2.0.8 and loose BEA (I mean Oracle) support or shall we use Acegi Security 1.0 and Spring 2.0.2 and write tedious and hard to maintain configuration files?

Defining one entry point for every web service request in the system can be advisable in specific scenarios such as security based on URL ones. Below it’s described this kind of solution using Spring WS 1.0 as web service stack and XMLBeans 2 as marshalling method.

web.xml

Define desired URL (for instance, http://server/app/services/)

<!-- Defines the Spring-WS MessageDispatcherServlet -->
<servlet>
    </servlet><servlet -name>spring-ws</servlet>
        <servlet -class>
            org.springframework.ws.transport.http.MessageDispatcherServlet
        </servlet>
        <init -param>
            <!-- Transform the location attributes in WSDLs -->
            <param -name>transformWsdlLocations</param>
            <param -value>true</param>
         </init>

<!-- Map all requests to this servlet -->
<servlet -mapping>
    </servlet><servlet -name>spring-ws</servlet>
    <url -pattern>/services/*</url>

applicationContext.xml

Configuration to get XMLObjects from XMLBeans unmarshalled at the endpoint.

<!-- EndPoint Mapping -->
<bean id="messageDispatcher"
    class="org.springframework.ws.server.MessageDispatcher">
    <property name="endpointMappings">
	<list>
                 <ref local="payloadMapping" />
             </list>
    </property>
</bean>

<!-- Payload Mapping -->
<bean id="payloadMapping" class="org.springframework.ws.server.endpoint.mapping.PayloadRootQNameEndpointMapping">
    <property name="defaultEndpoint" ref="uniqueEndpoint" />
    <!-- XSD validation can be specified -->
    <property name="interceptors">
	<list>
                 <ref local="validatingInterceptor" />
             </list>
    </property>
</bean>

<!-- XSD validation -->
<bean id="validatingInterceptor"
class="org.springframework.ws.soap.server.endpoint.interceptor.PayloadValidatingInterceptor">
    <!-- Schemas repository folder -->
    <property name="schemas" value="/WEB-INF/schemas/*.xsd" />
    <property name="validateRequest" value="true" />
    <property name="validateResponse" value="true" />
</bean>

<!-- Unique endpoint -->
<bean id="uniqueEndpoint" class="foo.bar.EndPoint">
    <!-- XMLBeans marshalling (in & out) -->
    <constructor -arg ref="xmlBeansMarshaller" />
</bean>

Endpoint Java Class

package foo.bar;

public class FCEEndPoint extends org.springframework.ws.server.endpoint.AbstractMarshallingPayloadEndpoint {

    public FCEEndPoint(Marshaller marshaller) {
        super(marshaller);
    }

    protected Object invokeInternal(Object requestObject) throws Exception {

        XmlObject in = (XmlObject)requestObject;

        // Retrieve operation name from some point of the incoming XML
        String operationName = in.getDomNode().getFirstChild().getNodeValue();

        // Generic invoker based on Java reflection
        XmlObject out = OperationInvoker.invoke(operationName, in);

        return out;

    }
}

How it works?

In this way, new web services can be added by creating one XSD file and implementing its related business object. And clients only have to invoke the same URL for each request just only by using an appropiate XML.