volatile usage --problem

import java.util.ArrayList;



public class ThreadTest {

public static void main(String[] args) {

ArrayList arr = new ArrayList();

TestTwo bobj = new TestTwo();

for (int  i =0; i<10 font="" i="">
arr.add(new MyTh(i,bobj));


for (int  i =0; i<10 font="" i="">
{
((Thread ) arr.get(i)).start();


}

}

}



class MyTh extends Thread{


int  num ;

static int  age ;


volatile StringBuffer buff = new StringBuffer("0");

static  StringBuffer buff2 = new StringBuffer("0");

TestTwo obj ;

MyTh (int  k, TestTwo cobj )

{this.num=k; 
this.obj=cobj;} 

@Override
public void run() {

if(this.num==6){
//setAge(40);
this.obj.count.append("hi");
this.buff.append("hi");
this.buff2.append("hi");
this.age =40;
    }
System.out.println(Thread.currentThread().getName() + " :"+this.num + ":" + this.age +":"+
" :[" +this.buff2 +":"+ this.buff2.hashCode() + 
    "] : [" + this.buff + " :"+ this.buff.hashCode() +"] :[ "+ this.obj.count+ ":"+this.obj.count.hashCode() +":]");

}

int   getAge(){
return age;
}

void  setAge(int  k){
this.age =k;
}

}


class TestTwo {

volatile StringBuffer count = new StringBuffer("0");


}


------------



Thread-0 :0:0: :[0:1740525517] : [0 :1769581898] :[ 0:1833313469:]
Thread-1 :1:0: :[0:1740525517] : [0 :857628581] :[ 0:1833313469:]
Thread-2 :2:0: :[0:1740525517] : [0 :1498557318] :[ 0:1833313469:]
Thread-3 :3:0: :[0:1740525517] : [0 :1419206900] :[ 0:1833313469:]
Thread-4 :4:0: :[0:1740525517] : [0 :313434985] :[ 0:1833313469:]
Thread-5 :5:0: :[0:1740525517] : [0 :1644604984] :[ 0:1833313469:]
Thread-6 :6:40: :[0hi:1740525517] : [0hi :1055613344] :[ 0hi:1833313469:]
Thread-7 :7:40: :[0hi:1740525517] : [0 :1151033700] :[ 0hi:1833313469:]
Thread-8 :8:40: :[0hi:1740525517] : [0 :1472482392] :[ 0hi:1833313469:]
Thread-9 :9:40: :[0hi:1740525517] : [0 :1908885604] :[ 0hi:1833313469:]

Java Tidbits .........(char vs byte stream )

A stream is a way of sequentially accessing a file. In Streams you can process the data one at a time as bulk operations are unavailable with them. But, streams supports a huge range of source and destinations including disk file, arrays, other devices, other programs etc. In Java, a byte is not the same thing as a char . Therefore a byte stream is different from a character stream. So, Java defines two types of streams: Byte Streams and Character Streams .

Byte Streams

A byte stream access the file byte by byte. Java programs use byte streams to perform input and output of 8-bit bytes. It is suitable for any kind of file, however not quite appropriate for text files. For example, if the file is using a unicode encoding and a character is represented with two bytes, the byte stream will treat these separately and you will need to do the conversion yourself. Byte oriented streams do not use any encoding scheme while Character oriented streams use character encoding scheme(UNICODE). All byte stream classes are descended from InputStream and OutputStream .

Obtain the count of total rows from SQL query bounded by rownum

Below query i used in a  project where  TOTAL count was obtained  even when Query is bounded by rownum on both ends .


select * from (select PART_NR,CTRY_CD,CUST_TRF_CD,VAL_FROM_DT,CHG_DT,NAT_HS_CD_2 , ROW_NUMBER() OVER(ORDER BY  CHG_DT,PART_NR) AS ID,
 COUNT(1) OVER ( ORDER BY 1 RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING ) ROW_COUNT from
((select TRIM(A.PART_NR) as PART_NR, TRIM(A.CTRY_CD) as CTRY_CD, TRIM(A.CUST_TRF_CD) as CUST_TRF_CD ,TO_CHAR(A.VAL_FROM_DT ,'yyyymmddhh24miss') as VAL_FROM_DT, TO_CHAR(A.CHG_DT ,'YYYYMMDDhh24miss') as CHG_DT,(case when (A.NAT_HS_CD is null  and A.CUST_TRF_CD is not null)  then
(select TRIM(C.NAT_HS_CD) from (select * from  (select CUST_TRF_CD, CTRY_CD, NAT_HS_CD ,VAL_FROM_DT from CLA_NAT_HS_DETAIL where CTRY_CD =421
 and INVALID_CD=0) AA where  VAL_FROM_DT= (select max(VAL_FROM_DT) from (select CUST_TRF_CD, CTRY_CD, NAT_HS_CD ,VAL_FROM_DT from CLA_NAT_HS_DETAIL
 where CTRY_CD  =421   and INVALID_CD=0) TT  where AA.CUST_TRF_CD=TT.CUST_TRF_CD and AA.CTRY_CD=TT.CTRY_CD) ) C where  C.CUST_TRF_CD=A.CUST_TRF_CD and
 C.CTRY_CD=A.CTRY_CD )  else TRIM(A.NAT_HS_CD)  end) as NAT_HS_CD_2 from cla_cust_part_ctry A where
 A.ctry_cd =421  and  A.CHG_DT between TO_DATE( '20110713000000', 'yyyymmddhh24miss') and TO_DATE( '20110714000000', 'YYYYMMDDhh24miss') and
 TRIM(A.PART_NR) not like '% %' ))  where  NAT_HS_CD_2 is not null) where ID > 20 and ID < 46 order by ID asc 

WebService TitBit-8

Subresources and Runtime Resource Resolution

You can use a resource class to process only a part of the URI request. A root resource can then implement subresources that can process the remainder of the URI path.

A resource class method that is annotated with @Path is either a subresource method or a subresource locator:

• A subresource method is used to handle requests on a subresource of the corresponding resource.
• A subresource locator is used to locate subresources of the corresponding resource.

Subresource Methods

A subresource method handles an HTTP request directly. The method must be annotated with a request method designator such as @GET or @POST, in addition to @Path. The method is invoked for request URIs that match a URI template created by concatenating the URI template of the resource class with the URI template of the method.

The following code snippet shows how a subresource method can be used to extract the last name of an employee when the employee’s email address is provided:

@Path("/employeeinfo")
Public class EmployeeInfo {

    public employeeinfo() {}

    @GET
    @Path("/employees/{firstname}.{lastname}@{domain}.com")
    @Produces("text/xml")
    public String getEmployeeLastName(@PathParam("lastname") String lastName) {
       ...
    }

}

The getEmployeeLastName method returns doe for the following GET request:

GET /employeeinfo/employees/john.doe@example.com

Subresource Locators

A subresource locator returns an object that will handle an HTTP request. The method must not be annotated with a request method designator. You must declare a subresource locator within a subresource class, and only subresource locators are used for runtime resource resolution.

The following code snippet shows a subresource locator:

// Root resource class
@Path("/employeeinfo")
public class EmployeeInfo {

    // Subresource locator: obtains the subresource Employee
    // from the path /employeeinfo/employees/{empid}
    @Path("/employees/{empid}")
    public Employee getEmployee(@PathParam("empid") String id) {
        // Find the Employee based on the id path parameter
        Employee emp = ...;
        ...
        return emp;
    }
}

// Subresource class
public class Employee {

    // Subresource method: returns the employee's last name
    @GET
    @Path("/lastname")
    public String getEmployeeLastName() {
        ...
        return lastName
    }
}

In this code snippet, the getEmployee method is the subresource locator that provides the Employee object, which services requests for lastname.

If your HTTP request is GET /employeeinfo/employees/as209/, the getEmployee method returns an Employee object whose id is as209. At runtime, JAX-RS sends a GET /employeeinfo/employees/as209/lastname request to the getEmployeeLastName method . The getEmployeeLastName method retrieves and returns the last name of the employee whose id is as209.

WebService TitBit-7

Status

This text is the proposed revised replacement text for the 2nd last paragraph in part 1, section 2.6 which reads as follows:

If the SOAP node is a SOAP intermediary, the SOAP message pattern and results of processing (e.g. no fault generated) MAY require that the SOAP message be sent further along the SOAP message path. Such relayed SOAP messages MUST contain all SOAP header blocks and the SOAP body from the original SOAP message, in the original order, except that SOAP header blocks targeted at the SOAP intermediary MUST be removed (such SOAP blocks are removed regardless of whether they were processed or ignored). Additional SOAP header blocks MAY be inserted at any point in the SOAP message, and such inserted SOAP header blocks MAY be indistinguishable from one or more just removed (effectively leaving them in place, but emphasizing the need to reinterpret at each SOAP node along the SOAP message path.)

The text builds on the proposed wording for resolving issue 137 by Noah and Henrik and discussion at the W3C f2f meeting in Cannes.
The idea here is to cast relaying as a feature - it builds on section 2.

2.7 Relaying SOAP Messages

As mentioned earlier in this section, SOAP provides a distributed processing model that assumes that a SOAP message originates at an initial SOAP sender and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries. While SOAP does not itself define any routing or forwarding semantics, it is anticipated that such functionality can be described as one or more features and expressed as SOAP extensions or as part of the underlying protocol binding (see section 5 and 6). The purpose of this section is to describe how message forwarding interacts with the SOAP distributed processing model.

SOAP Intermediaries

The semantics of one or more SOAP blocks in a SOAP message, or the SOAP message exchange pattern used MAY request that the SOAP message be forwarded to another SOAP node on behalf of the initiator of the inbound SOAP message. In this case, the processing SOAP node acts in the role of a SOAP intermediary.

SOAP defines two different types of intermediaries: forwarding intermediaries and active intermediaries. These two type of intermediary are described below.

Forwarding Intermediaries

Forwarding intermediaries process the message according to the SOAP processing model defined in section 2.6. SOAP header blocks targeted at the SOAP intermediary MUST be removed from the SOAP message prior to forwarding (such SOAP blocks are removed regardless of whether they were processed or ignored).

It is the responsibility of the feature defining the SOAP forwarding to describe the required semantics including rules describing how the forwarded message is constructed. Such rules MAY describe placement of inserted or reinserted blocks. Inserted SOAP header blocks may be indistinguishable from one or more of the header blocks removed above (effectively leaving them in place, but emphasizing the need to reinterpret at each SOAP node along the SOAP message path.)

Active Intermediaries

In addition to the processing performed by forwarding intermediaries, active intermediaries undertake additional processing that may modify the outbound message in ways not described in the inbound message. I.e. they may undertake processing not described by header blocks in the incoming message. The potential set of services provided by an active intermediary includes, but is not limited to: logging, security, content modification and tracing.

The collective effect of such additional processing may affect the correct processing of features expressed in the inbound message by downstream SOAP nodes. For example, as part of generating an outbound message, an active intermediary may have removed and encryped some or all of the blocks found in the inbound message.

It is STRONGLY RECOMMENDED that features provided by active intermediaries be described in a manner that allows such modifications to be detected by the affected SOAP nodes. For example, an active intermediary may describe the processing performed by inserting header blocks into the outbound SOAP message that inform downstream SOAP nodes acting in roles whose correct operation depends on receiving such notification. The semantics of such inserted headers should also call for either the same or other headers to be (re)inserted at subsequent intermediaries as necessary to ensure that the message can be safely processed by nodes yet further downstream. For example, if a message with headers removed for encryption passes through a second intermediary (without the original headers being decrypted and reconstructed), then indication that the encryption has occurred must be retained in the second relayed message.

WebService TitBit-6

Components of EJB-JAR.xml


 < ejb-jar >
     < assembly-descriptor >
         < method-permission >
             < description > The employee and temp-employee roles may access any
                method of the EmployeeService bean  < / description >
             < role-name > employee < / role-name >
             < role-name > temp-employee < / role-name >
             < method >
                 < ejb-name > EmployeeService < / ejb-name >
                 < method-name > * < / method-name >
             < / method >
         < / method-permission >
         < method-permission >
             < description > The employee role may access the findByPrimaryKey,
                getEmployeeInfo, and the updateEmployeeInfo(String) method of
                the AardvarkPayroll bean  < / description >
             < role-name > employee < / role-name >
             < method >
                 < ejb-name > AardvarkPayroll < / ejb-name >
                 < method-name > findByPrimaryKey < / method-name >
             < / method >
             < method >
                 < ejb-name > AardvarkPayroll < / ejb-name >
                 < method-name > getEmployeeInfo < / method-name >
             < / method >
             < method >
                 < ejb-name > AardvarkPayroll < / ejb-name >
                 < method-name > updateEmployeeInfo < / method-name >
                 < method-params >
                     < method-param > java.lang.String < / method-param >
                 < / method-params >
             < / method >
         < / method-permission >
         < method-permission >
             < description > The admin role may access any method of the
                EmployeeServiceAdmin bean  < / description >
             < role-name > admin < / role-name >
             < method >
                 < ejb-name > EmployeeServiceAdmin < / ejb-name >
                 < method-name > * < / method-name >
             < / method >
         < / method-permission >
         < method-permission >
             < description > Any authenticated user may access any method of the
                EmployeeServiceHelp bean < / description >
             < unchecked/  >
             < method >
                 < ejb-name > EmployeeServiceHelp < / ejb-name >
                 < method-name > * < / method-name >
             < / method >
         < / method-permission >
         < exclude-list >
             < description > No fireTheCTO methods of the EmployeeFiring bean may be
                used in this deployment < / description >
             < method >
                 < ejb-name > EmployeeFiring < / ejb-name >
                 < method-name > fireTheCTO < / method-name >
             < / method >
         < / exclude-list >
     < / assembly-descriptor >
 < / ejb-jar > 

WebService TitBit - 5

Best Explanation about wsgen / wsimport



Courtsy >>

https://coderanch.com/t/625764/certification/difference-wsimport-wsgen-command

1. Can we say that wsgen and wsimport command generates same classes (same JAX-WS artifacts)? 

2. Can we say that wsgen and wsimport command is used to generate both server and client side code ? 

3. can wsgen command be used to generate a WSDL file ? 

Correct me if I am wrong. 
wsgen and wsimport generates JAX-WS artifacts from SBI and WSDL respectively. 
If those JAX-WS artifacts do not exist, when the service is published using Endpoint.publish or web service container (Tomcat), those artifacts are dynamically generated. 
If those artifacts exist (generated by wsgen), the Endpoint.publish does not generate those artifacts. 

1. Yes. wsgen and wsimport generate request and response wrapper bean classes and the JAXB classes (XXX.class and XXXResponse.class). 
However, wsgen generates the JAXB classes and put them in a jaxws folder. But wsimport does not put those classes in any folder instead in the current directory. 
2. The JAX-WS artifacts generated can be used by both server and client side. 
3. I think wsgen can be used to generate WSDL. Here is an example at http://www.mkyong.com/webservices/jax-ws/jax-ws-wsgen-tool-example/