Difference between JSR 168 and JSR 286 Portlet life Cycle

Difference between JSR 168 and JSR 286 Portlet life Cycle

JSR 168 Portlet Life Cycle

1. void init(PortletConfig config):

This method is called by the portlet container to indicate to a portlet that the portlet is being placed into service. This method used to initialise a portlet. This method is called only one time during the portlet life cycle.

2. void render(RenderRequest request, RenderResponse response):

When a portlet is displayed in the portal page this method is called. Render method is responsible to generate HTML content. We can create render URL to invoke render method. For example

<portlet:renderURL var="myURL"/>

3. void processAction(ActionRequest request, ActionResponse response)

When we invoke action URL the processAction method is called. A process action is generally used to process submitted form or writing data to database. For example

<portlet:actionURL var="myURL" name="process"/>

As soon as a process action is invoked it invoke render method. If a portal page contains five portlets then all the five render methods will be called either in parallel or one after another.

4. void destroy():

Called by the portlet container to indicate to a portlet that the portlet is being taken out of service. The default implementation does nothing. When a portlet is undeployed this method is called by the portlet container.

JSR 286 Portlet Life Cycle

JSR 286 Portlet Life Cycle also have all above JSR 168 4 methods, there are 2 new method introduce in JSR 286.

5.  void processEvent(EventRequest request, EventResponse response):

Process Event method is used to process an event. In JSR 168 there was no no process event method. It was introduced in JSR 286. This portlet life cycle method has important role in implementing event based inter portlet communication (IPC). As soon as process event method is completed the portlet container invokes render method. 

6. void serveResource(ResourceRequest request, ResourceResponse response)

Called by the portlet container to allow the portlet to generate the resource content based on its current state. The portal / portlet container must not render any output in addition to the content returned by the portlet. The portal / portlet container should expect that the portlet may return binary content for a renderResource call. This portlet life cycle method is added in JSR 286. 

This method is basically required to generate non HTML based content like JSON, XML etc. We can implement AJAX using this method. A serveResource method can be invoked by creating resource URL. For example

<portlet:resourceURL var="myResourceUrl"/>

Solution for sender channel status retrying

Solution for sender channel status retrying

Scenario 1: My window machine installed with IBM WebSphere MQ 7.5 version and z/OS machine installed with IBM WebSphere MQ 7.0. I have one remote queue on my window 

machine which sends messages to z/OS machines local Queue. I am able to send messages from my remote queue to z/OS local queue using sender channel, Receiver Channel and Transmission Queue. Some network interruption happened on my window machine and lost connection with Z/OS machine. At the time of network interruption, my sender channel and Z/OS receiver channel was running. when connection restored with these two machine my sender channel status becomes "Retrying" and receiver channel status still showing running. When I looked on error log AMQERR01.LOG for sender channel, this look like below. 

I tried with lots of option like stop and start Sender Queue Manager, Sender channel, checked MAX instance defined on both machine but nothing worked. I also applied fix pack of 7.5.0.5 on MQ7.5 by reading below article. IT02422: WMQ V7.5 JAVA APPLICATION FAILS WITH REASON CODE 2025 (MQRC_MAX_CONNS_LIMIT_REACHED) AFTER NETWORK OUTAGES(http://www-01.ibm.com/support/docview.wss?doc=aimwmq&rs=171&uid=swg21110505) but this also not worked.

Solution: Finally I got one solution. forcefully stopped sender channel and receiver channel(STOP CHL(rcvr chl name) MODE(FORCE)), both channel status should be STOPPED now. start receiver channel.Stop and start Queue manager of sender channel. Than, finally start sender channel. In my case this worked :)

Scenario 2: I configured my remote Queue and local Queue on window machine. Through java application, I am trying to put messages on remote Queue and try to get those messages on my local queue, but my messages got stuck on transmission Queue and sender channel goes into Retrying state.
Note: Earlier my sender channel connected with other system's IP and able to send and receive messages, when I changed IP with my local system than messages got stuck in transmission queue and sender channel goes into Retrying state.

Solution: I found one temporary solution. Deleted old transmission Queue and created new one and given reference to sender channel and Remote queue.

In above 2 scenario, difference in 1st scenario is, sender channel goes in retrying state when one system lost connection with other system where as in 2nd scenario, changed IP address in sender channel.


Related Topic:

Spring jms code for ibm mq example

How to set IBM MQ expiration time

How to set IBM MQ ReplyToQueue and ReplyToQueueManager

Java code for xml digital signature creation and verification

Java code for xml digital signature creation and verification

In Previous post, I discussed about XML digital signature API hope you read from this post .

XML Signature Creation 

Identifying the resources to be signed.
Computing the digest of each resource.
Signing the document.

Click here to download complete java code for xml digital signature creation and verification.

Java Code for XML Digital Signature Creation

Creation of JKS File

Go to your JRE bin location  C:\Program Files\Java\jre1.8.0_91\bin and run this command.
keytool -genkeypair -dname "cn=Nitesh Kumar, ou=JavaSoft, o=Sun, c=IN" -alias digitalsignature -keypass digsign -keystore D:\Digital_signature\keystore.jks -storepass storepassword -keysize 2048 -keyalg RSA -sigalg SHA1WithRSA(orSHA256WithRSA)

 Java Code for XML Digital Signature Verification

Java XML Digital Signature API

Java XML Digital Signature API

Java Platform, Standard Edition 6 (Java SE 6) is the Java XML Digital Signature API. This API allows us to generate and validate XML signatures. XML signatures are a standard for digital signatures in the XML data format, and they allow us to authenticate and protect the integrity of data in XML and web service transactions. 

What is a digital signature?

 XML Digital Signatures are digital signatures designed for use in XML transactions.

 It allows us to sign more than one piece of data -- in binary or XML -- and to use any underlying     cryptographic signature algorithm.

XML Signature can be used to sign only portions of a XML message.

The use of XML Digital Signatures involves two parts: 

    (a)  XML Digital Signatures creation  

    (b)  XML Digital Signatures verification.

 There are three types of digital signature.

 Detached Signature

In this case, the digital signature is generated independently and it is not part of  the XML document. It means you will have two XML files, one is your XML file to be signed and another is the XML signature. Let see the skeletal structure of the XML document.

    < signature >

            …

    </ signature>

Enveloping signature 

In this case XML document remains inside the Signature object. It means <Signature> tag becomes the root element of the signed XML document. The following is the outline of the enveloping digital signature.

    < signature >

           < document >

                 …

           </ document >

    </ signature>

Enveloped signature 

In this case, signature is the child of the XML object which is signed. It means <Signature> is a child XML tag in the mail XML document. The following is the structure of the enveloped digital signature.

    <document>

        <signature>

             …

        </signature>

    </document>

XML Digital Signature example

The XML tag <Signature> basically contains 3 children tags.

<Signature>

 <SignedInfo></SignedInfo>

 <SignatureValue></SignatureValue>

 <KeyInfo></KeyInfo>

</Signature>

<Signature> is the root element of the XML digital signature concept and it is a protocol that must be followed as instructed by W3C. <SignedInfo> element is the information that you signed. <SignatureValue> contains the actual signature with Base64-encoded content and finally <KeyInfo> indicates the public key. The structure of <SignedInfo> is given below. 

<SignedInfo>

<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />

<SignatureMethod Algorithm=" http://www.w3.org/2001/04/xmldsig-more#rsa-sha256/>

<Reference URI="">

<Transforms>

<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />

<Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11" />

</Transforms>

<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />

<DigestValue>xe/kONljHYOi5X1sw8AmgIjbHw/SX8zjAT98pJahhI=</DigestValue>

</Reference>

</SignedInfo>

CanonicalizationMethod element

The CanonicalizationMethod element defines as a URI the algorithm used to canonic Alize the SignedInfo element before it is signed or validated. Canonicalization is the process of converting XML content to a physical representation, called the canonical form, in order to eliminate subtle changes that can invalidate a signature over that data. Canonicalization is necessary due to the nature of XML and the way it is parsed by different processors and intermediaries, which can change the data in such a way that the signature is no longer valid but the signed data is still logically equivalent. Canonicalization eliminates these permissible syntactic variances by converting the XML to a canonical form before generating or validating the signature.

SignatureMethod element

The SignatureMethod element defines as a URI the digital signature algorithm used to generate the signature, in this case the RSA-SHA256 algorithm used.

One or more Reference elements identify the data that is signed. Each Reference element identifies the data by way of a URI. The example in XML contains a single Reference element, and the URI is the empty String, "", which indicates the root of the document -- in other words, the whole document. The Reference URIs could also point to external data or to references within the same document.

Transforms element

The optional Transforms element contains a list of one or more Transform elements, each of which describes a transformation algorithm used to transform the data before it is digested and signed, or validated. The enveloped transform is required for enveloped signatures so that the Signature element itself is removed before calculating the signature value. Otherwise, the signature would include itself in the data to be signed, which is not correct.

DigestMethod element

The DigestMethod element defines as a URI the algorithm used to digest the data, in this case, SHA256. The Digest Value element contains the actual base64-encoded digest value.

The structure of <SignatureValue> is given below.

<SignatureValue>7vdS9h04J/slnfUO1aoQ/RbvWE=</SignatureValue>

SignatureValue element

The SignatureValue element contains the base64-encoded signature value of the signature over the SignedInfo element.

The structure of <KeyInfo> is given below.

<KeyInfo>

<X509Data>

<X509SubjectName>CN=rsa0,OU=clc,O=<sender>,L=location,ST=Unknown,C=</X509SubjectName>

<X509IssuerSerial>

<X509IssuerName>CN=sign0, OU=clc, O=<sender>, L=location, ST=Unknown, C=</X509IssuerName>

<X509SerialNumber>1328092436</X509SerialNumber>

</X509IssuerSerial>

</X509Data>

</KeyInfo>

The optional KeyInfo element contains information about the key that is needed to validate the signature.

KeyInfo element

The KeyInfo element can contain various kinds of content, such as X.509 certificates and Pretty Good Privacy (PGP) key identifiers. As per our requirement we use X.509 certificates. KeyInfo contains an X509Data element that contains an X509SubjectName element identifying the subject Distinguished Name of the signer's.