Supun Athukorala

Hibernate "nicely wraps" only what you tell it to wrap. So, assuming that your  Employee  mapping looks something like: @Entity public class Employee { ... @ManyToOne @JoinColumn ( name = "address_id" ) private Address address ; ... } and your  Address  has an  id  property, you can query based on  address_id  via: session . createCriteria ( Employee . class ) . add ( Restrictions . eq ( "address.id" , addressId )); In order to query based on  Address  properties, you'll have to  create aliases or nested criteria : session . createCriteria ( Employee . class )   . createAlias ( "address" ,   "a" )   . add ( Restrictions . eq ( "a.postalCode" ,  postalCode )); http://stackoverflow.com/questions/1787086/hibernate-query-a-foreign-key-field-with-id http://www.mkyong.com/hibernate/hibernate-criteria-examples/

Well, first of all, you're wasting memory with the new  HashMap  creation call. Your second line completely disregards the reference to this created hashmap, making it then available to the garbage collector. So, don't do that, use: private Map < String , String > someMap = ( HashMap < String , String >) getApplicationContext (). getBean ( "someMap" ); Secondly, the compiler is complaining that you cast the object to a  HashMap  without checking if it is a  HashMap . But, even if you were to do: if ( getApplicationContext (). getBean ( "someMap" ) instanceof HashMap ) { private Map < String , String > someMap = ( HashMap < String , String >) getApplicationContext (). getBean ( "someMap" ); } You would probably still get this warning. The problem is,  getBean  returns  Object , so it is unknown what the type is. Converting it to  HashMap  directly would not cause the problem with the sec...

This information came to my knowledge when I was implementing a REST service for my company. A REST client enters a REST application through a simple fixed  URL .  All future actions the client may take are discovered within  resource  representations returned from the server. The  media types  used for these representations, and the  link relations  they may contain, are standardized. The client transitions through application states by selecting from the links within a representation or by manipulating the representation in other ways afforded by its media type. In this way, RESTful interaction is driven by hypermedia, rather than out-of-band information. reference -  https://en.wikipedia.org/wiki/HATEOAS To learn HATEOAS, https://spring.io/understanding/HATEOAS https://www.baeldung.com/spring-hateoas-tutorial

RESTful web service will include CORS access control headers in its response, you’ll need to write a filter that adds those headers to the response. This  SimpleCORSFilter class provides a simple implementation of such a filter: SimpleCORSFilter  responds to all requests with certain  Access-Control-* headers. In this case, the headers are set to allow POST, GET, OPTIONS, or DELETE requests from clients originated from any host. The results of a preflight request may be cached for up to 3,600 seconds (1 hour). And the request may include an  x-requested-with  header. https://spring.io/guides/gs/rest-service-cors/ http://www.codingpedia.org/ama/how-to-add-cors-support-on-the-server-side-in-java-with-jersey/

In this iteration I worked on gathering up all separate knowledge bases in to one. And Finally I configured a parent Activity (class) which will create all the processes and add them to one knowledge base. Then I created a "StatefulKnowledgeSession" where those all activities who extended the parent activity can start their own process by calling the example process through "StatefulKnowledgeSession "

I completed following features in this iteration Messaging - send a text message in a task Location Access - give the GPS location by google play services. Sharing - sharing files through WiFi - direct and Bluetooth. Scan the tags - user can scan QR code and get data using ZXing bar-code reader Use Gallery - user can select pictures in storage.

I  continued working with the development of the Android version of the engine. In this iteration I implemented the following features to the prototype jbpm-android basically created by Kris Verlaenen. Browser Activity- open a search in browser through given link or user input words Camera Activity - User can use camera to capture images. In these Activities I created a separate Knowledge Base for each process. And in Last Iteration I am hoping to add all processes to a single knowledge base.

I  started working with the development of the Android version of the engine. First of all I studied the existing prototype created by Kris Verlaenen ( planet.jboss.org/jbpm5_lightweight_running_on_android ) . Then I started Implementing a task that will send a sms to anyone to their number. For this I used SmsManager . It can be archived by this, SmsManager smsManager = SmsManager. getDefault ( ) ; smsManager. sendTextMessage ( "phoneNo" , null , "sms message" , null , null ) ;

I completed the iteration with following features. Upgraded the UI Worked with JBPM Server Source Code Here are the screen shots attached with new UI Menu Screen Process & Task Dashboard Login Screen Process Definitions Process Instances Process Definition Details Task Description Task List

According to my timeline this is the tasks that I had to do, Continu ing working with the added features Optimiz ing the code Adding the feature of the Dashboards that will be available to the user. x I completed the iteration with following features. User can See the Process & Task Dashboard In Dashboard user can see in Tasks, the number of Total Tasks Tasks Completed In Dashboard user can see in Process Instances , the number of Total instances Completed instances Active instances Pending instances Suspended instances Aborted instances Screenshots are attached