tag:blogger.com,1999:blog-14685321516425114962024-03-08T10:26:09.667-08:00That Java ThingJava tips for serious tinkerersUnknownnoreply@blogger.comBlogger8125tag:blogger.com,1999:blog-1468532151642511496.post-65372792968753877682014-09-09T06:10:00.002-07:002016-10-25T05:36:49.904-07:00How to make an asynchronous processor in Apache Camel for generating and streaming files<div dir="ltr" style="text-align: left;" trbidi="on">
<p>
We've had a case where we needed to generate a PDF file and stream it back to the client from Camel. The PDF generating library expects an <span class="snippet">OutputStream</span> to write to, and as a file can grow big, it was important not to buffer an entire stream in memory.
While Camel already provides many options when it comes to concurrency, they are centered on invoking a route asynchronously, which was not (or at least not nicely) applicable to our case as we want only a part of the logic to run in a separate thread. We needed an asynchronous processor. An interface <span class="snippet">AsyncProcessor</span> already exists, but it only provides a callback to notify the caller of job done, but no actual mechanism to execute logic asynchronously. This needs to be done manually, but luckily, Camel does offer an easy way to create thread pools and use them to submit asynchronous tasks.
To create a thread pool, add a stanza similar to the following into Camel's Spring configuration, inside the <span class="snippet">camelContext</span>:
<pre name="code" class="brush: xml">
<threadPool id="smallPool" threadName="pdfWriter"
poolSize="5" maxPoolSize="30" maxQueueSize="50"/>
</pre>
</p>
<p>
This pool can then be used as normal to invoke routes asynchronously:
<pre name="code" class="brush: xml">
<route>
<from uri="direct:start"/>
<to uri="log:start"/>
<threads executorServiceRef="smallPool">
<to uri="log:hello"/>
</threads>
</route>
</pre>
</p>
<p>
but this is not what we're after. Instead, we can inject this pool into an <span class="snippet">AsyncProcessor</span> where we can submit a task to it. In the following example, the processor with create an instance of a <span class="snippet"><a href="http://blog.ostermiller.org/convert-java-outputstream-inputstream">CircularByteBuffer</a></span> and give its <span class="snippet">OutputStream</span> to the PDF generation process running in a separate thread to write to, and immediately return the associated <span class="snippet">InputStream</span> as a response (without blocking or buffering everything) to be consumed by the client.
<pre name="code" class="brush: java">
@Component
public class PdfGenerationProcessor implements AsyncProcessor {
@Resource(name="smallPool")
private ExecutorService smallPool;
@Override
public void process(Exchange exchange) throws Exception {
AsyncProcessorHelper.process(this, exchange); //Wrap synchronous invocations
}
@Override
public boolean process(Exchange exchange, AsyncCallback callback) {
CircularByteBuffer buffer = new CircularByteBuffer(1024 * 100); //Buffer a 100K
smallPool.submit(new PDFGenerator(exchange, callback, buffer.getOutputStream())); //Generate the PDF in a separate thread
exchange.getIn().setBody(buffer.getInputStream()); //Immediately return the stream for the client to read from
return false; //Signifies that the job will be performed asynchronously
}
private class PDFGenerator implements Runnable {
private Exchange exchange;
private AsyncCallback callback;
private OutputStream out;
private PDFGenerator(Exchange exchange, AsyncCallback callback, OutputStream out) {
this.exchange = exchange;
this.callback = callback;
this.out = out;
}
@Override
public void run() {
try {
generatePDF(out); //Actual logic for generating the file and writing it to the stream is here
} catch (Exception e) {
exchange.setException(e); //Async processors must not throw exceptions and must add them to the Exchange instead
} finally {
// callback must be invoked
callback.done(true);
//Cleanup, close streams etc.
try{out.flush(); out.close();} catch(Exception e) {/*ignore*/}
}
}
}
}
</pre>
</p>
<p>
<h3>References</h3>
<ul>
<li>
The library used here (<span class="snippet">CircularByteBuffer</span>) is a convenient implementation of piped streams (see more <a href="http://ostermiller.org/convert_java_outputstream_inputstream.html">here</a>). To use it, add this to Maven:
<pre name="code" class="brush: xml">
<dependency>
<groupId>org.ostermiller</groupId>
<artifactId>utils</artifactId>
<version>1.07.00</version>
</dependency>
</pre>
</li>
<li>
<a href="http://www.manning.com/ibsen/">Camel in Action</a>, chapter 10 has very good guides for concurrency in Camel
</li>
</ul>
</p>
</div>Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-1468532151642511496.post-61181174465188928122014-07-05T10:08:00.002-07:002016-05-31T04:12:55.898-07:00Spring Security Run-As example using annotations and namespace configuration<div dir="ltr" style="text-align: left;" trbidi="on">
<p>
Spring Security offers an authentication replacement feature, often referred to as Run-As, that can replace the current user's authentication (and thus permissions) during a single secured object invocation. Using this feature makes sense when a backend system invoked during request processing requires different privileges than the current application.
<br/>
For example, an application might want to expose a financial transaction log to the currently logged in user, but the backend system that provides it only permits this action to the members of a special "auditor" role. The application can not simply assign this role to the user as that would potentially permit them to execute other restricted actions. Instead, the user can be given this right exclusively for viewing their transaction log.
</p>
Only two classes are used to implement this feature. Instances of <span class="snippet">RunAsManager</span> are tasked with producing the actual replacement authentication tokens. A sensible default implementation is already provided by Spring Security.
As with other types of authentication, it is also necessary to register an instance of an appropriate <span class="snippet">AuthenticationProvider</span>.
<pre name="code" class="brush: xml">
<bean id="runAsManager"
class="org.springframework.security.access.intercept.RunAsManagerImpl">
<property name="key" value="my_run_as_key"/>
</bean>
<bean id="runAsAuthenticationProvider"
class="org.springframework.security.access.intercept.RunAsImplAuthenticationProvider">
<property name="key" value="my_run_as_key"/>
</bean>
</pre>
Tokens produced by <span class="snippet">runAsManager</span> are signed with the provided key (<span class="snippet">my_run_as_key</span> in the example above) and are later checked against the same key by <span class="snippet">runAsAuthenticationProvider</span>, in order to mitigate the risk of fake tokens being provided. These keys can have any value, but need to be the same in both objects. Otherwise, <span class="snippet">runAsAuthenticationProvider</span> will reject the produced tokens as invalid.
<p>
If an instance is registered, <span class="snippet">RunAsManager</span> will be invoked by <span class="snippet">AbstractSecurityInterceptor</span> for every intercepted object invocation for which the user has already been given access. If <span class="snippet">RunAsManager</span> returns a token, this token will be used be used instead of the original one for the duration of the invocation, thus granting the user different privileges. There are two key points here. <b>In order for the authentication replacement feature to do anything, the call has to actually be secured (and thus intercepted), and the user has to already have been granted access.</b>
</p>
To register a <span class="snippet">RunAsManager</span> instance with the method security interceptor, something similar to the following is needed:
<pre name="code" class="brush: xml">
<global-method-security secured-annotations="enabled" run-as-manager-ref="runAsManager"/>
</pre>
Now, all methods secured by the <span class="snippet">@Secured</span> annotation will be able to trigger <span class="snippet">RunAsManager</span>. One important point here is that <b><span class="snippet">global-method-security</span> will only work in the Spring context in which it is defined</b>. In Spring MVC applications, there usually are two Spring contexts: the parent context, attached to <span class="snippet">ContextLoaderListener</span>, and the child context, attached to <span class="snippet">DispatcherServlet</span>. <b>To secure <span class="snippet">Controller</span> methods in this way, <span class="snippet">global-method-security</span> must be added to <span class="snippet">DispatcherServlet</span>'s context.</b> To secure methods in beans not in this context, <span class="snippet">global-method-security</span> should also be added to <span class="snippet">ContextLoaderListener</span>'s context. <b>Otherwise, security annotations will be ignored.</b>
<p>
The default implementation of <span class="snippet">RunAsManager</span> (<span class="snippet">RunAsManagerImpl</span>) will inspect the secured object's configuration and if it finds any attributes prefixed with <span class="snippet">RUN_AS_</span>, it will create a token identical to the original, with the addition of one new <span class="snippet">GrantedAuthorty</span> per <span class="snippet">RUN_AS_</span> attribute found. The new <span class="snippet">GrantedAuthority</span> will be a role (prefixed by <span class="snippet">ROLE_</span> by default) named like the found attribute without the <span class="snippet">RUN_AS_</span> prefix.
</p>
<p>
So, if a user with a role <span class="snippet">ROLE_REGISTERED_USER</span> invokes a method annotated with <span class="snippet">@Secured({"ROLE_REGISTERED_USER","RUN_AS_AUDITOR"})</span>, e.g.
<pre name="code" class="brush: java">
@Controller
public class TransactionLogController {
@Secured({"ROLE_REGISTERED_USER","RUN_AS_AUDITOR"}) //Authorities needed for method access and authorities added by RunAsManager prefixed with RUN_AS_
@RequestMapping(value = "/transactions", method = RequestMethod.GET) //Spring MVC configuration. Not related to security
@ResponseBody //Spring MVC configuration. Not related to security
public List<Transaction> getTransactionLog(...) {
... //Invoke something in the backend requiring ROLE_AUDITOR
{
... //User does not have ROLE_AUDITOR here
}
</pre>
the resulting token created by <span class="snippet">RunAsManagerImpl</span> with be granted <span class="snippet">ROLE_REGISTERED_USER</span> and <span class="snippet">ROLE_AUDITOR</span>. Thus, the user will also be allowed actions, normally reserved for <span class="snippet">ROLE_AUDITOR</span> members, during the current invocation, permitting them, in this case, to access the transaction log.
</p>
To enable <span class="snippet">runAsAuthenticationProvider</span>, register it as usual:
<pre name="code" class="brush: xml">
<authentication-manager alias="authenticationManager">
<authentication-provider ref="runAsAuthenticationProvider"/>
... other authentication-providers used by the application ...
</authentication-manager>
</pre>
This is all that is necessary to have the default implementation activated.
<p>
Still, this setting will not work for methods secured by <span class="snippet">@PreAuthorize</span> and <span class="snippet">@PostAuthorize</span> annotations as their configuration attributes are differently evaluated (they are SpEL expressions and not a simple list or required authorities like with <span class="snippet">@Secured</span>) and will not be recognized by <span class="snippet">RunAsManagerImpl</span>.
For this scenario to work, a custom <span class="snippet">RunAsManager</span> implementation is required, as, at least at the time of writing, no applicable implementation is provided by Spring.
</p>
<p><h2>A custom <span class="snippet">RunAsManager</span> implementation for use with <span class="snippet">@PreAuthorize/@PostAuthorize</span></h2></p>
<p>
A convenient implementation relying on a custom annotation is provided below:
<pre name="code" class="brush: java">
public class AnnotationDrivenRunAsManager extends RunAsManagerImpl {
@Override
public Authentication buildRunAs(Authentication authentication, Object object, Collection<ConfigAttribute> attributes) {
if(!(object instanceof ReflectiveMethodInvocation) || ((ReflectiveMethodInvocation)object).getMethod().getAnnotation(RunAsRole.class) == null) {
return super.buildRunAs(authentication, object, attributes);
}
String roleName = ((ReflectiveMethodInvocation)object).getMethod().getAnnotation(RunAsRole.class).value();
if (roleName == null || roleName.isEmpty()) {
return null;
}
GrantedAuthority runAsAuthority = new SimpleGrantedAuthority(roleName);
List<GrantedAuthority> newAuthorities = new ArrayList<GrantedAuthority>();
// Add existing authorities
newAuthorities.addAll(authentication.getAuthorities());
// Add the new run-as authority
newAuthorities.add(runAsAuthority);
return new RunAsUserToken(getKey(), authentication.getPrincipal(), authentication.getCredentials(),
newAuthorities, authentication.getClass());
}
}
</pre>
</p>
This implementation will look for a custom <span class="snippet">@RunAsRole</span> annotation on a protected method (e.g. <span class="snippet">@RunAsRole("ROLE_AUDITOR")</span>) and, if found, will add the given authority (<span class="snippet">ROLE_AUDITOR</span> in this case) to the list of granted authorities.
<span class="snippet">RunAsRole</span> itself is just a simple custom annotation:
<pre name="code" class="brush: java">
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface RunAsRole {
String value();
}
</pre>
This new implementation would be instantiated in the same way as before:
<pre name="code" class="brush: xml">
<bean id="runAsManager"
class="org.springframework.security.access.intercept.RunAsManagerImpl">
<property name="key" value="my_run_as_key"/>
</bean>
</pre>
And registered in a similar fashion:
<pre name="code" class="brush: xml">
<global-method-security pre-post-annotations="enabled" run-as-manager-ref="runAsManager">
<expression-handler ref="expressionHandler"/>
</global-method-security>
</pre>
The expression-handler is always required for <span class="snippet">pre-post-annotations</span> to work. It is a part of the standard Spring Security configuration, and not related to the topic described here.
Both <span class="snippet">pre-post-annotations</span> and <span class="snippet">secured-annotations</span> can be enabled at the same time, but <a href="http://docs.spring.io/spring-security/site/docs/3.1.x/reference/ns-config.html#ns-method-security">should never be used in the same class</a>.
The protected controller method from above could now look like this:
<pre name="code" class="brush: java">
@Controller
public class TransactionLogController {
@PreAuthorize("hasRole('ROLE_REGISTERED_USER')") //Authority needed to access the method
@RunAsRole("ROLE_AUDITOR") //Authority added by RunAsManager
@RequestMapping(value = "/transactions", method = RequestMethod.GET) //Spring MVC configuration. Not related to security
@ResponseBody //Spring MVC configuration. Not related to security
public List<Transaction> getTransactionLog(...) {
... //Invoke something in the backend requiring ROLE_AUDITOR
{
... //User does not have ROLE_AUDITOR here
}
</pre>
</div>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-1468532151642511496.post-4912863101068635452012-12-19T14:16:00.002-08:002016-05-31T05:44:25.285-07:00Varnish Cache and remember-me cookies<div dir="ltr" style="text-align: left;" trbidi="on">
<p>
Automatically authenticating a previously logged in user upon their next visit (a feature often called "remember me") is an established Internet norm. While the exact implementations vary, they always rely on a special cookie that is set on the client and later recognized as a token signifying the client should be logged in automatically.
</p>
<p><h3>The problem</h3></p>
<p>
The cookie solution is perfectly fine, but in some environments, where cookies carry additional significance, it might be a source of problems. One such example is when the server is sitting behind a caching solution, such as Varnish. By default, Varnish will let all cookie-carrying requests pass right through it, without doing any processing or caching. This is a very sensible default behavior as it ensures that no personalized content will end up cached and returned to the wrong user, potentially revealing sensitive information. On the other hand, it also means that all clients sending any cookies (remember-me cookies included) will not benefit from the acceleration provided by the cache, nor will the server benefit from the decreased load in these cases as it will get hit every time. This will, of course, occur even if the cookies carry no information used for personalization of the content (as is the case with the remember-me cookie). Luckily, Varnish permits a very fine-grained handling of requests and responses through its excellent domain-specific configuration language, VCL. Yet, simply configuring Varnish to normally process requests carrying (only) the remember-me cookie is not a solution. The initial request carrying the remember-me cookie must pass through the cache and reach the application, so that the authentication process can take place, but all subsequent requests within the same session can be safely intercepted by Varnish (as long as they do not carry some other cookies with personalization info).
</p>
<p>
The problem that arises is how to distinguish the initial from all subsequents requests within the same session. Also, it must be taken into account that it is not predictable which URL within the application a cookie-carrying user will visit first. The user might visit the home page first, but might also land on some bookmarked page, or one they were sent to by a search engine. Checking the request for the presence of a session cookie might be enough, depending on whether this cookie is a temporary one or not. If it is temporary (and thus lost when the browser closes), this solution is probably enough. If the session cookie is persistent, it might get sent even after it had already expired, so its presence is not enough to determine whether the user has an active session.
</p>
<p><h3>A solution</h3></p>
<p>
One easy way to side-step all this complexity is to introduce an additional surely-temporary cookie which can be used as a flag indicating that the user has already signed in and that the request can be safely intercepted.
Since this is a Java blog, the proposed solution will be demonstrated utilizing Spring Security, the platform's de facto standard security framework, but the general principle is reusable in any technology.
Spring Security allows custom logic to fire after a successful log-in by implementing and registering an <span class="snippet">AuthenticationSuccessHandler</span>. This is exactly the place where the new cookie should be added to the response.
</p>
<p><h3>Example</h3></p>
<p>
As with everything else in Spring, there are multiple ways to register a custom handler, but the most usual way is to add <span class="snippet">authentication-success-handler-ref</span> attribute to the <span class="snippet">form-login</span> element in your security context configuration XML.
<pre name="code" class="brush: xml">
<form-login ... authentication-success-handler-ref="authenticationSuccessHandler" ... />
<beans:bean id="authenticationSuccessHandler" class="com.example.security.AuthenticationSuccessHandler"/>
</pre>
</p>
<p>
The class implementing the behavior should look similar to the following:
<pre name="code" class="brush: java">
public class AuthenticationSuccessHandler extends SavedRequestAwareAuthenticationSuccessHandler {
@Override
public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response, Authentication authentication) throws ServletException, IOException {
Cookie varnishCookie = new Cookie("VARNISH", "true");
varnishCookie.setPath("/");
varnishCookie.setMaxAge(-1); //It is very important that this cookie is temporary
response.addCookie(varnishCookie);
}
}
</pre>
</p>
<p>
On Varnish side, it is enough to allow the request to pass if the remember-me cookie is present and the flag-cookie absent (signifying that the current request is the initial one):
<p>
<pre name="code" class="brush: xml">
if (req.http.cookie !~ "VARNISH" && req.http.cookie ~ "REMEMBER_ME") {
return(pass);
}
</pre>
</p>
This way, requests that should auto log-in the user will succeed, while subsequent ones will be intercepted normally, benefiting from Varnish.
</p>
<p><h3>Notes</h3></p>
<p>
<ul>
<li>Since there is bound to be some part of the page that will be specific to the logged-in user, include that part using <a href="http://en.wikipedia.org/wiki/Edge_Side_Includes">ESI</a>, and exclude that URL from Varnish processing. Varnish supports <span class="snippet">ESI:include</span> so the setup is relatively simple.
</ul>
</p>
</div>Unknownnoreply@blogger.com7tag:blogger.com,1999:blog-1468532151642511496.post-54527182172340044842010-05-18T14:23:00.000-07:002016-05-31T05:45:18.575-07:00Conversation scope: CDI (JSR-299) vs Seam 2<p>CDI (JSR-299) is the new Java standard for contextual type-safe dependency injection and as such it is an integral part of Java EE 6 platform. Still, it will also work in any other environment, be it a servlet container or simple Java SE. It was insipered by Seam 2 (and what is therein known as 'bijection') and Guice.</p><h3>The Naming Game</h3><br /><p>Initially, CDI was known as WebBeans but the name had been changed before the spec was finalized. The reference implementation is called Weld but was also at some point called WebBeans. Yet again, that name is now obsolete as should not be used. Thus, WebBeans now refers to... well... nothing, so you're free to forget all about it. You will still see the old name popping up around the Web occasionally but it should fade into oblivion soon enough. More info on this story can be found at the very beginning of the reference documentation.<br /></p><h3>Conversations</h3><br />The existance of a built-in conversation scope in CDI will immediately lure most of the Seam 2 developers into a wrong assumption of familiarity. Wrong because although they serve the same purpose conversations in CDI and Seam 2 do not always behave identically.<br />While all Seam's conversations, both transient and long-running, invariantly survive redirects (unless specifically instructed not to through <span class="snippet">endBeforeRedirect=true</span>), conversations in CDI will survive only if they are promoted to long-running (through <span class="snippet">conversation.begin()</span> ) during the original request. A transient conversation will be destroyed at the end of the original request and a new one will be spawned for each redirect. In other words, without a long-running conversation, conversation scoped components in Seam 2 will behave (by default) as if they were in what you might know as flash scope from other frameworks and languages (this scope will also exist in Seam 3 with the related annotation <span class="snippet">@FlashScoped</span>). Under the same conditions, <span class="snippet">@ConversationScoped</span> beans in CDI will behave as if they were <span class="snippet">@RequestScoped</span>. In case a long-running conversation is present, the behavior will be the same in both Seam 2 and CDI.<br /><p>Reference documentation for some reason never states this explicitly so it can be very misleading for Seam 2 developers. Luckily though, there's <a href="http://seamframework.org/Seam3/Seam2ToSeam3MigrationNotes">a table</a> on the official site mapping Seam 2 scopes to their CDI equivalents where possible and gives brief description of the differences.</p><h3>Example</h3><br />To further clarify this (probably needlessly), let's illustrate with a simple example implemented both in Seam 2 and CDI.<br />In order to keep everything at a bare minimum, we'll just create a single component (or bean if you prefer), named <span class="snippet">MessageBean</span>, and a single Facelets view that accepts the new input and attempts to display the previous one after a redirect.<br />Note: Import and package statements are omitted from the following code listings.<br /><br /><strong>Seam 2 version</strong><br /><br /><span class="snippet">MessageBean</span> class:<br /><pre name="code" class="brush: java"><br />@Name("msg")<br />@Scope(ScopeType.CONVERSATION)<br />public class MessageBean implements Serializable {<br /><br /> private String message;<br /><br /> public String getMessage() {<br /> return message;<br /> }<br /><br /> public void setMessage(String message) {<br /> this.message = message;<br /> }<br /><br /> public String redir() {<br /> return "redir";<br /> }<br />}</pre><p><strong>CDI version</strong><br /></p><br />You'll notice a striking resemblance to the Seam 2 version.<br /><br /><span class="snippet">MesageBean</span> class:<br /><pre name="code" class="brush: java"><br />@Named("msg")<br />@ConversationScoped<br />public class MessageBean implements Serializable {<br /><br /> // @Inject Conversation conversation;<br /> private String message;<br /><br /> public String getMessage() {<br /> return message;<br /> }<br /><br /> public void setMessage(String message) {<br /> this.message = message;<br /> }<br /><br /> public String redir() {<br /> //if (conversation.isTransient())<br /> // conversation.begin();<br /> return "redir";<br /> }<br />}<br /><br /></pre><strong>Facelets view</strong> (the same in both cases):<br /><br />Note: Again, extra headers are omitted.<br /><br /><span class="snippet">input.xhtml</span>:<br /><pre name="code" class="brush: xml"><br /><html xmlns="http://www.w3.org/1999/xhtml"<br />xmlns:ui="http://java.sun.com/jsf/facelets"<br />xmlns:h="http://java.sun.com/jsf/html"<br />xmlns:f="http://java.sun.com/jsf/core"><br /><div><br />Previous input: #{msg.message}<br /></div><br /><br /><h:form><br /><h:inputText id="messageText" value="#{msg.message}" required="true"/><br /><h:commandButton id="redirectButton" value="Redirect" action="#{msg.redir}"/><br /></h:form><br /></html><br /></pre><strong>Configuration</strong> (the same in both cases):<br /><br /><span class="snippet">faces-config.xml</span>:<br /><pre name="code" class="brush: xml"><br /><navigation-rule><br /><navigation-case><br /><from-outcome>redir</from-outcome><br /><to-view-id>/input.xhtml</to-view-id><br /><redirect /><br /></navigation-case><br /></navigation-rule><br /></pre><br />If you were to execute both these examples, you'd soon realize the difference between the frameworks. While Seam 2 version keeps your input across the redirect and displays it on the next rendering, even without promoting the conversation, CDI will destroy the context on redirect leaving you with no message to display. Note that if the commented lines in the CDI version of <span class="snippet">MessageBean</span> were to be uncommented, thus promoting the conversation to a long-running one, the message would survive, together with the whole conversation context (which would afterwards be reused in the next cycle in this case). Normally, you'd also want a way to end the conversation at some point through <span class="snippet">conversation.end()</span> instead of waiting for the timeout (which is ultimately decided by the server).<br /><br /><h3>Download</h3><br />Below you can find both implementations as war files ready for deployment. The examples are meant to be deployed to JBoss AS so some tweaks (like adding Weld or any other CDI implementation jar to the classpath) might be needed in order to get it running on Tomcat or other servers/containers.<br /><br /><a href="http://www.drivehq.com/file/df.aspx/publish/veggen/PublicFolder/conversationsCDI.war">conversationCDI.war</a> (tested on JBoss AS 6)<br /><a href="http://www.drivehq.com/file/df.aspx/publish/veggen/PublicFolder/conversationsSeam.war">conversationsSeam.war</a> (tested on JBoss AS 5, does not work on JBoss AS 6 for some reason)<br /><br /><h3>References</h3><br /><a href="http://www.seamframework.com/Weld">Weld main site</a><br /><a href="http://docs.jboss.org/seam/latest/en-US/html/">Seam 2 tutorial</a>Unknownnoreply@blogger.com5tag:blogger.com,1999:blog-1468532151642511496.post-52196678800739926942010-03-14T16:00:00.001-07:002016-05-31T05:45:54.766-07:00Global transactions in SeamTransactions grew to be a necessity in most today's applications, and managing them grew to be a demanding task. If the application is complex enough it can evolve into a nightmare in its own right. Thus, offloading this task to a framework whenever possible is a very desirable approach.<br />Being a powerful feature-packed framework that it is, Seam offers exceptional support for transactional behavior that in many instances surpasses all others. One feature not seen in other frameworks are global transactions.<br /><br /><h3>The confusion</h3><br />This topic is regarded as somewhat arcane, despite being essentially simple. The reason for this is twofold. Firstly, the documentation regarding global transactions is relatively poor. Secondly, and more importantly, the exiting documentation does not call this feature <em>global transactions</em>, and this is the term used most widely over the internet (it was originally coined by Dan Allen is his book <em>Seam in Action</em>, often regarded as the "default" book for Seam).<br /><br /><h3>Clearing it up</h3><br />In essence, global transactions refer to the two or three transactions that wrap each request in Seam. The first one wraps JSF phases beginning with Restore View (for JTA transactions) or Invoke Application (for resource-local transactions), and ending just before Render Response. The second wraps all page actions (if they are used), and the third wraps the Render Response phase. During this final transaction, context flushing is disabled, effectively rendering the whole transaction read-only.<br />In this fashion, Seam accomplishes a couple of things:<ul><li>an error in page preparation or rendering will never role back a successfully executed business logic,</li> <br /><li>view rendering is executed atomically, which not only avoids opening and closing a transaction on every lazy initialization, but also guarantees isolation and guards against accidental changes of the state during this phase,</li><br /><li>page actions are executed atomically (with benefits similar to those mentioned above sans disabled context flushing).</li></ul><br />This way, Seam effectively does away with a good portion of the most common problems of transaction management.<br />To effectively use global transactions, one should keep in mind that Seam turns them on by default. To turn them off, you'll need to disable Seam's transaction management all together. This is done by adding<br /><pre name="code" class="brush: xml"><core:init transaction-management-enabled="false"/></pre><br />to the component descriptor file.<br /><br /><h3>Notes</h3><br />It should also be noted that, despite what can be read in some sources, <span class="snippet">@Transactional</span> annotation is not unusable in conjunction with global transactions. The point here is that since there is an overarching transaction, no new transactions will be spawned to encompass annotated business methods, effectively ignoring <span class="snippet">@Transactional</span>. Of course, an overarching transaction will only be present during a JSF postback. On non-JSF calls, <span class="snippet">@Transactional</span> will still do it's job normally. This misunderstanding was caused by a somewhat ambiguous statement in <em>Seam in Action</em>.<br />To recap, <em>global translations</em> is just another name for (as Dan Allen would put it) <em>"automatic transaction wrapped around the request"</em>. A useful feature which one should always keep in mind when developing applications in Seam.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1468532151642511496.post-38750684696015586942009-05-30T06:18:00.000-07:002016-05-31T05:46:35.333-07:00Authentication and authorization with JBoss security domainsAuthentication and authorization comprise the fundamentals of security, and as such, they are important aspects of almost any application. Having in mind that security is such a frequent issue, it comes as no surprise that many people have devised many different ways of carrying it out, and so we now have literally countless options to choose from. If you are going to deploy your application to JBoss AS, you can get the basic authentication and authorization set up in virtually no time. To carry out these tasks, JBoss uses the notion of a security domain overlaying the standard JAAS (Java Authentication and Authorization Service).<br /><br /><h3>Configuring the data source (<span class="snippet">*-ds.xml</span>)</h3><br /><br />In order to set up a security domain for your app to use, you first need to set up a data source against which you will check the user's credentials. More often than not, your source of data will be a relational database. JBoss conveniently provides templates for many populars databases, so setting up a data source should be a breeze. These templates can be found under<br /><strong><JBoss home>/docs/examples/jca<sup>1</sup></strong>. Notice that all the filenames in this directory end with "-ds". This is the convention for naming the data source configuration files.<br /><br />Let's assume we want to use MySQL. All we need to do, is make a copy of mysql-ds.xml, edit it to reflect our situation, and put it into the deployment directory. Editing this file is pretty straight forward, you decide on a JNDI name you want your data source bound to (I'll use <span class="snippet">MySqlDS</span>), input your connection URL, username and password. There's really no need to change the driver class.<br /><br />When this is done, you place this file under <strong><JBoss home>/server/<profile name>/deploy<sup>2</sup></strong>. That's it for this step.<br /><br /><h3>Configuring a security domain (<span class="snippet">login-config.xml</span>)</h3><br /><br />Next, you need to edit JBoss' <span class="snippet">login-config.xml</span> file (found under<JBoss home>/server/<profile name>/conf). There are other ways to set up the security domain, but is by far the easiest. All you need to do here is nest a snippet similar to the following inside the <span class="snippet">policy</span> element.<br /><pre name="code" class="brush: xml"><!-- My custom security domain --><br /> <application-policy name="custom-domain"><br /> <authentication><br /> <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule"<br /> flag = "required"><br /> <module-option name="dsJndiName">java:/MySqlDS</module-option><br /> <module-option name="principalsQuery">SELECT password FROM USERS WHERE username=?</module-option><br /> <module-option name="rolesQuery">SELECT role, 'Roles' FROM ROLES WHERE username=?</module-option><br /> </login-module><br /> </authentication><br /> </application-policy></pre><br />Pay attention that <span class="snippet">dsJndiName</span> attribute value must be identical to the <span class="snippet">jndi-name</span> you chose in your <span class="snippet">mysql-ds.xml</span>, preceded by <span class="snippet">java:/</span>.<br /><span class="snippet">principalsQuery</span> is the SQL query used to retrieve the user's password which, of course, has to match the one entered, and <span class="snippet">rolesQuery</span> is the SQL query used to retrieve the roles associated with the user (leave the <span class="snippet">'Roles'</span> part as it is, it's not clear from the JBoss' documentation what purpose it has).<br /><br />Our security domain is now ready. The next thing to do would be to instruct our application to use it.<br /><br /><h3>Declaring page-level security (<span class="snippet">web.xml</span>)</h3><br /><br />Presume we have a <span class="snippet">web.xml</span> with the following security constraints configured:<br /><pre name="code" class="brush: xml"><security-constraint><br /> <web-resource-collection> <br /> <web-resource-name>Secure Resource</web-resource-name><br /> <url-pattern>/secure/*</url-pattern> <br /> </web-resource-collection><br /> <auth-constraint> <br /> <role-name>registereduser</role-name> <br /> </auth-constraint> <br /> </security-constraint> <br /><login-config><br /> <auth-method>FORM</auth-method><br /> <form-login-config><br /> <form-login-page>/login.html</form-login-page><br /> <form-error-page>/error.html</form-error-page><br /> </form-login-config><br /></login-config><br /><security-role> <br /> <role-name>registereduser</role-name><br /></security-role><br /> <resource-ref><br /> <res-ref-name>jdbc/mysql</res-ref-name><br /> <res-type>javax.sql.DataSource</res-type><br /> <res-auth>Container</res-auth><br /> </resource-ref></pre><br />This tells our app server that only the users with the <span class="snippet">registereduser</span> role can access the resources under <span class="snippet">/secure/</span> (this is the job of the <span class="snippet">url-pattern</span> element). It also tells we are going to use a form to perform authentication (notice the <span class="snippet">auth-method</span> element), and that this form is found on the page named <span class="snippet">login.html</span> (the <span class="snippet">form-login-page</span> element). The request gets redirected to the page specified under <span class="snippet">form-error-page</span> in case the login failed. You can also use <span class="snippet">BASIC</span> authentication method (just place <span class="snippet">BASIC</span> instead of <span class="snippet">FORM</span> inside <span class="snippet">auth-method</span> element) . This will cause the browser to display a simple pop-up dialog that asks for username and password when a secured resource is requested. You don't need <span class="snippet">form-login-config</span> for this approach.<br /><br /><h3>Creating a login form (<span class="snippet">j_security_check</span>)</h3><br /><br />The login page is obviously required to contain a login form. This form must specify <span class="snippet">j_security_check</span> as it's action, and it also must have a username input field named <span class="snippet">j_username</span> and a password input field named <span class="snippet">j_password</span>. <br /><br />This is how it might look like in it's simplest form:<br /><pre name="code" class="brush: xml"><form name="loginForm" method="post" action="j_security_check"><br /><table><br /> <tr><br /> <td>User Name:</td><br /> <td><input type="text" name="j_username"></td><br /> </tr><br /> <tr><br /> <td>Password:</td><br /> <td><input type="password" name="j_password"></td><br /> </tr><br /> <tr colspan="2"><br /> <td><input type="submit" value="login"></td> <br /> </tr><br /></table><br /></form></pre><br /><h3>Binding the application to a security domain (<span class="snippet">jboss-web.xml</span>)</h3><br />So, <span class="snippet">web.xml</span> dictates the security constraints, but there is no mention of how these constraints will be carried out. This is the job of the <span class="snippet">jboss-web.xml</span> config file (which is, of course, JBoss specific). It is in this file where we specify what security domain we want to use for authentication. Here's how it should look like in this case:<br /><pre name="code" class="brush: xml"><?xml version="1.0" encoding="UTF-8"?><br /><jboss-web><br /> <security-domain>java:/jaas/custom-domain</security-domain><br /> <resource-ref><br /> <res-ref-name>jdbc/mysql</res-ref-name><br /> <res-type>javax.sql.DataSource</res-type><br /> <jndi-name>java:/MySqlDS</jndi-name><br /> </resource-ref><br /></jboss-web></pre><br />Pay attention to the <span class="snippet">security-domain</span> element. It is necessary to prefix the domain name with <span class="snippet">java:/jaas/</span>, and the name its self must be exactly the same as the one you typed into the <span class="snippet">login-config.xml</span> file.<br /><br />That's it! Now every unauthenticated request to the secure resource (under <span class="snippet">/secure/</span>, as specified in <span class="snippet">web.xml</span>) will first be redirected to the login page (or, in case of <span class="snippet">BASIC auth-method</span>, a login pop-up will displayed). If the user logs in successfully and is authorized i.e. associated with any of the required roles (only <span class="snippet">registereduser</span> in our case), the requested resource will be displayed. Otherwise, if the login attempt fails, or the user doesn't have any of the required roles, the error page will be displayed instead. Users stay logged in for the entire duration of the session.<br /><br /><h3>Method-level security (<span class="snippet">isUserInRole</span>)</h3><br /><br />Declarative security in <span class="snippet">web.xml</span> is enough if you only need page-level security (based on the URL pattern), but if you need to dynamically check user's role on a method level, you can do so by calling <span class="snippet">isUserInRole("registereduser")</span> on a request object (acquired from the <span class="snippet">ExtrnalContext</span>). Here's a short example of a method doing this:<br /><pre name="code" class="brush: java"><br />public Boolean isRegisteredUser() {<br />HttpServletRequest httpServletRequest =<br />(HttpServletRequest) FacesContext.getCurrentInstance() //first get the current FacesContext instance<br />.getExternalContext() //than get the ExternalContext<br />.getRequest(); //get the underlying request<br />// return True if this request was issued by a user with a "registereduser" role<br />return httpServletRequest.isUserInRole("registereduser"); <br />}</pre><br />You can get the username in pretty much the same way, just call <span class="snippet">getRemoteUser()</span> instead of <span class="snippet">isUserInRole("...")</span>.<br /><br /><strong>Notes:</strong><br /><sup>1</sup> <strong><JBoss home></strong> refers to your JBoss installation directory (the same as <span class="snippet">JBOSS_HOME</span> environmental variable).<br /><sup>2</sup> <strong><profile name></strong> refers to your deployment profile name (you will probably be using <span class="snippet">default</span>).Unknownnoreply@blogger.com9tag:blogger.com,1999:blog-1468532151642511496.post-69786304238281912212009-04-05T04:21:00.000-07:002016-05-31T05:47:39.840-07:00Validators in JSFIn JSF, validators are components that provide a mechanism for clean and easy validation of user input and, if necessary, generation of messages that can be displayed back to the client.<br /><br />JSF comes with some basic built-in validators, but it allows for new, custom ones, to be added by the developer.<br /><br /><h3>Built-in validators</h3><br /><br />The following validators are available out of the box:<br /><br />• <span class="snippet">f:validateDoubleRange</span>: Checks whether a numeric input (convertible to <span class="snippet">double</span>) is within a specified range.<br />• <span class="snippet">f:validateLength</span>: Checks if the string input length is within a given range.<br />• <span class="snippet">f:validateLongRange</span>: Checks whether a numeric input (convertible to <span class="snippet">long</span>) is within a given range.<br /><br /><br />In order to be used, a validator needs to be nested into an <span class="snippet">h:input</span> component that requires it.<br />To dictate the boundaries of the acceptable range, you need to specify the values for the <span class="snippet">minimum</span> and/or <span class="snippet">maximum</span> attributes to each of these validators.<br /><br />Let's exemplify this. Assume we were creating an application that calculates monthly rates for the chosen loan. The client is expected to input the number of months they require the loan for, but our application does not allows this to be less than 6 or greater than 120 (or 10 years).<br /><br />If we had a backing bean called <span class="snippet">loansManager</span> and, within it, a <span class="snippet">HtmlInputText</span> field, the component we would use would look like this:<br /><pre name="code" class="brush: xml"><h:inputText id="account" required="true"<br />binding="#{loansManager.client.accountNumber}"<br />requiredMessage="Value is required!"><br /><f:validator validatorId="AccountNumberValidator"/><br /></h:inputText></pre><br /><h3>Custom validators</h3><br /><br />If you need validation beyond the scope of the afore mentioned built-in components, you will have to write a custom validator to take care of your requirements.<br /><br />You have two options here, to create a validator class or to create a validator method in one of your backing beans.<br /><br />The first approach means implementing the <span class="snippet">Validator</span> interface and it's <span class="snippet">validate</span> method.<br /><br />This time assume our application expects the client to input his account number in form ***.*******.**, where each * represents one character (probably should be a digit, but let's keep it simple).<br /><br />The implementing class would then look like this:<br /><pre name="code" class="brush: java"><br />package loans.validators;<br /><br />import javax.faces.application.FacesMessage;<br />import javax.faces.component.UIComponent;<br />import javax.faces.context.FacesContext;<br />import javax.faces.validator.Validator;<br />import javax.faces.validator.ValidatorException;<br /><br />public class AccountNumberValidator implements Validator {<br /><br /> public AccountNumberValidator() {<br /> }<br /><br /> public void validate(FacesContext ctxt, UIComponent cmp, Object val) {<br /> <br /> String message = null;<br /><br /> try {<br /> String[] parts = ((String)val).split("-");<br /> if (parts.length < 3)<br /> message = "Wrong account number!";<br /> else {<br /> if (parts[0].length() != 3 || parts[1].length() != 7 || parts[2].length() != 2)<br /> message = "Wrong account number!";<br /> }<br /> } catch (Exception e){}<br /><br /> if (message != null) {<br /> FacesMessage msg = new FacesMessage(<br /> FacesMessage.SEVERITY_ERROR, message, message);<br /> throw new ValidatorException(msg);<br /> }<br /> }<br />}</pre><br />To register this validator, you would have to add the following snippet to your <span class="snippet">faces-config.xml</span> file:<br /><pre name="code" class="brush: xml"><validator><br /><validator-id>AccountNumberValidator</validator-id><br /><validator-class>loans.validators.AccountNumberValidator</validator-class><br /></validator></pre><br />Now, you can add your validator to any <span class="snippet">h:input</span> component that requires it.<br /><br />For example:<br /><pre name="code" class="brush: xml"><h:inputText id="account" required="true"<br />binding="#{loansManager.client.accountNumber}"<br />requiredMessage="Value is required!"><br /><f:validator validatorId="AccountNumberValidator"/><br /></h:inputText></pre><br />The second option, mentioned earlier, is writing a validator method instead. For this, we would make a <span class="snippet">validateAccountNumber</span> method in our <span class="snippet">loansManager</span> backing bean. The method should look like this:<br /><pre name="code" class="brush: java"><br />public void validateAccountNumber(FacesContext ctxt, UIComponent cmp, Object val) {<br /> <br /> String message = null;<br /><br /> try {<br /> String[] parts = ((String)val).split("-");<br /> if (parts.length < 3)<br /> message = "Wrong account number!";<br /> else {<br /> if (parts[0].length() != 3 || parts[1].length() != 7 || parts[2].length() != 2)<br /> message = "Wrong account number!";<br /> }<br /> } catch (Exception e){}<br /><br /> if (message != null) {<br /> FacesMessage msg = new FacesMessage(<br /> FacesMessage.SEVERITY_ERROR, message, message);<br /> ctxt.addMessage(cmp.getClientId(ctxt), mess);<br /> }<br /> }</pre><br />Note that this time, instead of throwing a validator exception, we're manually adding a message the <span class="snippet">FacesContext</span>'s queue. In the previous example this was done automatically.<br /><br />To use this new validator, you would add it to your <span class="snippet">h:input</span> component like this:<br /><pre name="code" class="brush: xml"><h:inputText id="account" required="true"<br />binding="#{loansManager.client.accountNumber}"<br />validator="#{loansManager.validateAccountNumber}"<br />requiredMessage="Value is required!"/></pre><br /><b>Note:</b><br />You might as well do validation anywhere inside your application and just add the message to the <span class="snippet">FacesContext</span> in the same manner you've seen earlier, but this has one important constraint. In place of <span class="snippet">cmp.getClientId(ctxt)</span> inside<br /><span class="snippet">ctxt.addMessage(cmp.getClientId(ctxt), msg);</span><br />you would have to hard code the component id:<br /><pre name="code" class="brush: java">ctxt.addMessage("account", msg);</pre><br />since you no longer have the reference to the component itself.<br />Also, you might put a global message (not bound to any component) into a <span class="snippet">FacesContext</span> message queue with<br /><pre name="code" class="brush: java">ctxt.addMessage(null, msg);</pre><br />but these messages can only be displayed with <span class="snippet"><h:messages/></span> element.<br /><p/>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1468532151642511496.post-45125659765770027832009-04-04T11:54:00.000-07:002016-05-31T05:48:03.402-07:00Extended Persistence ContextExtended persistence context is an interesting feature of the JPA specification. It allows one to declare that the injected <span class="snippet">EntityManager</span> lives beyond the scope of the JTA transaction, that is, to <em>extend</em> it to the lifetime of the stateful session bean itself. This is achieved with the following annotation:<br /><pre class="brush: java" name="code">@PersistenceContext(type=PersistenceContextType.EXTENDED) EntityManager em;</pre><br />Doing this has a couple of implications.<br />First of all, within the extended persistence context, managed entities remain managed even after the transaction commits (or is rolled back). This behavior is very different than that of a transaction scoped context, were entities get detached at the end of the transaction.<br />Second implication important to note is that changes done to the managed entities from outside of a transaction will not be propagated to the database immediately, and will be buffered instead. In order to get the changes reflected in the database, the EntitiyManager needs to be accessed from a transaction context and flushed (by invoking it's <span class="snippet">flush()</span> method).<br /><br />For obvious reasons, extended persistence context is only available within stateful Session Beans.<br /><br />The most frequently quoted example of use is a multi-step conversation with a client, where the data that is to be persisted in a single transaction is acquired form a client in a series of steps with arbitrary periods of time in between. In this scenario, changes are sequentially applied to the managed entity in question, and the <span class="snippet">EntityManager</span> is flushed at the very end of the conversation.<br /><br />To illustrate this, image you were dealing with a multi-page client registration form. On each page, the client is expected to input some information about themselves, but each time the information pertains to a different aspect. For example, the first page could ask for general details, like name and title, the second would deal with the contact info, and the third could ask for some optional data, like an average income or a favorite hobby.<br />Now, to achieve this, you could create a stateful bean similar to the following:<br /><pre class="brush: java" name="code">@Stateful<br />public class RegistrationBean implements Registration<br />{<br /> @PersistenceContext(type=PersistenceContextType.EXTENDED) EntityManager em;<br /><br /> private Customer customer;<br /><br /> public long createCustomer(String name, String lastName)<br /> {<br /> customer = new Customer();<br /> customer.setName(name);<br /> customer.setLastName(lastName);<br /> em.persist(customer);<br /> return customer.getId();<br /> }<br /><br /> public void setContacts(String address, String phoneNumber, String email)<br /> {<br /> customer.setAddress(address);<br /> customer.setPhoneNumber(phoneNumber);<br /> customer.setEmail(email);<br /> }<br /><br /> public void setOptionals(...)<br /> {<br /> ...<br /> }<br /><br /> @TransactionAttribute(TransactionAttributeType.REQUIRED)<br /> public void confirmRegistration() {<br /> em.flush();<br /> }<br />}</pre><br />In conclusion, it's worth to note that the same effect could have been achieved by wrapping the whole conversation in a single user-managed transaction, but that it still makes more sense to exploit the power of an extended persistence context as it provides both a simpler and cleaner solution.<br /><p/>Unknownnoreply@blogger.com4