WebSphere Portlet Factory designer - how to setup the debugging mode

Configuring a server for debugging a model

An example procedure based on the IBM WebSphere Application Server can show you how to debug a model.

1. To configure the WebSphere Application Server for debugging, use the IBM WebSphere Portal server or WebSphere Application Server Admin tool.
   • For portlets

     Access WebSphere Portal server Configuration page. Click Servers > Application Servers > WebSphere Portal.

   • For standalone applications and widgets

     Access the application server Configuration page. Click Servers > Application Servers > server1.

2. On the Configuration page, under Additional Properties, select Debugging Service.

   This link provides access to the application server Debug General Properties page.

3. On the Debug General Properties page, make server debugging possible by enabling the Startup check box.
4. On the Debug General Properties page, make a note of the port number to be used for debug output.
5. Optional: For a portlet, you can also set various debug parameters for WebSphere Portal server, including the JVM Debug Port. IBM WebSphere Portlet Factory Designer can connect to the JVM Debug port to receive debug information.

Running a model in debug mode

After you configure the server for debugging, follow these steps to initiate debugging of Java code:

1. Add a breakpoint to the code.
   1. Open the Java source file for an LJO or the generated Java source file for the model.

      For example, for a model named "Test" in the WEB-INF/models directory, you would find its generated Java source file in: WEB-INF/factory/generated/genjava/_Test.java

   2. Set a breakpoint at the desired spot in the code.
2. Run the Model to Initiate Debugging.
   1. In IBM WebSphere Portlet Factory Designer, choose Run > Debug Configurations > Remote Java Application > the name of your model
   2. Click the debug button
   3. Wait until the debugger is finished loading.
   4. Debug the code for your model as you would any other Java application.

Whats new in WebSphere Portal 7.0

Following are few changes in WebSphere Portal 7

1. Configuration Wizard - Graphical Config wizard can be used for the tasks like to enable the security in WebSphere Portal 7.0 with LDAP, transferring data to different database other than executing command line configuration tasks.

2. ConfigEngine - New tasks have been added to capture the automated logs in case any case open with IBM support.

3. Blog and Wiki - Now you can easily create Blog and Wiki on a Portal page using Add content widget in Page Builder theme. Web Content Management APIs can be utilize to extend the Blog and Wiki functionality.

4. Page Builder Theme.

5. Portal Light Mode.

6. Impersonation.

7. WebDav support

8. Tagging and Rating.

Jakarta Commons Digester VS XMLBeans

Jakarta Commons Digester

Many Jakarta projects read XML configuration files to provide initialization of various Java objects within the system. There are several ways of doing this, and the Digester component was designed to provide a common implementation that can be used in many different projects. Basically, the Digester package lets you configure an XML -> Java object mapping module, which triggers certain actions called rules whenever a particular pattern of nested XML elements is recognized. A rich set of predefined rules is available for your use, or you can also create your own. Advanced features of Digester include:

* Ability to plug in your own pattern matching engine, if the standard one is not sufficient for your requirements.

* Optional namespace-aware processing, so that you can define rules that are relevant only to a particular XML namespace.

* Encapsulation of Rules into RuleSets that can be easily and conveniently reused in more than one application that requires the same type of processing.

XMLBeans

At a high level XMLBeans is an XML-Java binding tool that uses XML Schema as a basis for generating Java classes that you can use to easily access XML instance data in a natural manner in your Java programs. It was designed to provide both easy access to XML information via convenient Java classes as well as complete access to the underlying XML, combining the best of low-level APIs like SAX and DOM that provide full access with the convenience of Java binding. There are several factors that set XMLBeans apart from any other XML-Java binding alternatives:

* XML Schema Compliance - XMLBeans has achieved extremely high schema compliance and is able to compile even the most complex schemas. This is critical when adopting an XML-Java binding framework since you may received schemas that are out of your control.

* Access to the full underlying XML Infoset - The XML Cursor API allows you to access a lower level DOM like access to the underying XML Infoset. You can get a "cursor" at any point while using the strongly typed generated XMLBeans and begin navigating the underlying XML instance.

* Access to the schema type system - The XMLBeans schema API allows you to walk through the schema type system giving you full access to a Java object representation of the XML Schema that was compiled to generate the XMLBeans classes.

* Speed - XMLBeans is optimized for performance at many levels. For example, XMLBeans lazily constructs objects from XML, so that you do not have the performance overhead of object creation when you only access portions of an XML document. Several Fortune 500 customers have adopted XMLBeans based on speed alone.

Digester Vs XMLBeans

Digester is just a convenient thin wrapper for SAX. it's mostly used as a xml to object mapper, but not the object to xml.
It executes rules when certain SAX events are received. this means that it can be used for purposes other than just mapping and that as a mapper it is very, very flexible and extensible.

JAXB, xml beans and castor. they provide complet marshalling and unmarshalling services. They map object graphs into xml and verse-versa.

If we have an xml-schema or DTD and want to generate java beans then a generative start-from-xml solution is most suitable. if you have an existing object model that you want to express as xml then a
start-from-java will be more suitable.

if you have an object model that you want to build up from xml then digester is a very good match. there's a lot less to learn than a object <-> xml mapper - especially if you write your own rules. Digester is often a better match if you already have
a particular object model and you don't care about Object to XML mapping.

in terms of performance, digester is a very thin wrapper around SAX and so is efficient providing that you're willing to avoid reflection by writing your own rules. the best plan is probably to start with the rules that digester ships with and then optimize if performance becomes
an issue.

Java Open Source

Simple Logging Facade for Java

Simple Logging Facade for Java

The Simple Logging Facade for Java or (SLF4J) is mainly serve as a simple facade for various logging APIs allowing to the end-user to plug in the desired implementation at deployment time.
SLF4J also allows for a gradual migration path away from Jakarta Commons Logging (JCL). Logging API implementations can either choose to implement the the SLF4J interfaces directly, e.g. NLOG4J or SimpleLogger. Alternatively, it is possible (and rather easy) to write SLF4J adapters for the given API implementation, e.g. Log4jLoggerAdapter or JDK14LoggerAdapter.

I would always prefer a Logging facade instead of the framework directly. Advantages: - change the underlying logging framework by configuration - combine your program code with other 3rd party libs an use a common implementation

It's also very easy to understand and you can combine it even with an own implementation.