Components have access to a logger (java.util.logging.Logger) which is initially configured by the CDK.
This logger can be got by using the method AbstractComponent#getLogger().
In the different component classes, such as the message listeners or the service-unit manager, you can access the component and its logger.
However, you have to be careful about the way you log things.
\\
For the moment, logs mix both messages and exceptions that occur in the component.
Unfortunately, it is not possible to proceed differently for the moment.
This should be changed in future versions of the CDK.
Logs format can also be configured, but it is not easy.
A potential good practice to make your log more readable would be to append the name of your component as a prefix to the first message.
The timestamp is logged by default.
Here are some good-practices to respect when you use logs in your component.
\\
{tip}
*Log guideline 1*
Make your message have less than 80 characters per line.
{tip}
Logs may be displayed in a shell.
Therefore, this limitation of 80 characters should be respected as much as possible.
*Line 1:* a message of less than 80 characters.
*Following lines (optional):* a stack trace.
\\
{tip}
*Log guideline 2*
Check the log level before logging (This is highly recommended when logging contains expressions and time consuming things such as XML serialization\!\!\!).
{tip}
This will increase performances by avoiding useless or undesired logs.
Example:
{code:lang=java}
Logger log = getLogger();
if( log.isLoggable( Level.INFO ))
log.info( "your log message" );
Logger log = getLogger();
if( log.isLoggable( Level.DEBUG ))
log.debug( "your log message" );
{code}
\\
{tip}
*Log guideline 3*
Use the severe() method only for events that should not have happened or for critical things.
{tip}
This log method means an error occurred.
When an error occurs, an error should also be set on the exchange, and not just be logged as an error.
\\
{tip}
*Log guideline 4*
Do not hesitate to use the debug() method.
{tip}
It will definitely help to maintain the component.
\\
{tip}
*Log guideline 5*
For very exchange your component processes, leave an info message.
{tip}
\\
{tip}
*Log guideline 6*
Use warning() only for caught exceptions, that do not result in a fault or an error.
{tip}
Faults and errors are sent back.
It is useless to handle them twice.
\\
{tip}
*Log guideline 7*
Some exceptions should result in faults and errors, not in logs.
{tip}
Faults are business faults. It means something went wrong with respect to the application mission.
Errors are technical errors, that arrive at the bus level.
Faults and errors must be set on the exchange.
\\
{tip}
*Log guideline 8*
Logs written during the processing of an exchange should start with the exchange ID.
{tip}
Each exchange has an ID.
When processing an exchange, this ID should be the first thing to be logged, followed by a log message.
A typical place where this must be applied is in JBI listeners.
\\
{tip}
*Log guideline 9*
Logs written during the life cycle update of a service-unit should start with the service-unit name.
{tip}
Each service-unit has a name.
Whe updating the life cycle of a service-unit, this name should be the first thing to be logged, followed by a log message.
A typical place where this must be applied is in service-unit managers.
{tip}
{color:#333333}{*}Log guideline 10{*}{color}
{color:#333333}Do not add timetamps, class names (or similar things) programmatically.{color}
{tip}
This is time consuming and can be configured with the logger configuration file if needed.
h1. Last minute check list
So, that's it? You have created and implemented your component.
Maybe you also tested it. Before going further, check some little things.
h2. Checking code quality
\\
{tip}
*Guideline 1.a*
Class organization is easy to explain and to understand for a developer having read this document.
{tip}
Generally, components code is not huge.
But it can be very complicated. High cohesion and low coupling are essential in object-oriented programming.
Working on these aspects ease the maintenance of your component.
\\
{tip}
*Guideline 1.b*
The component implementation has been reviewed or checked with tools like FindBugs.
{tip}
Sometimes, inattention errors or multiple code updates can lead to errors and problems at runtime.
Use IDE tools to check your code. Tools like FindBugs bring you a 1-click check and highlights programming errors.
\\
{tip}
*Guideline 1.c*
Overridden CDK classes were overridden for a valid reason.
{tip}
If you override CDK classes, there must be a reason.
By default, only two classes need be completed: the JBI and the external listeners. Overriding CDK classes if it is not necessary increases the complexity of your component and its maintenance.
\\
{tip}
*Guideline 1.d*
Shared-libraries were used when possible.
{tip}
Some components need additional libraries. Sometimes, several components need the same library.
Petals offers the possibility to share a same library in a common artifact called a shared-library. This requires the components to have a dependency to the same version of a library. The advantage is that it makes your component size lighter.
h2. Checking XML schema
\\
{tip}
*Guideline 2.a*
Every element in the component XML schema is processed in the implementation.
{tip}
One detail to take care of, is the coherence of the component XML schema with the parameters processed in the component implementation.
\\
{tip}
*Guideline 2.b*
Every element defined in the component XML schema is meaningful.
{tip}
Another bad habit is to drag useless or temporary parameters in XML schema.
Modify configurations structures result in migration issues. Therefore, an effort brought on this part can avoid future troubles.
\\
{tip}
*Guideline 2.c*
Names from XML schema elements are meaningful. Composed names are separated by a '-' character.
{tip}
Element names should have a clear meaning and not be ambiguous. Composed names are encouraged and should be separated with a '-' symbol.
\\
{tip}
*Guideline 2.d*
Names from XML schema elements are valid English words or known acronyms.
{tip}
Element names should be valid English words or acronyms that anyone can understand (use a dictionary if necessary).
\\
{tip}
*Guideline 2.e*
XML schema should have a minimal number of complex types and use simple types as much as possible.
{tip}
Keep your XML schema simple.
Prefer two simple fields with a composed name rather than a complex type with two simples fields.
In particular when the complex type cannot appear more than once.
\\
{tip}
*Guideline 2.f*
The CDK version in the pom.xml matches the one mentioned in the component XML schema.
{tip}
Another usual error is related to the version of the CDK.
It sometimes happen that the CDK version specified in the pom.xml file does not match the version specified in the component XML schema.
If you use the version 5.0 in your pom.xml, then the CDK name space in the XML schema must be 5.
h2. Checking coherence
\\
{tip}
*Guideline 3.a*
Your component provides a default WSDL in case where a service-unit does not have one.
{tip}
Every configuration should provide a WSDL file.
However, in some cases, it happens that no WSDL is provided. In which case your component should provide one.
\\
{tip}
*Guideline 3.b*
Operations and MEPs, as processed in the component, are coherent with the WSDL content.
{tip}
If your component checks operation names and/or message exchange patterns, you should make sure these treatments are compatible with the WSDL elements.
At least, in the one provided by your component.
\\
{tip}
*Guideline 3.c*
Faults, as processed in the component, are coherent with the WSDL content.
{tip}
In the same way, if your component sets faults on exchanges, these faults should be declared in the WSDLs.
At least, in the one provided by your component.
\\
{tip}
*Guideline 3.d*
Returned messages, as built in the component, are coherent with the WSDL content.
{tip}
If your component returns messages, the structure of these messages should be coherent with the WSDL operation messages.
At least, in the one provided by your component.
\\
{tip}
*Guideline 3.e*
All the actions performed on the exchange are compatible with the processed MEP.
{tip}
Message exchange patterns define very strictly the actions you can do on an exchange.
E-mail
...