very good and detailed explanation on jspx

http://diaryproducts.net/about/programming_languages/java/convert_jsp_pages_to_jsp_documents_jspx_with_jsp2x

Convert JSP pages to JSP documents (JSPX) with Jsp2x
Submitted by Hannes Schmidt on Thu, 01/17/2008 - 19:01.

Jsp2X is a command line utility for batch conversion of JSP pages to JSP documents, i.e. JSPs in well-formed XML syntax (aka JSPX, see chapter 5 of the JavaServer PagesTM 1.2 Specification and chapter 6 of the JavaServer PagesTM 2.0 Specification). It is written in Java and incorporates a parser derived from a combined JSP+XHTML grammar using the ANTLR parser generator. It tries very hard to create JSPX output that portable across engines. Jsp2X was designed to be used in an iterative fashion in which it alerts the user of potential problems in the input.
Introduction

Version 1.2 of the JSP standard introduces the notion of JSP documents which are simply JSP files in well-formed XML syntax. Files in traditional JSP format, also known as JSP pages contain a more or less free-form tag soup for which parsers are difficult to write and which are therefore hard to digest in an automated manner. It took a long time until the various JSP engine vendors agreed on what was valid JSP and what wasn't. I usually prefer the Jetty servlet container for testing a web application during development because it starts up quickly which reduces the time it takes to switch between coding and testing an application. When I later deploy that application to Resin I am bewildered to see Resin reject the JSPs that worked flawlessly in Jetty. An upgrade to Resin 3.0.23 fixes many discrepancies but I still end up tweaking my JSP pages to make them work in both containers.

JSP documents are well-formed XML. XML has a strict and precise (albeit verbose) syntax. There are plenty of parsers and other tools available for XML. Making your JSP files XML-compliant therefore opens a world of possibilities for further processing. For example, I have haven't found a single JSP editor that correctly formats and highlights anything but the simplest pages. With JSP documents these problem have a trivial solution: use your favorite XML editor.

Another annoying trait of JSP pages is that the JSP engine preserves insignificant whitespace. A JSP parser only parses what looks like a JSP tag or a directive even if the text in between is well-formed XML. For that reason it can't detect and remove whitespace that would be considered insignificant by XML or HTML standards. This unnecessarily increases the size of the emitted HTML. The more JSP code is factored out into tag files or included JSP fragments, the more insignificant whitespace generated and sent to the browser. In JSP documents, on the other hand, it is very easy to detect and drop insignificant whitespace. In fact, if the JSP engine uses an XML parser to read the input, the parser will take care of whitespace on behalf of the engine. To give you a rough idea about the potential savings: after I converted all 70+ JSP pages and tag files of a well-factored 100k SLOC web application to JSP documents, the average size of the HTML output decreased by 50% to 75%!

Taking into account that the template text in most JSP pages is in fact XHTML or HTML the JSP committee realized that it isn't a very long road from a JSP page to a well-formed XML document. They only had to get rid of the leniency in the JSP parser and come up with alternatives for crazy constructs like <a href="<c:url …>"> . This thought process led to the definition of JSP documents in the JSP standard at time when millions of JSP pages had already been written an deployed. This is where Jsp2X comes in. It is a tool that assists in the conversion of JSP pages to JSP documents, a process that is generally straight-forward but tends to be tedious and has the potential to introduce subtle errors when executed by hand.

To understand what JspX does you need to keep in mind that unlike a JSP engine, Jsp2X parses both the JSP tags and the template text in between those tags. In that respect Jsp2X incorporates a more complex parser than what you'd find in a typical JSP engine (luckily, I had a very powerful and yet easy-to-use tool at hand: ANTLR, a robust LL(*) parser generator). More importantly, Jsp2X can successfully parse the template text in your JSP pages only if it is reasonably correct XHTML. Jsp2X doesn't expect fully well-formed XML template text. It requires that all tags are nested properly and that empty tags are closed correctly. There is no need for a single root element - Jsp2X will create one on-the-fly if necessary.
Where can I get it?

The latest binary and source distributions be downloaded from this page. To compile the sources you need Maven version 2.0.7 and a JDK 1.6.0_02. Older Maven 2.0 releases >= 2.0.4 may work as well and a recent 1.5 JDK should be fine, too. Jsp2X is released under the LGPL.

The usage of the binary distribution is described in section Usage.

The source code repository is hosted at Google Code.
What exactly does it do?

A conversion of a single JSP page requires a number of different transformations. The following is a hopefully complete list:

    * Jsp2X writes the converted input to an output file whose name is derived from the input file. The extension of the output file name is mapped according to what the JSP standard lists as standard extensions for JSP pages/documents, tag files and fragments (also see Usage).
    * Jsp2X adds four very short utility tag files to the converted project. They have the jspx: prefix and contain functionality that would otherwise clutter the converted JSP document.
    * Jsp2X wraps the JSP page in a <jsp:root> tag.
    * Jsp2X wraps JSP fragments into a <jspx:fragment> tag. <jsp:root> tags in fragments are disallowed so I had to come up with another tag that is transparent with respect to the generated output and that can be used to collect the potentially many top-level elements of a fragment underneath a single top-level element (a requirement of XML well-formedness).
    * Jsp2X converts all taglib declarations to name space references on the new root element (<jsp:root> or <jsp:fragment>). Unused taglibs are omitted. Jsp2X even detects taglibs that are declared in a fragment that is included by the JSP page to be converted. JSP page authors often move their taglib declarations to a separate file that is then included at the top of every JSP page.
    * Jsp2X escapes special XML characters in the input. Keep in mind that an JSP document is parsed twice, once by the JSP engine's XML parser and once on the client side by the browser's HTML/XHTML parser. If you wanted to display a literal < on a page, it was sufficient to put the HTML entity < into the JSP page because the entity had no special meaning to the JSP parser. A JSP document would have to read &lt; to get the desired effect. The JSP parser will substitute & with & such that the browser gets the intended &lt ; and renders that as < . Jsp2X does the necessary escaping for you.
    * Jsp2X wraps template text in <jsp:text> tags, excluding insignificant whitespace.
    * Jsp2X escapes HTML comments and converts JSP comments to XML comments with the intended effect that HTML comments will end up in the output whereas JSP comments do not.
    * Jsp2X wraps scriptlets and expressions in <jsp:scriptlet> and <jsp:expression> tags respectively.
    * Jsp2X inserts escaped HTML comments into the body of elements with empty bodies to prevent them from being collapsed into empty element: <td></td> becomes <td><!----&gt</td> . This is definitely noisy but I found no other way to prevent the JSP engine's XML parser from collapsing empty element bodies. One of the goals for Jsp2X was to preserve the intent of a JSP page as much as possible. Luckily, a typical HTML page doesn't contain that many empty elements so the added syntactic noise will be minimal.
    * Jsp2X tries to detect and convert dynamic attribute constructs. The detection of these constructs is not bullet-proof because Jsp2X does not have a full-blown EL expression parser. Instead it uses regexes to detect the most common cases. The table below lists the supported cases (with additional whitespace and indention for clarity).
      JSP page 	JSP document

      <foo x="<bar …>">
          …
      </foo>

      	

      <jspx:element name="foo">
          <jspx:attribute name="x"/><bar…></jspx:attribute>
          <jspx:body>…<jspx:body>
      </jspx:element>

      <foo <c:if test="…">x="…"<c:if>>
          …
      </foo>

      	

      <jspx:element name="foo">
          <c:if test="…">
              <jspx:attribute name="x"/>…</jspx:attribute>
          <c:if>
          <jspx:body>…<jspx:body>
      </jspx:element>

      <foo ${condition : 'x="…"' ? ''}>
          …
      </foo>

      	

      <jspx:element name="foo">
          <c:if test="${condition}">
              <jspx:attribute name="x"/>…</jspx:attribute>
          <c:if>
          <jspx:body>…<jspx:body>
      </jspx:element>

      <foo ${condition : '' ? 'x="…"'}>
          …
      </foo>

      	

      <jspx:element name="foo">
          <c:if test="${!(condition)}">
              <jspx:attribute name="x"/>…</jspx:attribute>
          <c:if><jspx:body>…<jspx:body>
      </jspx:element>

      <foo ${condition : 'x="…"' ? 'y="…"'}>
          …
      </foo>

      	

      <jspx:element name="foo">
          <c:choose>
              <c:when test="${condition}">
                  <jspx:attribute name="x"/>…</jspx:attribute>
              <c:when>
              <c:otherwise>
                  <jspx:attribute name="y"/>…</jspx:attribute>
              </c:otherwise>        
          </c:choose>
          <jspx:body>…<jspx:body>
      </jspx:element>

    * Jsp2X rewrites the file extension in references to an included file as long as the included file is also listed as an input file. This is why you should convert all JSP files in a single invocation of Jsp2X. If you don't Jsp2X will not be able to rewrite references to converted files.
    * Jsp2X converts DOCTYPE declarations to <jsp:output> elements.

You might notice the use of <jspx:element> and <jspx:attribute> tags where you'd expect JSP's built-in <jsp:element> and <jsp:attribute> tags. The reason is that the built-in mechanism doesn't work for conditional attributes (something I consider a blatant oversight in the standard). For example,

<jsp:element …><c:if …><jsp:attribute …>…</jsp:attribute></c:if></jsp:element>

doesn't work because the attribute element applies to the <c:if> tag, not the <jsp:element> tag. It is in accordance with the standard but the standard should have been written to accommodate this very common use case. Jsp2X creates several tag files with custom tags that have similar functionality to <jsp:element> , <jsp:attribute> and <jsp:body> but work for conditional attributes:

<jspx:element name="foo"><c:if …><jspx:attribute name="bar">…</jsp:attribute></c:if></jsp:element> .

Another difference is that <jspx:element> distinguishes between empty tags and tags with empty bodies. For example, a JSP page with

<jspx:element name="foo"><jsp:body/></jsp:element>

will emit <foo></foo> and

<jspx:element name="foo"></jsp:element> or <jspx:element name="foo"/>

will emit <foo/> . The jsp: variant would have emitted <foo/> in either case. This is XML-compliant but violates HTML (not XHTML) in which <div></div> and <div/> are treated differently. The latter is actually disallowed and the its effect differs from browser to browser. FF treats it like an opening <div> and implicitly closes it at the end of the parent tag, e.g.

<td><div class="a"/><div>foo</div><td> is treated like

<td><div class="a"><div>foo</div></div></td> .

IE7 simply ignores everything after the <div/> .

The use of Jsp2X's custom <jspx:element> instead of the built-in <jsp:element> assists in creating output that is more likely to preserve the JSP page author's intent. It also enables the use of HTML (albeit a somewhat stricter dialect of it) as opposed restricting the template text to pure XHTML.
Requirements

    * mandatory: JDK 5 or higher
    * recommended: JSP files named with standardized extensions ( .tag , .jsp and .jspf .
    * recommended: Access to the complete set of all JSP files that comprise the web application (i.e. everything underneath the WEB-INF directory).
    * recommended: The include directives in every input JSP page should use context-relative URIs to refer to other JSP files (as in /WEB-INF/jsp/taglibs.jspf ).

Usage

Jsp2X is distributed as an executable JAR file. It is invoked as follows:

# java -jar <path to distribution jar> …

Invoking it with --help shows the command line options.

# java -jar jsp2x-VERSION-bin.jar --help
Usage:
Jsp2X [--help] [-c|--clobber] [(-o|--output) <output>] file1 file2 … fileN

Converts JSP pages to JSP documents (well-formed XML files with JSP tags).


[--help]
Prints this help message.

[-c|--clobber]
Overwrite output files even if they already exist.

[(-o|--output) <output>]
The path to the output folder. By default output files and logs are
created in the same directory as the input file.

file1 file2 … fileN
One or more paths to JSP files. Should not be absolute paths.

Unless you specify --clobber , Jsp2X will never overwrite existing files. For every input file it will create a converted output file and possibly a log file in the same directory of the input file unless the --output switch is specified. With --output <path> , output files are written to a directory structure underneath the directory specified by <path>. The directory structure will mimic the one of the input files and non-existing directories will be created on the fly as required. The base name of the output file will be derived from the input file using the following mapping between standard JSP page extensions and standard JSP document extensions:
Input extension 	Output extension
jsp 	jspx
tag 	tagx
jspf 	jspx

If the input file's extension doesn't match any of the ones listed in above table, Jsp2X will generate the output file name simply by appending .xml to the input file name.

Input file paths should always be relative paths. They must be relative paths if --output is specified. If they are relative paths they may start with './' but they don't need to, e.g. ./foo/bar.jsp is treated equivalent to foo/bar.jsp . JSP pages may include other JSP fragments. Jsp2X can handle this as long as the value of every include directive's uri attribute should point to the included file when prepending the uri value with the current working directory. In other words, you should

    * run Jsp2X from with the webapp directory of your source tree (usually src/main/webapp ) and
    * your JSP pages use context-relative URIs to refer to the included fragment, e.g. /WEB-INF/jsp/taglibs.jspf .

In all other cases Jsp2X will emit a warning and the conversion result might be incomplete.

A typical conversion session might look like this:

# cd src/main/webapp
# find -name "*.tag" -or -name "*.jsp" -or -name | 
  xargs java -jar jsp2x-VERSION-bin.jar --clobber
# cd ../../..


Jsp2X will print the total number of input files and the number of successfully converted input files. You will find as many log files as there are input files for which the conversion was unsuccessful. Read the log files and tweak the input pages or come running to me if you think you found a bug.

When converting the JSP pages in Provider Portal, I used a slightly more elaborate approach that yielded better diffs in SVN. The key to that approach is that I first renamed the JSP pages to their JSP document counterparts in one commit then replaced the content of the renamed file with its converted form in a second commit. The diff of the second commit lists all modifications made by Jsp2X allowing you to later go back and see what exactly it did. Here's a transcript of my conversion session (before you copy-and-paste it make sure you understand what's going on with all those find commands):

   1. Convert all JSP files into a separate temporary directory:

      # cd src/main/webapp
      # find -name "*.tag" -or -name "*.jsp" -or -name | 
        xargs java -jar jsp2x-VERSION-bin.jar --clobber --output temp


   2. Use find to generate a script that renames all JSP files:

      # find \( -name  -or -name "*.jspf" \) -and -printf | 
        sed -r "s/jspf?\$/jspx/" | bash
      # find -name "*.tag" -and -printf "svn rename %p %p\\n" | sed -r  | bash
      # svn commit -m "…"

   3. Use find to generate another script that copies the converted files from the tempotary directory to the real one:

      # cd temp/WEB-INF
      # find \( -name "*.tagx" -or -name "*.jspx" \) -and -printf  | sed s/\\/\\.\\//\\// | bash
      # cd ../..
      # rm -r temp
      # svn commit -m "…"

How it works

Jsp2X is split into four main parts: the parser, the transformer, the dumper and the main class with some glue code for command line and file management. The parser was hardest to get right because unlike a true JSP page parser it can't just scan the template text for JSP constructs. The transformer needs a complete tree structure of the input including the tags in the template text. So the parser has to scan for markup in the template textand JSP constructs at the same time. The input is not just simple markup with elements, attributes and some text. JSP constructs can literally occur anywhere in the document. The parser needs to accept input like this:

<a href="<c:url value="foo"/>" ${isBold ? 'class="bold"' : ''}>

This is an <a> element with an href attribute whose value is a <c:url> tag which has more attributes. Next to the href attribute there is an EL expression with a conditional class attribute. I refer to these constructs as being recursive because tags are allowed within tags (this is different to elements occurring in the body of other elements). Also note the nesting of the quotation marks. As you can see, parsing this is not trivial. Luckily, I had a very powerful tool at hand: ANTLR. Given the grammar of an input language ANTLR generates the Java source code of a class that can parse the input language and turn it into an in-memory tree representing the input. So as long as you can come up with a grammar for the desired input, ANTLR generates a program that parses the input for you. ANTLR can generate source code for Java, C#, C and other languages. It supports complex LL(*) grammars (any context-free language if you know who Chomsky is) in which the decision about which grammar rule to apply can not be made by just looking a constant number of tokens ahead (it uses backtracking in conjunction with memoization to alleviate the exponential cost of backtracking). I am an ANTLR newbie so I expect my JSP grammar to have deficiencies.

The transformer is a simple recursive tree walker that can change, delete and add nodes during the walk. Most of the work is done in a first pass. It also detects and converts the afore-mentioned recursion in attributes and tags. The second pass combines consecutive PCDATA (i.e. text) nodes and escapes XML entities. The third pass attempts to detect insignificant whitespace. For example, it converts

<td>
    Foo
</td>

to

<td>
    <jsp:text>Foo<jsp:text>
<td>

The difference between the two fragments is that the first one would cause the JSP engine to emit HTML output that includes the whitespace:

<td>
    Foo
</td>

The second fragment on the other hand would emit

<td>Foo</td>

This is because the whitespace around "Foo" became whitespace-only text between tags and can be safely eliminated by the JSP engine. The text child of the <td> element in the first fragment contains both whitespace and non-whitespace. The JSP standard says that in JSP documents only text that exclusively consists of whitespace can be eliminated.

The dumper is a very simple XML serializer. After the transformer did its work, the tree is basically in XML form and serializing it is a trivial task. ANTLR supports tree parsing to some extent so I used that mechanism for the dumper.

There's not much to say about the main class, except maybe that it uses a neat little command line parser called JSAP.

yet another explanations,
http://download.oracle.com/javaee/1.4/tutorial/doc/JSPX3.html

Advertisements

weblogic application.xml

i just finished solving another simple task.

problem description:
there are three projects inside the application. Front_End, Pricing_Admin_Engine, and Help_Context.

deployment of previous two applications have no problem, since they are standard Java EE applications. deployment Help_Context have problems. As the project structure is

the root of this project is CFC_Static_Content, and the required resource is at CFC_Static_Content\cfc_static\help\db\enUS\content\cfc.xml
once deployed as it is, the url would be
CFC_Static_Content/cfc_static/help/db/enUS/content/cfc.xml, while required is /help/db/enUS/content/cfc.xml.

for some, this is a very simple problem, and the solution is also very simple, just add a META-INF folder, to contain new created application.xml, inside which specifiy as

<?xml version="1.0" encoding="UTF-8"?>
<application id="CFC" version="5"
	xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd">
	<display-name>CFC Static Content</display-name>
	<module id="WebModule_CFC_Help">
		<web>
			<web-uri>cfc_static/help</web-uri>
			<context-root>/help</context-root>
		</web>
	</module>
</application>

spring security

a new topics, on my way to master.

1. web.xml, define the secure filters. one special points, about “springSecurityFilterChain”, which is a special spring internal infrastructure bean created by the namespace to handle web security.
If you are familiar with pre-namespace versions of the framework, you can probably already guess roughly what’s going on here. The <http> element is responsible for creating a FilterChainProxy and the filter beans which it uses. Common problems like incorrect filter ordering are no longer an issue as the filter positions are predefined.>
as “http://static.springsource.org/spring-security/site/docs/3.1.x/reference/ns-config.html&#8221;.
2.

	<!-- This bean id should not be changed -->
	<bean id="authenticationProcessingFilter" scope="prototype"
		class="com.db.cfc.frontend.common.security.filter.AuthProcessinglFilter">
		<security:custom-filter position="PRE_AUTH_FILTER" />
		<property name="authenticationManager" ref="authenticationManager" />
	</bean>

	<bean id="exceptionTranslationFilter"
		class="org.springframework.security.ui.ExceptionTranslationFilter">
		<property name="authenticationEntryPoint" ref="authenticationEntryPoint" />
		<property name="accessDeniedHandler">
			<bean class="org.springframework.security.ui.AccessDeniedHandlerImpl">
				<property name="errorPage" value="/WEB-INF/jsp/error/AccessDenied.jsp" />
			</bean>
		</property>
	</bean>

	<bean id="authenticationEntryPoint"
		class="org.springframework.security.ui.preauth.PreAuthenticatedProcessingFilterEntryPoint" />

	<bean id="preAuthenticatedAuthenticationProvider" class="org.springframework.security.providers.preauth.PreAuthenticatedAuthenticationProvider">
		<security:custom-authentication-provider />
		<property name="preAuthenticatedUserDetailsService" ref="preAuthenticatedUserDetailsService" />
	</bean>

	<bean id="preAuthenticatedUserDetailsService" class="com.db.cfc.frontend.common.security.service.impl.UserDetailsService">
		<property name="profileService" ref="profileService" />
		<property name="securityService" ref="securityService" />
	</bean>

	<bean id="authenticationManager" class="org.springframework.security.providers.ProviderManager">
		<property name="providers">
			<list>
				<ref bean="preAuthenticatedAuthenticationProvider" />
			</list>
		</property>
	</bean>

inside, the application_context_security.xml, using the xmlns:security=”http://www.springframework.org/schema/security&#8221; namespace, to define the < http > configuration, would automatically create the springSecurityFilterChain, which is something like an alias to the filterChainProxy.

and the filter –> authenticationManager –> provider –> userDetailService configuration inside the application_context_security.xml, would configure corresponding beans.

in addition, there is something called, “entry-point”, which i need to continue investigate.

<!– ACL context configuration start –>
<security:http entry-point-ref=”authenticationEntryPoint”
auto-config=”false” session-fixation-protection=”none”
lowercase-comparisons=”false” access-denied-page=”/WEB-INF/jsp/error/AccessDenied.jsp”>

<!– Common to all roles, but authenticated –>
<security:intercept-url pattern=”/1/*.action”
access=”ROLE_BR_B_C_E,ROLE_BR_B_C_V,ROLE_BR_B_M_E,
ROLE_BR_B_M_V,ROLE_BR_S_C_E,
ROLE_BR_S_C_V,ROLE_BR_S_M_E,ROLE_BR_S_M_V,ROLE_DD_B_C_E,
ROLE_DD_B_C_V,ROLE_DD_B_M_E,
ROLE_DD_B_M_V,ROLE_DD_S_C_E,ROLE_DD_S_C_V,ROLE_DD_S_M_E,
ROLE_DD_S_M_V,
ROLE_SA_E,ROLE_SA_V,ROLE_CFC-SALES_V,ROLE_CFC-SALES_E” />
<security:anonymous />

</security:http>

<bean id=”exceptionTranslationFilter”
class=”org.springframework.security.ui.ExceptionTranslationFilter”>
<property name=”authenticationEntryPoint” ref=”authenticationEntryPoint” />
<property name=”accessDeniedHandler”>
<bean class=”org.springframework.security.ui.AccessDeniedHandlerImpl”>
<property name=”errorPage” value=”/WEB-INF/jsp/error/AccessDenied.jsp” />
</bean>
</property>
</bean>

<bean id=”authenticationEntryPoint”
class=”org.springframework.security.ui.preauth.PreAuthenticatedProcessingFilterEntryPoint” /

in addition, http://heraclitusonsoftware.wordpress.com/software-development/spring/simple-web-application-with-spring-security-part-13/#comment-1882
which explains some part of my foundings, saved my effort for typing. ^_^

addon, i found out its FilterSecurityInterceptor.java, which maintains the security configurations inside the applcation_context_security.xml, as
<security:http entry-point-ref=”authenticationEntryPoint”
auto-config=”false” session-fixation-protection=”none”
lowercase-comparisons=”false” access-denied-page=”/WEB-INF/jsp/error/AccessDenied.jsp”>

<!– Common to all roles, but authenticated –>
<security:intercept-url pattern=”/1/*.action”
access=”ROLE_BR_B_C_E,ROLE_BR_B_C_V,ROLE_BR_B_M_E,ROLE_BR_B_M_V,ROLE_BR_S_C_E,
ROLE_BR_S_C_V,ROLE_BR_S_M_E,ROLE_BR_S_M_V,ROLE_DD_B_C_E,ROLE_DD_B_C_V,ROLE_DD_B_M_E,
ROLE_DD_B_M_V,ROLE_DD_S_C_E,ROLE_DD_S_C_V,ROLE_DD_S_M_E,ROLE_DD_S_M_V,
ROLE_SA_E,ROLE_SA_V,ROLE_CFC-SALES_V,ROLE_CFC-SALES_E” />
<security:anonymous />

</security:http>

and this same class, FilterSecurityInterceptor,during its doFilter() process, it would call its super class AbstractSecurityInterceptor ‘s method AbstractSecurityInterceptor.beforeInvocation(), where the xml configuration checks against the userDetails data.

and


  Abstract class that implements security interception for secure objects.
  

The AbstractSecurityInterceptor will ensure the proper startup configuration of the security interceptor. It will also implement the proper handling of secure object invocations, namely:

  1. Obtain the {@link Authentication} object from the {@link SecurityContextHolder}.
  2. Determine if the request relates to a secured or public invocation by looking up the secure object request against the {@link ObjectDefinitionSource}.
  3. For an invocation that is secured (there is a ConfigAttributeDefinition for the secure object invocation):
    1. If either the {@link org.springframework.security.Authentication#isAuthenticated()} returns false, or the {@link #alwaysReauthenticate} is true, authenticate the request against the configured {@link AuthenticationManager}. When authenticated, replace the Authentication object on the SecurityContextHolder with the returned value.
    2. Authorize the request against the configured {@link AccessDecisionManager}.
    3. Perform any run-as replacement via the configured {@link RunAsManager}.
    4. Pass control back to the concrete subclass, which will actually proceed with executing the object. A {@link InterceptorStatusToken} is returned so that after the subclass has finished proceeding with execution of the object, its finally clause can ensure the AbstractSecurityInterceptor is re-called and tidies up correctly.
    5. The concrete subclass will re-call the AbstractSecurityInterceptor via the {@link #afterInvocation(InterceptorStatusToken, Object)} method.
    6. If the RunAsManager replaced the Authentication object, return the SecurityContextHolder to the object that existed after the call to AuthenticationManager.
    7. If an AfterInvocationManager is defined, invoke the invocation manager and allow it to replace the object due to be returned to the caller.
  4. For an invocation that is public (there is no ConfigAttributeDefinition for the secure object invocation):
    1. As described above, the concrete subclass will be returned an InterceptorStatusToken which is subsequently re-presented to the AbstractSecurityInterceptor after the secure object has been executed. The AbstractSecurityInterceptor will take no further action when its {@link #afterInvocation(InterceptorStatusToken, Object)} is called.
  5. Control again returns to the concrete subclass, along with the Object that should be returned to the caller. The subclass will then return that result or exception to the original caller.
@author Ben Alex @version $Id: AbstractSecurityInterceptor.java 3046 2008-05-09 18:09:56Z luke_t $

i love spring security, its cool.!
http://static.springsource.org/spring-security/site/docs/3.0.x/reference/technical-overview.html#tech-intro-authentication

there are in general two steps, authentication and authorisation.
1. authentication is generally done by authenticationManager, eg, org.springframework.security.providers.ProviderManager, together with providers, userDetailService.
2. authorisation is generally done by AbstractSecurityInterceptor, which would retrieve the configureAttributes, like ROLE_A, ROLE_B in <intercept-url pattern=’/secure/**’ access=’ROLE_A,ROLE_B’/>, for example; and using a accessDecisionManager to decide, the previously retrieved authentication object against the configAttributes.

and these two postes, are equally cool,
http://asahu05.wordpress.com/2010/07/20/spring-acegi-security-in-flex-application

and http://enlightensoft.wordpress.com/2010/04/09/spring-security-3-0-part-1/

the threadlocal java API document is confusing

This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its get or set method) has its own, independently initialized copy of the variable. ThreadLocal instances are typically private static fields in classes that wish to associate state with a thread (e.g., a user ID or Transaction ID).

For example, the class below generates unique identifiers local to each thread. A thread’s id is assigned the first time it invokes UniqueThreadIdGenerator.getCurrentThreadId() and remains unchanged on subsequent calls.

import java.util.concurrent.atomic.AtomicInteger;

public class UniqueThreadIdGenerator {

private static final AtomicInteger uniqueId = new AtomicInteger(0);

private static final ThreadLocal < Integer > uniqueNum =
new ThreadLocal < Integer > () {
@Override protected Integer initialValue() {
return uniqueId.getAndIncrement();
}
};

public static int getCurrentThreadId() {
return uniqueId.get();
}
} // UniqueThreadIdGenerator

Each thread holds an implicit reference to its copy of a thread-local variable as long as the thread is alive and the ThreadLocal instance is accessible; after a thread goes away, all of its copies of thread-local instances are subject to garbage collection (unless other references to these copies exist).

the correct method, should be

public static int getCurrentThreadId() {
return uniqueNum.get();
}

class loader

http://objectmix.com/weblogic/509088-app-inf-lib-app-inf-classes-classloading.html

i think the problem in above post, is related to the fact, that
Classes loaded by Bootstrap class loader have no visibility into classes
loaded by its descendants (ie Extensions and Systems class loaders).
The classes loaded by system class loader have visibility into classes loaded
by its parents (ie Extensions and Bootstrap class loaders).
If there were any sibling class loaders they cannot see classes loaded by
each other. They can only see the classes loaded by their parent class
loader. For example Sibling1 class loader cannot see classes loaded by
Sibling2 class loader
Both Sibling1 and Sibling2 class loaders have visibilty into classes loaded
by their parent class loaders (eg: System, Extensions, and Bootstrap)classloader

jasper report

the own official web site provides the best documentation.

Compiling Report Designs
(back to top)
A report design is represented by a JRXML file that has the structure defined in the jasperreport.xsd file, or by an in-memory JasperDesign object. In order to generate reports according to such a report design, this needs to be compiled. Report design compilation can be done using the compileReportXXX() methods exposed by the JasperCompileManager class and results into a *.jasper file or a JasperReport object.
When compiling a report design, the engine first performs a validation to ensure that the template (JasperDesign) is consistent and then transforms all the report expressions in a ready-to-evaluate form, storing them inside the resulting compiled report template (JasperReport or .jasper file).
This transformation implies either the on-the-fly compilation of a Java class file that will be associated with the report template, or the generation of a Groovy or BeanShell script to use when evaluating report expressions during the report filling process, depending on the specified report expression language for the report (see the language property of a report template).

Before reading more about report compilation, you should understand when do you need to compile your report templates and which is the best way to do it by reading the following FAQ:
When should I compile my report templates and how?.

To make report design compilation process as flexible as possible, a special interface called JRCompiler was introduced.
As seen above, there are several different types of classes implementing this interface shipped with the library:
1. Java creport compilers. These report compilers generate and compile a Java class containing the report expressions evaluating methods; \\
2. The Groovy report compiler that generates a script for runtime report expressions evaluation.
3. The BeanShell report compiler that generates a script for runtime report expressions evaluation.

For more details about report compilation, check The Ultimate Guide to JasperReports.

Ant task for compiling report designs

Since the report design compilation process is more like a design-time job than a runtime one, an Ant task was provided with the library in order to simplify development.
This Ant task is implemented by the JRAntCompileTask and is very similar to the Ant built-in task, as far as syntax and behavior are concerned.
The report design compilation task can be declared like this, in a project’s build.xml file:

In the example above, the lib folder should contain the jasperreports-.jar file along with its required libraries (including the jdt-compiler-.jar, which is the recommended report compiler, in case you use Java as the report expression language).
This user-defined Ant task can be then used to compile multiple JRXML report design files in a single operation, by specifying the root directory that contains those files or by selecting them using file patterns. Attributes of the report design compilation task:
Attribute Description
srcdir Location of the JRXML report design files to compile. Required unless nested elements are present.
destdir Location to store the compiled report design files (the same as the source directory by default).
compiler Name of the class that implements the JRCompiler interface (optional).
xmlvalidation Flag to indicate if the XML validation should be performed on the source report design files (true by default).
tempdir Location to store the temporary generated files (the current working directory by default).
keepjava Flag to indicate if the temporary Java files generated on-the-fly should be kept and not deleted automatically (false by default).

The report design compilation task supports nested and elements, just like the Ant built-in task.

To see this in action, check the demo/samples/antcompile sample provided with the project source files.

Viewing a report design

Report designs can be viewed using the JasperDesignViewer application.
In its main() method, it receives the name of the file which contains the report design to view.
This can be the JRXML file itself, or the compiled report design (*.jasper file).

Filling Reports
(back to top)
A compiled report design can be used to generate reports by calling the fillReportXXX() methods of the JasperFillManager class. There are two flavours of the fill methods in this fa?ade class. Some receive a java.sql.Connection object as the third parameter, and the others receive a JRDataSource object instead.

This is because most of the times reports are filled with data from a relational database to which we connect through JDBC and is very convenient to have the SQL query inside the report template itself. The JasperReports engine can use the connection passed in and execute the SQL query, thus producing a report data source for filling the report.
In cases where data is available in other forms, the fill methods receiving a data source are to be used.

View, Print and Export Reports
(back to top)
Generated reports can be viewed using the JasperViewer application. In its main() method, it receives the name of the file which contains the report to view.

Generated reports can be printed using the printReport(), printPage() or printPages() static methods exposed by the JasperPrintManager class.

After having filled a report, we can also export it in PDF, HTML or XML format using the exportReportXXX() methods of the JasperExportManager class.

Parameters
(back to top)
Parameters are object references that are passed-in to the report filling operations. They are very useful for passing to the report engine data that it can not normally find in its data source. For example, we could pass to the report engine the name of the user that has launched the report filling operation if we want it to appear on the report, or we could dynamically change the title of our report.

An important aspect is the use of report parameters in the query string of the report, in order to be able to further customize the data set retrieved from the database. Those parameters could act like dynamic filters in the query that supplies data for the report.
Declaring a parameter in a report design is very simple and it requires specifying only its name and its class:

<parameter name=”ReportTitle” class=”java.lang.String”/>
<parameter name=”MaxOrderID” class=”java.lang.Integer”/>
<parameter name=”SummaryImage” class=”java.awt.Image”/>

There are two possible ways to use parameters in the query:

1. The parameters are used like normal java.sql.PreparedStatement parameters using the following syntax:

SELECT * FROM Orders WHERE CustomerID = $P{OrderCustomer}

2. Sometimes is useful to use parameters to dynamically modify portions of the SQL query or to pass the entire SQL query as a parameter to the report filling routines. In such a case, the syntax differs a little, like in the following example:

SELECT * FROM Orders ORDER BY $P!{OrderByClause}

There are also the following built-in system parameters, ready to use in expressions:

Data Source
(back to top)
JasperReports support various types of data sources using a special interface called JRDataSource.
There is a default implementation of this interface, the JRResultSetDataSource class, which wraps a java.sql.ResultSet object. It allows the use of any relational database through JDBC.
When using a JDBC data source, you could pass a java.sql.Connection object to the report filling operations and specify the query in the report definition itself (see the <queryString> element in the XML file) or could create a new instance of the JRResultSetDataSource by supplying the java.sql.ResultSet object directly.
With other types of data sources, things should not be different and all you have to do is to implement the JRDataSource interface, or use one of the implemetations that are shipped with the JasperReports library to wrap in-memory collections or arrays of JavaBeans, CSV or XML files, etc.

Fields
(back to top)
Report fields represent the only way to map data from the data source into the report generating routines. When the data source of the report is a java.sql.ResultSet, all fields must map to corresponding columns in the java.sql.ResultSet object. That is, they must have the same name as the columns they map and a compatible type.
For example:
If we want to generate a report using data retrieved from the table Employees, which has the following structure:
Column Name Datatype Length
EmployeeID int 4
LastName varchar 20
FirstName varchar 10
HireDate datetime 8
We can define the following fields in our report design:

<field name=”EmployeeID” class=”java.lang.Integer”/>
<field name=”LastName” class=”java.lang.String”/>
<field name=”FirstName” class=”java.lang.String”/>
<field name=”HireDate” class=”java.util.Date”/>

If we declare a field that does not have a corresponding column in the java.sql.ResultSet, an exception will be thrown at runtime. Columns present in the java.sql.ResultSet object that do not have corresponding fields in the report design do not affect the report filling operations, but they also won’t be accessible.

Expressions
(back to top)
Expressions are a powerful feature of JasperReports. They can be used for declaring report variables that perform various calculations, for data grouping on the report, to specify report text fields content or to further customize the appearance of objects on the report.
Basically, all report expressions are Java expressions that can reference report fields and report variables.
In an XML report design there are several elements that define expressions: <variableExpression>, <initialValueExpression>, <groupExpression>, <printWhenExpression>, <imageExpression> and <textFieldExpression>.
In order to use a report field reference in an expression, the name of the field must be put between $F{ and } character sequences.
For example, if we want to display in a text field, on the report, the concatenated values of two fields, we can define an expression like this one:

<textFieldExpression>
$F{FirstName} + ” ” + $F{LastName}
</textFieldExpression>

The expression can be even more complex:

<textFieldExpression>
$F{FirstName} + ” ” + $F{LastName} + ” was hired on ” +
(new SimpleDateFormat(“MM/dd/yyyy”)).format($F{HireDate}) + “.”
</textFieldExpression>

To reference a variable in an expression, we must put the name of the variable between $V{ and } like in the example below:

<textFieldExpression>
“Total quantity : ” + $V{QuantitySum} + ” kg.”
</textFieldExpression>

There is an equivalent syntax for using parameters in expressions. The name of the parameter should be put between $P{ and } like in the following example:

<textFieldExpression>
“Max Order ID is : ” + $P{MaxOrderID}
</textFieldExpression>

Variables
(back to top)
A Report variable is a special objects build on top of an expression. Variables can be used to simplify the report design by declaring only once an expression that is heavily used throughout the report design or to perform various calculations on the corresponding expressions.
In its expression, a variable can reference other report variables, but only if those referenced variables were previously defined in the report design. So the order in which the variables are declared in a report design is important.
As mentioned, variables can perform built-in types of calculations on their corresponding expression values like : count, sum, average, lowest, highest, variance, etc.
A variable that performs the sum of the Quantity field should be declared like this:

<variable name=”QuantitySum”
class=”java.lang.Double” calculation=”Sum”>
<variableExpression>$F{Quantity}</variableExpression>
</variable>

For variables that perform calculation we can specify the level at which they are reinitialized. The default level is Report and it means that the variable is initialized only once at the beginning of the report and that it performs the specified calculation until the end of the report is reached. But we can choose a lower level of reset for our variables in order to perform calculation at page, column or group level.
For example, if we want to calculate the total quantity on each page, we should declare our variable like this:

<variable name=”QuantitySum” class=”java.lang.Double”
resetType=”Page” calculation=”Sum”>
<variableExpression>$F{Quantity}</variableExpression>
<initialValueExpression>new Double(0) </initialValueExpression>
</variable>

Our variable will be initialized with zero at the beginning of each new page.
There are also the following built-in system variables, ready to use in expressions:

PAGE_NUMBER
COLUMN_NUMBER
REPORT_COUNT
PAGE_COUNT
COLUMN_COUNT
GroupName_COUNT

Documentation pending…

Report Sections
(back to top)
When building a report design we need to define the content and the layout of its sections. The entire structure of the report design is based on the following sections:

<background>
<title>
<pageHeader>
<columnHeader>
<groupHeader>
<detail>
<groupFooter>
<columnFooter>
<pageFooter>
<lastPageFooter>
<summary>
<noData>

Sections are portions of the report that have a specified height and width and can contain report objects like lines, rectangles, images or text fields.
When declaring the content and layout of a report section in an XML report design we use the generic element <band>.
This is how a page header declaration should look. It contains only a line object and a static text:

<pageHeader>
<band height=”30″>
<rectangle>
<reportElement x=”0″ y=”0″ width=”555″ height=”25″/>
<graphicElement/>
</rectangle>
<staticText>
<reportElement x=”0″ y=”0″ width=”555″ height=”25″/>
<textElement textAlignment=”Center”>
<font fontName=”Helvetica” size=”18″/>
</textElement>
<text>Northwind Order List</text>
</staticText>
</band>
</pageHeader>

Subreports
(back to top)
Subreports are an important feature for a report-generating tool. They allow the creation of more complex reports and simplify the design work.
Subreports are very useful when creating master-detail type of reports, or when the structure of a single report is not sufficient to describe the complexity of the desired output document.
A subreport is in fact a normal report incorporated into another report. One can overlap subreports or create subreports containing subreports themselves, up to any nesting level. Any report template can be used as a subreport when incorporated into another report, without anything inside it having to change.
Like other report elements, the subreport element has an expression that is evaluated at runtime in order to obtain the source of the JasperReport object to load.
There are two ways to supply parameter values to a subreport. First, you can use the <parametersMapExpression> element which introducest the expression that will be evaluated to produce the specified parameters map. And/or you can supply the parameters individually using a <subreportParameter> element for each relevant parameter. When using simultaneously both ways to supply parameters the parameters values specified using <subreportParameter> will override values specified with <parametersMapExpression>.
Subreports require a data source in order to generate their content, just like normal reports, behave in the same way, and expect to receive the same kind of input when they are being filled.
Values calculated by a subreport can be returned to the parent report. More specifically, after a subreport is filled, values of the subreport variables can be either copied or accumulated (using an incrementer) to variables of the caller report (master variables).
See the Subreport sample for details.

from : http://jasperforge.org/uploads/publish/jasperreportswebsite/trunk/tutorial.html