When Googling the web for a flexible and secure way to shutdown an embedded Jetty server programmatically i found some examples. These examples were nor safe because the server could be shutdown by guessing the correct uri initiating the shutdown, or did require extra interfaces (sockets) listening on the loopback interface to initiate the shutdown. When writing my own embedded Jetty concept i had 4 requirements. First, it should be practically impossible to stop the Jetty server from outside the application (unless you have a special key). Secondly, it must be possible to stop the Jetty server from any servlet. No extra implementations of socket listeners. Last, when initiating a stop of Jetty anywhere in the code, is should be able to set the exit or return code to the underlying operating system.

Here in a nutshell how i realized all these requirements.

Tweet
Read More...

Weblogic Server provides runtime MBeans which provide information about the runtime state of its resources. The entry point for these MBeans are the MBeanServer Services. There are two Runtime MBeans, the DomainRuntimeServiceMBean, which is only available at the Administration Server and the RuntimeServiceMBean which is the entry point for WLS runtime MBeans for the current server. WLS runtime MBeans can provide information about the runtime state of WebLogic Server resources. An overview of the available Runtime MBeans can be found in the Weblogic Server MBean Reference. Sometimes it can be useful to retrieve data from these Runtime MBeans in a BPEL process. For example the name of the Weblogic domain, the machine or the managed server whereon the BPEL process is running.

Here is an example how you can retrieve the Weblogic Domain Name, Machine Name and Server Name whereon the BPEL instance is running.

Tweet
Read More...

For a small Java project is was searching for a standard JDK Class to read a XML configuration file into a Java bean. Important was that the structure of the XML file was maintainable by humans using external editors and not necessarily all elements in the XML file had to match attributes in the Java bean(s) wherein the contents of the XML file is stored. The XMLDecoder class in the java.beans package only can de-serialize objects encoded using the XMLEncoder class and therefore is less useful for his purpose.


Based on Java's SAXParser and a relative simple handler extending DefaultHandler, i was able to parse an external editable XML into a Java bean holding (ArrayLists of) other beans as attributes, also capable of holding one or more Java Beans as attributes.

Tweet Read More...

In my current project the BPEL development team, wherein i participate, maintains and develops BPEL processes on 10g. The complexity of these processes are not the processes itself but merely the applied transformations in these processes which also contain custom XSL functions. Testing of the XSL transformations within the IDE (JDeveloper) therefore is in many cases not an option. Alternatively the whole service has to be deployed to a local installed BPEL server and tested by instantiating the service. The main disadvantage here is that BPEL keeps it XSL files in cache, even the XSL files which were re-deployed. So when testing a re-deployed service with modified XSL files, the results of the transformations are unchanged, simply because the 'old' version of the XSL files are still in memory. To load the modified XSL files in memory the BPEL server has to be re-started after each deployment. When having to go though multiple iterations of testing and therefore time-consuming restarts of the local BPEL server can be quite annoying.

Tweet Read More...

After 18 months following the Java Certified Professional Program at the Open University I finally may call myself a certified java developer. In the past months subjects like UML, Object Orientation, Java Collection Framework, Swing, JSP, JSTL, EL, Struts and Spring have come by. The last assignment of this CPP was designing and building a basic online auction system. On top of the minimum requirements I added some extra features; Category administration, member registration confirmation and password reset through links in e-mail, article images, SMS bid notification and an automatic invoice generation system.

If interested, you can experience it here.

Tweet

A last one to conclude this series of Siebel CRM monitoring framework articles. Just to show how relative simple it is to build your own custom Siebel monitors. Every active user accessing Siebel using the web client interface has a session which is maintained by a dedicated Siebel task. These sessions are listed in the Server Session view on the Server Administration Screen. In this screen you can see that every session has a unique task identifier. When selecting the State Value detailed view all state values belonging to the task associated with the session are shown. If the session belongs to a Siebel Object Manager, one of the state values is View Name containing the name of the current Siebel view. The Business Components associated to the views are SA-VBC Session and Server Task State Value. By querying all active session in Business Component SA-VBC Session and counting the number of views per view name in Business Component Server Task State Value you get a aggregated list of all active views.

Tweet Read More...

Active Siebel multithreaded components like the SRBroker or ObjectManager usually consist of multiple MultiThreaded Servers (MTServers) and Tasks to handle multiple simultaneous requests or Siebel sessions. More common naming for a Siebel is a MTServer is processes, which is typically independent, have a separate address space and can be identified on an operating system by its process id (PID). Siebel Tasks are threads spawned by a process and do run in the same memory space as its parent process. Per multithreaded component the number of minimum, default or maximum processes (MTServers) and threads (Tasks) can be configured by the component parameters. The number of processes and tasks are component parameters, not process or tasks parameters. Important to comprehend is that the actual number of threads is distributed over the instantiated processes.

I have not yet seen a monitor which can monitor the distribution of the Tasks for MTServers and visualize this in a clear way. So therefore i gave it a shot to create one myself.

Tweet
Read More...

In my previous post i introduced a simple monitoring framework for Siebel CRM written in Java. Since it is a framework adding monitors should be a straightforward process. To put it to the test i wrote the Java class SBLWorkflowProcMonitor extending the abstract class SBLMonitor to monitor; the number of workflows in a specific state, average duration of the workflows and the number of completed workflows per time unit.

Tweet Read More...

I have built some monitoring scripts in Perl and Shell in the past years, of which most needed a lot of code to realize an interface with the application and exception handling functions to catch and process every possible error i could think of. In other words, it was quite a challenge to get a stable and reliable working monitoring script. Besides that, not every customer had a Perl interpreter installed on their servers or ran Siebel on another platform than Unix (in all its variations). Since most of the scripts do retrieve the information from the Siebel server manager, i questioned myself if there was not a better way to develop siebel monitors. Monitors which could retrieve information from Siebel using an API instead from wrapper scripts around command-line utilities. Java is more generic available on any platform and Oracle offers a SiebelDataBean which enables to interface with Siebel CRM. So i gave myself the challenge to design and develop a small monitoring framework to monitor the Siebel CRM application which should be easily extendible.

Tweet

Read More...

How to install the source code from Bruce Eckels book the “Annotated Solution Guide for Thinking in Java 4th edition” on OS X.

Tweet Read More...

Tags: Java