Configuring proper roles to access ActiveVOS console using standard alone server

ActiveVOS serve that is embedded with designer does not have any login screen and by default you will be able to access the console that shows up dashboards, monitor, catalog and other features. But when you install ActiveVOS server as stand alone, you need to configure the server with
proper user and roles. Otherwise, you would not be able to access your http://localhost:8080/activevos page.

If you are familiar with Tomcat, you can add "admin" as user and role. Now you would be able to login as admin user. But you can't still see any contents as you do not have necessary privilege. You need to add these roles again your "admin" user to see proper contents of ActiveVOS console page.

For your reference, I am pasting contents from ActiveVOS site.

1) tomcat\conf\server.xml (file-based configuration)
<Realm className= "org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>


2) tomcat\conf\tomcat-users.xml file:

<role rolename="abTaskClient"/>
<role rolename="abServiceConsumer"/>
<role rolename="abAdmin"/>
<user username="admin" password="admin" roles="abAdmin, abTaskClient, abServiceConsumer"/>


 For further read, please follow this http://infocenter.activevos.com/infocenter/ActiveVOS/v92/index.jsp?topic=/doc.server_userguide/html/SvrUG3-4.html

ActiveVOS Error deploying BPR: No catalog mapping found for resource

I created a business process (BPEL) in ActiveVOS Designer and deployed in embedded server sucessfully. When I exported the process and deployed in standalone ActiveVOS server, the deployment failed. The ActiveVOS server spit the following error:

[INFO][CommonErrorHandlerProcess.bpr] Starting BPR archive deployment.
ERROR: [CommonErrorHandlerProcess.bpr] [CommonErrorHandlerProcess.pdd] Error deploying BPR: No catalog mapping found for resource "project:/org.activebpel.rt.email.services/wsdl/email.wsdl".
[INFO][CommonErrorHandlerProcess.bpr] Finishing BPR archive deployment.

After googling several times, I found that it was due to license issue. I have uploaded the license and the issue is resolved.

Before confirming it is license issue, you may have to follow the below steps:
1. Check if the server started successfully
2. Logon to ActiveVOS server console (http://localhost:6060/activevos)
3. Check the server status (Home --> Server Status)
4. Check the contribution (Catalog --> Contributions)
5. Check the resources after unchecking "Hide System" (Catalog --> Resources --> All)

Happy Orchestrating!

Tomcat authentication using Remote Address Filter / Remote Address Valve

Remote Address Filer or Remote Address Valve lets you to check the remote machine IP address and decide whether to allow or deny access. This is really useful when you want to enforce system to system authentication. Filter is nothing but an interceptor which will be used by Tomcat server to check if remote server can access the application. For more information, you can check the original documentation at http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Remote_Address_Filter. In this post, I am trying to explain the power of regular expressions in configuring IP addresses in allow or deny attribute.

 1. A sample valve configuration that allows access only to localhost is:

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127.0.0.1"/>

2. The "allow" attribute can take comma separated values to support configuring more than one remote IP address. This is useful when you have a few IP addresses. If you need to configure a big list of IP addresses, this is going to be tough for you. In this case, you can configure the filter with wild card character to allow (or deny) multiple IP addresses. Sample is as below:

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="10.110.156.*"/>

The above will allow from 10.110.156.0 to 10.110.156.255.

3. Alternatively, Tomcat server allows you to use regular expression to have fine control on the way IP addresses are being configured. Look at the below examples:

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="10\.110\.156\.\d{1,3}"/>

The above will allow IP addresses from 10.110.156.0 to 10.110.156.999. This is almost similar to output of wildcard example shown above.

4. You may want to still fine tune the values.

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="10\.110\.156\.[1-2][0-9]"/>

The above will allow IP addresses from 10.110.156.10 to 10.110.156.29 only.

So it is really up to how you write regular expression to achieve proper filtering of IP addresses. This link http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html can provide more detailed information on regular expressions.

Happy securing tomcat server!

Apache Camel - Failed to resolve endpoint: smtps://smtp.gmail.com:465

Problem:

While routing incoming JMS message to send mail using "smtps", camel is spitting this error:

Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: smtps://smtp.gmail.com:465?debugMode=true&password=bbb&username=aaa%40gmail.com due to: No component found with scheme: smtps
    at org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:534)
    at org.apache.camel.util.CamelContextHelper.getMandatoryEndpoint(CamelContextHelper.java:63)
    at org.apache.camel.model.RouteDefinition.resolveEndpoint(RouteDefinition.java:192)
    at org.apache.camel.impl.DefaultRouteContext.resolveEndpoint(DefaultRouteContext.java:106)
    at org.apache.camel.impl.DefaultRouteContext.resolveEndpoint(DefaultRouteContext.java:112)
    at org.apache.camel.model.SendDefinition.resolveEndpoint(SendDefinition.java:61)
    at org.apache.camel.model.SendDefinition.createProcessor(SendDefinition.java:55)
    at org.apache.camel.model.ProcessorDefinition.makeProcessor(ProcessorDefinition.java:500)
    at org.apache.camel.model.ProcessorDefinition.addRoutes(ProcessorDefinition.java:213)
    at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:909)
    ... 18 more

Camel configuration:
 
<bean id="myNotificationListener" class="MyNotificationListener"/>
  
<camel:camelContext xmlns="http://camel.apache.org/schema/spring">
   <route id="sendmailnotification">
      <from uri="activemq:queue:AuditQueue"/>
      <bean ref="myNotificationListener" method="onMessage"/>
      <setHeader headerName="subject">
        <constant>new incident reported</constant>
      </setHeader>
      <removeHeader headerName="JMSTimestamp">
      </removeHeader>
      <to uri="smtps://smtp.gmail.com:465?username=aaa@gmail.com&amp;password=bbb&amp;debugMode=true"/>
    </route>



Solution:
Please add camel-mail.jar and mail.jar to your classpath

Unable to locate Spring NamespaceHandler for XML schema namespace [http://camel.apache.org/schema/spring]

Problem:
Exception in thread "main" org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://camel.apache.org/schema/spring]
Offending resource: class path resource [camel-context.xml]


Solution:
Very simple: Add camel-spring.jar to classpath

How to access OracleConnection in Tomcat server

If you ever want to access underlying Oracle Connection in an application deployed in Tomcat server, you can use the following simple code.

try{
 java.sql.Connection connection = ConnectionManager.getConnection();
 OracleConnection ocn = connection.unwrap( OracleConnection.class );       
 XMLType xmlReq = new XMLType(ocn, rxml);
 ...
 ...
 ...

}catch(Exception e){
 e.printStackTrace();
}


For more documentation, please read http://docs.oracle.com/javase/6/docs/api/java/sql/Wrapper.html#unwrap(java.lang.Class)

Hope this tip is useful to you.

How to access oracle.jdbc.OracleCallableStatement object in JBoss or Tomcat servers

Though it may not be advisable to directly work on the underlying vendor specific API such as oracle.jdbc.OracleCallableStatement, how would do you access it when situation arises.

Use the below snippet for a JBoss deployed application:
public static OracleCallableStatement getOracleCallableStatement(java.sql.CallableStatement callableStatement) throws SQLException {
     OracleCallableStatement ocs = null;
if(callableStatement instanceof org.jboss.resource.adapter.jdbc.WrappedCallableStatement) {
            org.jboss.resource.adapter.jdbc.WrappedCallableStatement wc = (org.jboss.resource.adapter.jdbc.WrappedCallableStatement) callableStatement;
            Statement stmt = wc.getUnderlyingStatement();
            ocs = (OracleCallableStatement) stmt;
        }
       return ocs;
}

For java doc, please read http://docs.jboss.org/jbossas/javadoc/4.0.2/org/jboss/resource/adapter/jdbc/WrappedCallableStatement.html


Use the below snippet for a Tomcat deployed application:

public static OracleCallableStatement getOracleCallableStatement(java.sql.CallableStatement callableStatement) throws SQLException {
     OracleCallableStatement ocs = null;

if( callableStatement instanceof org.apache.tomcat.dbcp.dbcp.DelegatingCallableStatement) {
            org.apache.tomcat.dbcp.dbcp.DelegatingCallableStatement dcs = (org.apache.tomcat.dbcp.dbcp.DelegatingCallableStatement) callableStatement;
            ocs = (OracleCallableStatement)dcs.getInnermostDelegate();
        } 

       return ocs;

}

Hope this is useful. Let me know if comments.

Enable access log in JBoss application server

Go to %JBOSS_HOME%\server\default\deploy\jboss-web.deployer folder and you will find server.xml. The Access logger is disabled by default. Just un-comment the access logger section and restart the JBoss application server. Rest is taken care.

Here is the Access logger configuration.
<Valve className="org.apache.catalina.valves.FastCommonAccessLogValve" prefix="localhost_access_log." suffix=".log" pattern="common" directory="${jboss.server.home.dir}/log" resolveHosts="false" />
The access log file will be created with the name - "localhost_access_log.2014-02-06" . The file is rotated every day. However, if required, you can modify the file name by reconfiguring. Generally, I would prefer to name it like node1_hostname_access.log where hostname is the name of the server in which JBoss is running. This will allow me to process and analyze several log files in a cluster environment without any ambiguity.

As other standard servers support, JBoss also supports two log format patterns - 1) common and 2) combined.

Apart from common and combined, you can also customize the log format as you wish. I have customized to my requirement as follows: -
 
<Valve className="org.apache.catalina.valves.AccessLogValve"
                prefix="node1_hostname_access." suffix=".log"
                pattern="%a %A %u %t %r %s %T %b %S" directory="${jboss.server.home.dir}/log"
                resolveHosts="false" />

Please read https://docs.jboss.org/jbossweb/latest/config/valve.html for more information on the parameters.

See below sample access log generated.

127.0.0.1 10.xx.xx.xx- [06/Feb/2014:16:01:07 +0530] GET /web-console/ HTTP/1.1 304 0.007 - -
127.0.0.1 10.xx.xx.xx- [06/Feb/2014:16:01:07 +0530] GET /web-console/applet.jsp HTTP/1.1 200 0.041 444 93300E3B983D53F8BE5FB39901E48B6B
127.0.0.1 10.xx.xx.xx- [06/Feb/2014:16:01:07 +0530] GET /web-console/ServerInfo.jsp HTTP/1.1 200 0.060 4226 93300E3B983D53F8BE5FB39901E48B6B
127.0.0.1 10.xx.xx.xx- [06/Feb/2014:16:01:07 +0530] GET /web-console/css/jboss.css HTTP/1.1 304 0.000 - 93300E3B983D53F8BE5FB39901E48B6B
127.0.0.1 10.xx.xx.xx- [06/Feb/2014:16:01:07 +0530] GET /web-console/images/logo.gif HTTP/1.1 304 0.000 - 93300E3B983D53F8BE5FB39901E48B6B
127.0.0.1 10.xx.xx.xx- [06/Feb/2014:16:01:07 +0530] POST /web-console/Invoker HTTP/1.1 200 0.439 2245739 93300E3B983D53F8BE5FB39901E48B6B
127.0.0.1 10.xx.xx.xx- [06/Feb/2014:16:01:07 +0530] GET /web-console/%5bLorg/jboss/console/manager/interfaces/ResourceTreeNode.class; HTTP/1.1 404 0.001 1177 93300E3B983D53F8BE5FB39901E48B6B


Hope you liked the tip.

HTTP 500 error and Chunked encoding in OSB/WebLogic

Till recently, there was a strange issue seen in peak time with my production WebLogic Server. I have a bunch of Web Services deployed in CXF in WebLogic server. The message flow is as below: -

External Load balancer --> OSB --> External Load balancer --> (CXF in) Web Logic


While up to 95 to 98% of the requests sent to WebLogic had been processed successfully, the remaining requests were timed out in 30 seconds by WebLogic server. When I looked at the access log generated in the WebLogic server, all timed out requests had recorded with HTTP status code 500.  It took a while to understand, isolate and resolve the issue.

I did a thread dump analysis and saw several hogging threads with a kind of trace given below:


"[ACTIVE] ExecuteThread: '43' for queue: 'weblogic.kernel.Default (self-tuning)'" RUNNABLE native
         
                java.net.SocketInputStream.socketRead0(Native Method)
         
                java.net.SocketInputStream.read(SocketInputStream.java:129)
         
                weblogic.servlet.internal.PostInputStream.read(PostInputStream.java:142)
         
                weblogic.utils.http.HttpChunkInputStream.readChunkSize(HttpChunkInputStream.java:115)
         
                weblogic.utils.http.HttpChunkInputStream.initChunk(HttpChunkInputStream.java:74)
         
                weblogic.utils.http.HttpChunkInputStream.skip(HttpChunkInputStream.java:203)
         
                weblogic.utils.http.HttpChunkInputStream.skipAllChunk(HttpChunkInputStream.java:378)
         
                weblogic.servlet.internal.ServletInputStreamImpl.ensureChunkedConsumed(ServletInputStreamImpl.java:35)
         
                weblogic.servlet.internal.ServletRequestImpl.skipUnreadBody(ServletRequestImpl.java:194)
         
                weblogic.servlet.internal.ServletRequestImpl.reset(ServletRequestImpl.java:152)
         
                weblogic.servlet.internal.MuxableSocketHTTP.requeue(MuxableSocketHTTP.java:195)
         
                weblogic.servlet.internal.VirtualConnection.requeue(VirtualConnection.java:329)
         
                weblogic.servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:1538)
         
                weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1455)
         
                weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
         
                weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
After further investigation, I found that the WebLogic server was not receiving the message within the default POST TIMEOUT (30 seconds) configured in the WebLogic server. Increasing the time out value to 45 or 60 seconds did not help. It only aggravated the performance issue.

Let's look at how the issue was resolved. When you define a business service in Oracle Service Bus (OSB), you would have seen a parameter namely "Use Chunked Streaming Mode" under "HTTP Transport Configuration" section. The default value was configured as "Enabled". Apparently, the load balancer was not able to handle requests with chuncked encoding in peak time. It was unable to transmit the request message to the WebLogic server within the configured post timeout period. It can be validated against the thread dump shown above. After changing the value from "Enabled" to "Disabled", the 500 error has been eliminated permanently and now the server is in good health.

Thanks for reading this post and hope you liked the tip. Please feel free to post your comment here.