Ivan Krizsan

Ranch Hand
+ Follow
since Oct 04, 2006
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Ivan Krizsan

Hello!
I am now in the process of uploading a corrected version of the PDF book. It should be available for download soon.
Thanks again for pointing this error out to me!
Best wishes!
Ivan Krizsan
Hi!
Thanks for pointing this out to me!
I thought I had re-generated the table of contents but apparently something went wrong.
The document is, as far as I know, complete so you do have the entire book.
I will look into this as soon as possible!
Best wishes,
Ivan Krizsan
Hello!
The simplest way that I could think of to keep track of the number of instances of the session bean was a writeable static field, as seen in the example.
This was done in order to show when a certain instance of the session bean is instantiated and destroyed and how many instances of the session bean are created.
There is nothing in the instructions that suggests using the example in a distributed environment.
I have included a comment on the reason for using a writable static field in the latest version of the study notes.
Thanks for bringing this to my attention!
Best wishes!
Ivan
Hi!
Finally, a new version of the book is available.
The above mentioned example has been corrected, as well as a number of other mistakes and typing errors I made.
Best wishes!
Hi!
Thanks for pointing this out!
I will update the notes as soon as I am able to.
Best wishes,
Ivan
Hi!
Jersey is a REST web service stack that aids in implementing RESTful or RESTlike web services.
Mule is an ESB, which also support routing, transformation etc of messages.
If you are to develop a RESTful web service, then use Jersey. If you are to develop an integration solution that allows multiple systems or components of one single system to communicate with each other, then I would use Mule.
Mule allows you to expose a RESTful web service, but may be overkill if that is all you want to do.

Mule configurations are Spring configurations, so integration with an application that use the Spring framework is very easy.
Best wishes!
11 years ago
Hi again!
I have further improved the solution I earlier posted. Changes are:
  • Introduce a trait as interface of the service.
  • Remove the service child class that mixed in the trait(s) implementing non-business concerns.
  • Perform mixin of the trait(s) implementing non-business concerns at service instance creation time.
  • Eliminated the MyApplicationServiceExceptionHandling trait.
  • Eliminated the class MyApplicationServiceWithExceptionTranslation.
  • Added a trait to perform logging (non-business concern).


  • Code speaks louder than words, so here is the modified example program. The domain and exception classes are the same as in the above post, so please refer to that post for implementation of those classes.










    Note that the order in which the traits are mixed in is significant. Try experimenting with the logging trait first and look at the exceptions logged.
    I feel that this new solution is more elegant than the previous one. One possible drawback may be that it will be difficult to re-use traits implementing non-business concerns with different services.
    Best wishes!
    11 years ago
    Hi!
    Sorry, I have no plans on any other formats of the study notes.
    I will surely consider requests like this if, by any chance, I write study notes for a newer version of the certification.
    For those interested in self-publishing electronic books in several formats and perhaps even get paid for it, I would like to recommend having a look at LeanPub:
    https://leanpub.com/
    Best regards!

    P.S. I am in no way affiliated with LeanPub except for the fact that I consider publishing books there.
    Hi!
    As at some previous occasions, I will answer my own question. I will do it with an example that uses pure Scala.
    In this very simplistic example, there is one domain class that is used by an application service. In addition there is a client of the service.
    The domain class is written to throw different kinds of generic exceptions:


    Then there is the application service class that calls the above domain class.

    As you can see, the service class do not contain any exception handling or translation. This is the goal of this exercise - I do not want to clutter the service class, containing application logic, with error handing, logging, exception translation etc. Despite this, I want the service to throw application-specific exceptions to clients in case of errors.

    As an interlude and in order to make the example complete, here are the classes implementing the application-specific exceptions:




    Then there is a client of the application service, which also is the starter class of this example:


    If we run the example program in its current incarnation, we obtain the following output:


    Trying with a message that is too short
    Unexpectedly received another exception :java.lang.IllegalArgumentException
    Trying with a number that is too small (negative)
    Unexpectedly received another exception :java.lang.IllegalArgumentException
    Trying with a number that breaks an assumption
    Unexpectedly received another exception :java.lang.AssertionError
    Trying with good parameters, which should result in an exception that should be passed through
    Received IOException as expected: cannot read data



    In three of the four cases, the client received an exception that I did not want it to receive.
    So, how do we fix this without adding code to the service class and use only pure Scala?
    The solution I have devised uses traits. I separate all the exception translation code into the following trait:


    To bring the above trait together with the service class, I implement a child class to the service class:


    Finally, we modify the client to instantiate the child service class instead of the original service class. Note also that I have uncommented one import:


    If we now run the example program, we get the following output:


    Trying with a message that is too short
    Received a MessageTooShortException as expected: The message 'a' is too short
    Trying with a number that is too small (negative)
    Received a NumberTooSmallException as expected: The number '-1' is too small
    Trying with a number that breaks an assumption
    Received a AssumptionBrokenException as expected: Assumption broken: assumption failed: the result of doubling the number must not become 4
    Trying with good parameters, which should result in an exception that should be passed through
    Received IOException as expected: cannot read data



    I succeeded in separating application logic, in the application service, and exception translation!
    There is more, but interested readers need to wait for my next book to read about the details.
    Best wishes!
    11 years ago
    Hi!
    I have an application service that receives certain exceptions from the domain layer and possibly underlying layers.
    I would like to translate received exceptions to application-specific exceptions, but would prefer to separate the code that performs the translation, so that it does not make the code in the service class more difficult to understand.
    Is there a way to accomplish this in Scala?
    Thanks in advance!
    12 years ago
    Hi!
    I have written a book on Mule 2.x and Mule 3.x that contains two parts.
    The first part consists of several step-by-step examples. The second part consists of reference/recipes on different areas of Mule.
    The book is free and a PDF can be downloaded here: http://www.slideshare.net/krizsan/ivans-mule-tutorial
    You need to register on Slideshare before being able to download, which also is free.
    If you find any errors or have suggestions for improvements, please do not hesitate to contact me here on JavaRanch!
    Best wishes!
    12 years ago
    Hi!
    I don't know what you mean by "root collections".
    From what I suspect I understand, I would return URLs pointing to the static images in responses of the web service. The client can then decide whether to request an image or not and at which time to send the request.
    Best wishes!
    12 years ago
    Hi!
    How have you created the project you are working in? Did you use a Maven archetype?
    Is your aim to run Mule embedded in the web application or embedded in web application container to which you are to deploy your Mule application?
    Are you able to compile the project, using Maven, without any errors (i.e. just execute "mvn compile")?
    Best wishes!
    12 years ago
    Hi!

    Anirudh Gupta wrote:
    However, I have formed this impression that Weblogic 12C and Glassfish 3.1.1 implementation of Interceptors is not complete,
    and what is full of errors. Will shortly post the Error Description and Stack Trace here.


    I recommend also creating a bug-ticket for the relevant product. I do not know about Weblogic, but GlassFish, being open source, has a JIRA bugtracking system here: http://java.net/jira/browse/GLASSFISH
    I have had only good experiences from reporting bugs back to the community.
    Best wishes!
    Hi!

    Ong Vua wrote:
    I couldn't find any Dispatch interface for JAX-RPC. I only found Call. Is that correct?


    Yes, Call is the JAX-RPC equivalent to the Dispatch interface.
    Here is an article that shows how to use it, in case you have any doubts: http://www.ibm.com/developerworks/webservices/library/ws-javaclient/
    Best wishes!
    12 years ago