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.

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
   
   

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 Name > select target JMS server > Finish

Create JMS Queue and ConnectionFactory

	Name	Type	JNDI Name	Subdeployment	Targets
	MyConnectionFactory	Connection Factory	jms/QCF	Default Targetting	myserver
	MyTestQueue	Queue	jms/TestQ	MyTestQueueSubDeploy	MyJMSServer

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:

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