Wednesday, April 29, 2015

config JBossAS 7.1 to use customized truststore

From JBoss AS 7.1, my ejb service needs to send out email to exchange server via Microsoft EWS Java API.

EWS Java API maven dependency as
<dependency>
 <groupId>com.microsoft.ews-java-api</groupId>
 <artifactId>ews-java-api</artifactId>
 <version>2.0-SNAPSHOT</version>
</dependency>

Our exchange server endpoint is exposed via https, whose certificate is self-signed by company's root CA (the root ca is also self-signed).

At runtime, when the EJB trying to connect to exchange server (via https), since JBoss doesn't trust company's root ca, we got error as


...
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
 at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:196) [rt.jar:1.7.0_75]
 at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:268) [rt.jar:1.7.0_75]
 at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:380) [rt.jar:1.7.0_75]
 ... 171 more

To fix this, I need to config JBoss to trust company's root ca, so that also trust the https certificate the root ca signed. Since my dev JBoss has no truststore configured yet, I add following system properties to server's standalone-full.xml file in C:\DEVEL\APPS\jboss-as-7.1.3.Final\standalone\configuration. The updated  standalone-full.xml as


        <extension module="org.jboss.as.webservices"/>
        <extension module="org.jboss.as.weld"/>
    </extensions>

    <system-properties>
        <property name="javax.net.ssl.trustStore" value="c:\\Users\\jwang.tek\\.keystore "/>
        <property name="javax.net.ssl.trustStorePassword" value="dev1234"/>
    </system-properties>


    <management>
        <security-realms>

Note: the system-properties needs to be right after extension tag.

Restart JBoss AS server, connect via cli, I can see the added system properties as


C:\DEVEL\APPS\jboss-as-7.1.3.Final\bin>jboss-cli.bat --connect
[standalone@localhost:9999 /] /system-property=foo:read-resource
{
    "outcome" => "failed",
    "failure-description" => "JBAS014807: Management resource '[(\"system-property\" => \"foo\")]' not found",
    "rolled-back" => true
}
[standalone@localhost:9999 /] /system-property=javax.net.ssl.trustStore:read-resource
{
    "outcome" => "success",
    "result" => {"value" => "c:\\\\Users\\\\jwang.tek\\\\.keystore "}
}
[standalone@localhost:9999 /]

Done. JBoss started fine, hit EJB service and sending email to exchange server works fine.


Use jboss pre-deployed module in maven ejb project


Use jboss pre-deployed module in maven ejb project

Goal

From my EJB maven project, I want to use commons-io and org.jgroups libraries,  both of the jars have already been pre-deployed as modules in JBossAS 7.1.3 runtime.
 I use these jars as provided dependency to avoid packing redundant jars inside ejb project as lib jars.

JBoss AS 7.1.3 already has commons-io and org.jgroups deployed as module

...\jboss-as-7.1.3.Final\modules\org\apache\commons\io\main
commons-io-2.1.jar
...\jboss-as-7.1.3.Final\modules\org\jgroups\main
jgroups-3.0.14.Final.jar

Steps

in ejb project pom.xml, add
// add commons-io and org.jgroups dependency with provided scope (so the jar won't be deployed alone with project archive as lib jars). This also makes the Eclipse IDE happy
...

<dependency>
 <groupId>commons-io</groupId>
 <artifactId>commons-io</artifactId>
 <version>2.1</version>
 <scope>provided</scope>
</dependency>

<dependency>
 <groupId>org.jgroups</groupId>
 <artifactId>jgroups</artifactId>
 <version>3.0.14.Final</version>
 <scope>provided</scope>
</dependency>
...
// once packaged, the ejb jar won't have  commons-io and org.jgroups in its lib directory. For server deployment, we then need to config project packaging plugin to add dependency to manifestEntries in ejb's MANIFEST.MF to use commons-io and org.jgroups as jboss pre-deployed module. Update ejb maven plugin to add dependency to manifestEntries as below
...

<plugin>
 <artifactId>maven-ejb-plugin</artifactId>
 <version>${version.ejb.plugin}</version>
 <configuration>
  <!-- Tell Maven we are using EJB 3.1 -->
  <ejbVersion>3.1</ejbVersion>
  <archive>
     <manifestEntries>
     <Dependencies>org.apache.commons.io, org.jgroups</Dependencies>
     </manifestEntries>  
  </archive>                    
 </configuration>
</plugin>
...

The generated MANIFEST.MF will have line as

Dependencies: org.apache.commons.io, org.jgroups

done. build project and deploy to JBoss.

Monday, April 13, 2015

Self-signed Certificate & Java Security Warning & Browser

dev setup:


  • html page XYZ hosting Java Applet ABC
  • Java Applet ABC signed by mykey
  • mykey - self-issued pivate key

security warning - untrusted applet signer


When loading html page, we got security warning as below:

Reason:  The applet is signed using self-issued key (for dev only)


To resolve:
Export signer pubkey certificate (its private key is used to sign applet ABC)
C:\> keytool -export -keystore c:\Users\*****\.keystore -alias mykey -file C:\Users\*****\workspace\POC\jwangdev.cer.p12
Enter keystore password: dev1234

Import singer certificate into “Signer CA” via Java Control Panel.
Java Control Panel -> Security -> Manage Cerficates… -> choose “Signer CA” -> import C:\Users\*****\workspace\POC\jwangdev.cer.p12


restart browser. done.

applet security warning - untrusted https certificate issuer

reason:
From the signed applet ABC, we have https connection to https://localhost:8443 (a dev jboss server with default self-signed https certificate for "localhost"). When applet tries to make such https connection, we have security warning window as below: 

To suppress the above warning window:

Add “C:\Users\*****\workspace\POC\ dev_jboss_cert.cer.p12” certificate to “Secure Site” via Java Control Panel. 

restart browser. done.

Wednesday, September 10, 2014

weblogic integrating remote ejb via foreign jndi provider

Server Env Overview

weblogic 12c (12.1.1), with domain setup as
  • AdminServer - domain admin 
  • CoreServer - host core business service EJBs
  • AppServer - host application specific EJBs which uses core business service EJBs

Foreign JNDI Provider Setup

login to admin console -> domain -> Services -> Foreign JNDI Providers, create new Foreign JNDI Provider

where Provider URL is pointing to CoreServer and Targets points to AppServer.

Add Foreign JNDI Links as

where Local JNDI Name is the global JNDI name used in EJBs from AppServer and Remote JNDI Name is the global JNDI name for remote EJBs deployed in CoreServer.


Inject Remote EJBs via @EJB annotation

To use remote ejbs from JavaEE components from AppServer (say EJBs), simply add EJB ref as

@EJB(mappedName="<the_local_JNDI_name_as_defined_in_Foreign_JNDI_Links>") 
AssignmentEjb tmpEjb;

where mappedName is the global JNDI name as defined in local JNDI name in Foreign JNDI Links in Weblogic Admin console.

Tuesday, September 9, 2014

eclipse remote debugging app in managed weblogic server

Dev Env Overview

  • Eclipse JUNO + OEPE bundle
  • WLS 12c (12.1.1) in remote Linux
    • domain setup: admin server, core server, front server, app server
Launch managed WLS server in development mode with debug on
  1. cd $WLS_DOMAIN/bin
  2. start Admin server: startWebLogic.sh << WLS Start Mode=Development
  3. start managed CoreServer0: startManagedWebLogic.sh CoreServer0
  4. start managed FrontServer: startManagedWebLogic.sh FrontServer
  5. start managed AppServer in dev mode with debug on
debugFlag=true DEBUG_PORT=29898 startManagedWebLogic.sh MyAppServer t3://<my-app-server-host>:<my-app-server-port> noderby


Eclipse Setup
  1. download/install Eclipse JUNO + OEPE bundle from Oracle website
  2. configure proxy
  3. install m2e plugin for Juno "M2E - Maven Integration for Eclipse" from Eclipse Marketplace
  4. in Java EE perspective, in Servers tab, create a new server pointing to remote Linux server
    22426: my wls domain admin port; 29898: my appserver debugging port
  5. update advanced publishing config of the newly added server (change designed target server)
  6. (checkpoint) now Eclipse is talking to remote server
  7. add Java EE project to new server
Publish Dev Change to Remote Server
  1. make dev changes
  2. when you're ready, click the publish icon () to publish to remote server to testing 
Debugging App on Remote Server
  1. (checkpoint) make sure remote Server is running with debug On
  2. from Eclipse -> Java EE Perspective -> Servers view, click debug icon () to enter debug mode
  3. set breakpoint in IDE
  4. hit the server; Eclipse will bring up debug perspective when breakpoint is reached

Friday, June 27, 2014

WLS 12c to JBOSS 7.1.1.Final JMS Bridging Setup

Configuration


  • WLS 12c (WLS Queue, WLS JMS Bridge)
  • JBoss 7.1.1.Final (JBOSS Queue)


Steps on JBOSS AS 7.1.1.Final

Create JMS Queue on JBOSS

Edit standalone-full.xml, add queue configuration as
<hornetq-server>
<jms-destinations>
<jms-queue name="VSSQueue">
<entry name="queue/VSS"/>
<entry name="java:jboss/exported/jms/queue/VSS"/>
</jms-queue>
</jms-destinations>
</hornetq-server>

Start JBOSS With Fully Qualified Domain Name (FQDN)

Starting with FQDN allows the connection of WLS bridge originated from yet another host

$ cd $JBOSS_HOME
$ export JAVA_OPTS="$JAVA_OPTS -Djboss.bind.address=jboss_host.company.com"
$ export JAVA_OPTS="$JAVA_OPTS -Djboss.bind.address.management=
jboss_host.company.com"
$ bin/standalone.sh -c standalone-full.xml




Steps on WLS 12c

Copy JBOSS JMS libs to <WLS_DOMAIN>/lib

To make WLS talk to JBOSS via JMS, we need to add

  • hornetq-jms-client.jar (from hornetq-2.2.14.Final/lib) and 
  • jboss-client.jar  (from $JBOSS_HOME/bin/client

to <WLS_DOMAIN>/lib (Note: JBOSS AS7.1.1.Final uses hornetq-2.2.13, but works with 2.2.14)

Deploy resource adapters jms-notran-adp/jms-xa-adp to WLS

To use JMS bridging, we need to deploy jms-notran-adp/jms-xa-adp to WLS as
    1. Click Deployments (LHS) > Lock & Edit > click install (RHS) > select /<USER>/Development/Env/wls1211_dev/wlserver/server/lib/jms-xa-adp.rar > choose Install this deployment as an application > select desired target server -> Finish
    2. Click Deployments (LHS) > check jms-xa-adp > click Start Serving all requests > State should be "Active" 

Create JMS System Module

Login to WLS console > (LHS) Services > Messaging > JMS Modules > (RHS) new JMS Modules (System)  > select target server -> Finish

Create JMS Server

in WLS console, (LHS) Services > Messaging > JMS Servers > (RHS) click New > enter Name > create and select persistent store > select target server > Finish

Create Subdeployment

in WLS console,  (LHS) Services > Messaging > JMS Modules > (RHS) select JMS module we just created > click Subdeployments tab > click New > enter Subdeployment Nameselect target JMS server > Finish

Create JMS Queue and ConnectionFactory

Name Sorted Ascending Type JNDI Name Subdeployment Targets 
MyConnectionFactoryConnection Factoryjms/QCFDefault Targettingmyserver
MyTestQueueQueuejms/TestQMyTestQueueSubDeployMyJMSServer

create/select subdeployment and target server

Create JMS Bridge

    create source destination: queue@WLS
    create target destination: queue@JBOSS
    create JMS bridge


    Restart WLS 

        Ref:

        Friday, June 13, 2014

        GIT Submodules Recipes

        In Git, parent project is associated with submodule project at git-commit level, NOT at git-branch level.

        ParentProj at GIT-repo-Parent
        ChildProj at GIT-repo-Child

        Person GitAdmin setup git repo

        • parentRepo
        • childRepo

        PersonA clone and add submodule

        • personA clone parentProj 
        • personA clone childProj
        • personA add childProj  to parentProj as submodule
        • personA commit submodule change (at commit 100)
        • personA push up changes 
        PersonB use parentProj


        • personB clone parentProj (including childProj)
        • personB init, update submodule childProj (now childProj is at detached commit 100) 
        PersonA upgrades submodule
        • personA update childProj in master
        • personA commit changes in childProj in master (at commit 120)
        • personA push up childProj changes to origin/master
        PersonA update parent to use childProj's newest commits
        • personA add/commit childProj changes in parentProj (uses new childProj commit 120)
        • personA push up parentProj  
        PersonB updates parentProj to pick up changes
        • PersonB pull parentProj changes (will see parentProj points to a newer ChildProj commit 120)
        • PersonB update submodule (this will sync ChildProj to the commit 120) notes: will lost local uncommitted changes in ChildProj