2012/07/26

Jenkins in Weblogic Application Server 12c

To deploy jenkins in Weblogic server 12c you need a little ajustment as it is described in "Install the Jenkins as a WAR to the Weblogic server".

Here a bash shellscript using "Here Documents" to do it faster:

---------------------------------------------------------------------------------------
#!/bin/bash
TARGET=$1

if [ -z "$TARGET" ] || [ ! -e $TARGET ]
then
        echo "I need an absolut path to the jenkins war!"
        exit 1
fi

TMPDIR=$HOME/tmp/jenkins-ci/jenkins
MYPWD=$(pwd)
rm -fr $TMPDIR
mkdir -p $TMPDIR
cd $TMPDIR
unzip $TARGET

cat > WEB-INF/weblogic.xml <<ENDOFMESSAGE
<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-web-app
    xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsdhttp://xmlns.oracle.com/weblogic/weblogic-web-apphttp://xmlns.oracle.com/weblogic/weblogic-web-app/1.2/weblogic-web-app.xsd">
    <wls:weblogic-version>10.3.4</wls:weblogic-version>
    <wls:context-root>jenkins</wls:context-root>
    <wls:container-descriptor>
        <wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes>
    </wls:container-descriptor>
</wls:weblogic-web-app>
ENDOFMESSAGE

mkdir -p $MYPWD/weblogic
RESULT=$MYPWD/weblogic/jenkins.war
zip -r $RESULT *

ls -l $RESULT

---------------------------------------------------------------------------------------

 Example:

./weblogic-jenkins.sh jenkins.war

Enjoy!

2012/03/25

Preparing a USB stick using a network installer CD for Debian Squeeze

It can not be easier!

To install Debian GNU/Linux from network using a USB stick, download an installer image from here, from here if you need some non-free firmware or from here for the freshest version available.

Insert your usb stick and identify the device using dmesg.

dmesg

.
..
...
[3848496.714205] usb 3-2: new high speed USB device using ehci_hcd and address 4
[3848496.847464] usb 3-2: New USB device found, idVendor=03f0, idProduct=5307
[3848496.847468] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[3848496.847472] usb 3-2: Product: v165w
[3848496.847475] usb 3-2: Manufacturer: HP
[3848496.847478] usb 3-2: SerialNumber: 00000000000064
[3848496.847595] usb 3-2: configuration #1 chosen from 1 choice
[3848497.230156] Initializing USB Mass Storage driver...
[3848497.230383] scsi8 : SCSI emulation for USB Mass Storage devices
[3848497.230523] usb-storage: device found at 4
[3848497.230527] usb-storage: waiting for device to settle before scanning
[3848497.230541] usbcore: registered new interface driver usb-storage
[3848497.230548] USB Mass Storage support registered.
[3848502.230522] usb-storage: device scan complete
[3848502.231119] scsi 8:0:0:0: Direct-Access     hp       v165w            0.00 PQ: 0 ANSI: 2
[3848502.233229] sd 8:0:0:0: [sdh] 7892040 512-byte logical blocks: (4.04 GB/3.76 GiB)
[3848502.233720] sd 8:0:0:0: [sdh] Write Protect is off
[3848502.233724] sd 8:0:0:0: [sdh] Mode Sense: 00 00 00 00
[3848502.233728] sd 8:0:0:0: [sdh] Assuming drive cache: write through
[3848502.236846] sd 8:0:0:0: [sdh] Assuming drive cache: write through
[3848502.236851]  sdh:
[3848502.906878] sd 8:0:0:0: [sdh] Assuming drive cache: write through
[3848502.906884] sd 8:0:0:0: [sdh] Attached SCSI removable disk


So, in my case the device is /dev/sdh:

cat firmware-6.0.4-amd64-netinst.iso > /dev/sdh
sync


That's it, just boot from the USB stick and enjoy!

2012/01/08

JBoss Messaging Message Bridge Configuration and Weblogic

Some days ago I had to deploy a JBoss Application Server 5.1 (JBoss AS) as integration point between a Weblogic Application Server 11g (WLS) and some another rare artifacts. Just like that.

Messages sent into a first JMS queue, provided by the JBoss AS, must be consumed by a Message Driven Bean (MDB) located in the WLS and some messages must be produced into a second JMS queue. But a remote queue is not something you can inject into a EJB.

A messaging bridge had to be placed in between:

















Here the messaging bridge service is provided by the integration server, in this case the JBoss AS (node B). So, the explanation is done from the integration point of view.

Step 1

In your JBoss AS, edit the file you_server_configuration/deploy/messaging/jms-ds.xml and add the following blocks of xml code to define the two bridges and the remote provider:


<connection-factories>
...

<!-- RemoteJMSProvider for WLS -->
<mbean code="org.jboss.jms.jndi.JMSProviderLoader"
  name="jboss.messaging:service=JMSProviderLoader,name=RemoteJMSProvider">

    <attribute name="ProviderName">RemoteJMSProvider</attribute>
    <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
    <attribute name="FactoryRef">/SomeConnectionFactory</attribute>
    <attribute name="QueueFactoryRef">/
SomeConnectionFactory</attribute>
    <attribute name="TopicFactoryRef">/
SomeConnectionFactory</attribute>
    <attribute name="Properties">
       java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
       java.naming.provider.url=t3://your_ip_for_node_a:7001
       java.naming.security.authentication=none

    </attribute>
</mbean>

<mbean code="org.jboss.jms.server.bridge.BridgeService" name="jboss.messaging:service=Bridge,name=IntegrationInputBridge" xmbean-dd="xmdesc/Bridge-xmbean.xml">
     <!-- The JMS provider loader that is used to lookup the source destination -->
     <depends optional-attribute-name="SourceProviderLoader">
        jboss.messaging:service=JMSProviderLoader,name=JMSProvider
     </depends>

     <!-- The JMS provider loader that is used to lookup the target destination -->
     <depends optional-attribute-name="TargetProviderLoader">
        jboss.messaging:service=JMSProviderLoader,name=RemoteJMSProvider
     </depends>

      <!-- The JNDI lookup for the source destination -->
      <attribute name="SourceDestinationLookup">/queue/IntegrationInputQueue</attribute>
      <attribute name="TargetDestinationLookup">/queue/IntegrationInputQueue</attribute>
      <!-- The username to use for the source connection
      <attribute name="SourceUsername"></attribute>        -->
      <!-- The password to use for the source connection
      <attribute name="SourcePassword"></attribute>        -->
      <!-- The username to use for the target connection  
      <attribute name="TargetUsername"></attribute>        -->
      <!-- The password to use for the target connection 
      <attribute name="TargetPassword"></attribute>        -->

      <!-- Optional: The Quality Of Service mode to use, one of:
           QOS_AT_MOST_ONCE = 0;  QOS_DUPLICATES_OK = 1;  QOS_ONCE_AND_ONLY_ONCE = 2; -->
      <attribute name="QualityOfServiceMode">0</attribute>

      <!-- JMS selector to use for consuming messages from the source
      <attribute name="Selector">specify jms selector here</attribute>      -->

      <!-- The maximum number of messages to consume from the source before sending to the target -->
      <attribute name="MaxBatchSize">1</attribute>

      <!-- The maximum time to wait (in ms) before sending a batch to the target even if MaxBatchSize is not exceeded. -1 means wait forever -->
      <attribute name="MaxBatchTime">-1</attribute>

      <!-- If consuming from a durable subscription this is the subscription name
      <attribute name="SubName"></attribute>      -->
      <!-- If consuming from a durable subscription this is the client ID to use
      <attribute name="ClientID"></attribute>      -->

      <!-- The number of ms to wait between connection retrues in the event connections to source or target fail -->
      <attribute name="FailureRetryInterval">5000</attribute>

      <!-- The maximum number of connection retries to make in case of failure, before giving up
           -1 means try forever-->
      <attribute name="MaxRetries">-1</attribute>

      <!-- If true then the message id of the message before bridging will be added as a header to the message so it is available
           to the receiver. Can then be sent as correlation id to correlate in a distributed request-response -->
      <attribute name="AddMessageIDInHeader">false</attribute>
</mbean>

<mbean code="org.jboss.jms.server.bridge.BridgeService" name="jboss.messaging:service=Bridge,name=IntegrationOutputBridge" xmbean-dd="xmdesc/Bridge-xmbean.xml">
     <!-- The JMS provider loader that is used to lookup the target destination -->
     <depends optional-attribute-name="TargetProviderLoader">
        jboss.messaging:service=JMSProviderLoader,name=JMSProvider
     </depends>
     <!-- The JMS provider loader that is used to lookup the source destination -->
     <depends optional-attribute-name="SourceProviderLoader">
        jboss.messaging:service=JMSProviderLoader,name=RemoteJMSProvider
     </depends>
      <!-- The JNDI lookup for the source destination -->
      <attribute name="SourceDestinationLookup">/queue/IntegrationOutputQueue</attribute>
      <attribute name="TargetDestinationLookup">/queue/IntegrationOutputQueue</attribute>
      <!-- The username to use for the source connection
      <attribute name="SourceUsername"></attribute>        -->
      <!-- The password to use for the source connection
      <attribute name="SourcePassword"></attribute>        -->
      <!-- The username to use for the target connection  
      <attribute name="TargetUsername"></attribute>        -->
      <!-- The password to use for the target connection 
      <attribute name="TargetPassword"></attribute>        -->
      <!-- Optional: The Quality Of Service mode to use, one of:
           QOS_AT_MOST_ONCE = 0;  QOS_DUPLICATES_OK = 1;  QOS_ONCE_AND_ONLY_ONCE = 2; -->
      <attribute name="QualityOfServiceMode">0</attribute>
      <!-- JMS selector to use for consuming messages from the source
      <attribute name="Selector">specify jms selector here</attribute>      -->
      <!-- The maximum number of messages to consume from the source before sending to the target -->
      <attribute name="MaxBatchSize">1</attribute>
      <!-- The maximum time to wait (in ms) before sending a batch to the target even if MaxBatchSize is not exceeded. -1 means wait forever -->
      <attribute name="MaxBatchTime">-1</attribute>
      <!-- If consuming from a durable subscription this is the subscription name
      <attribute name="SubName"></attribute>      -->
      <!-- If consuming from a durable subscription this is the client ID to use
      <attribute name="ClientID"></attribute>      -->
      <!-- The number of ms to wait between connection retrues in the event connections to source or target fail -->
      <attribute name="FailureRetryInterval">5000</attribute>
      <!-- The maximum number of connection retries to make in case of failure, before giving up
           -1 means try forever-->
      <attribute name="MaxRetries">-1</attribute>
      <!-- If true then the message id of the message before bridging will be added as a header to the message so it is available
           to the receiver. Can then be sent as correlation id to correlate in a distributed request-response -->
      <attribute name="AddMessageIDInHeader">false</attribute>
</mbean>

...
</connection-factories>


The first mbean block declares a RemoteJMSProvider which is the responsible for the remote connection with JMS container at the WLS.

The second mbean block declares a bridge that will send forward to WLS any message incoming into /queue/IntegrationInputQueue in the JBoss AS.

The third mbean block declares a bridge that will bring backward to JBoss AS any message incoming into /queue/IntegrationOutputQueue in the WLS.

Step 2: Create two queues at the WLS to replicate the other two at the JBoss AS.

/queue/IntegrationInputQueue
/queue/IntegrationOutputQueue

Step 3:  Copy the client jar to create connections from the WLS.

$JAVA_HOME/server/yourServerConfiguration/lib/wlfullclient.jar

Step 4: Of course, you need to enable the ports the servers need to traffic on, check your firewall.

Be advice, the serialization between slightly different java virtual machines may be a "real pain in the keyboard" sometimes. If a obscure RuntimeException is thrown when the serialization is being done, I suggest you to check the JVM's versions, otherwise you are playing with fire :-)
But, if you have a homogeneous production environment you probably won't have any problems.

Excuse my written english, enjoy!