WLST Session

This provides a ruby interface to WLST. It is usually connected to a Domain object from MintPress::OracleWeblogic

Simple Usage

The following will get a wlst session object from a weblogic domain:

wlst = domain.wlst_session

At this point, the WLST object proxies any objects on the other end. So whereas with jython you might have:

foo = cmo.getName()

In ruby this would be:

foo = wlst.cmo.getName()

One important thing to note is that ruby syntax is always used - so if you have the jython example of:

foo = something(named_parameter = "foo")

in ruby, this MUST be:

foo = wlst.something(named_parameter: "foo")

Arrays and hashes are automtaically translated, and can be iterated as ruby, however jarrays are not - you need to use to_a to convert these to ruby arrays.

# This works and is code we use in product:
allJDBCResources = wlst.cmo.getJDBCSystemResources()
allJDBCResources.each do |datasource|
  # This is ruby, so you can omit () if you wish
  puts datasource.getName
end

# However:

This returns a proxied java object, which we don’t detect is array, but we know it!

jmsSystemResources = wlst.ls(‘/JMSSystemResource’, returnMap: ‘true’).to_a jmsSystemResources.each do |jms_resource| puts jms_resource.getName end




Credential Masking
------------------
WLSTSession will transparently accept Mint::Secret objects, and they should be used wheneer a credential is passed.  This ensures that the output is masked.  For example:

wlst.set(‘Password’, ‘Credential’) # This will log the credential wlst.set(‘Password’, Mint::Secret.new(‘Credential’) # This will replace the credential with ****** in logs.


Creating your own sesion object
-------------------------------
Sometimes you don't want ot be on the admin server - to deal with this, you need to create the object manually by running code like:

MintPress::Utils::WLSTSession.session(host.transport, fmw_home)


Setting credentials
-------------------
If you don't want to use a domain object, but wish to use high level functions, you need to provide credentials to the system - that is done using the `set_domain_creds` function like so:

MintPress::Utils::WLSTSession.set_domain_creds(domain_name: domain_name, domain_home: domain_home, username: domain.admin_username, password: domain.admin_password.value, admin_server_address: domain.admin_server.listen_address, admin_server_port: domain.admin_server.listen_port, admin_server_port_ssl: domain.admin_server.ssl.listen_port)


This is not generally required - the cases where you'd usually use this, you'd also be using a domain obejct, and could use wlst_session (which does this for you).  However, if you do hit such a corner case, this is an available and supported API

Connecting to domains
---------------------

wlst.connect_any # This connects via online if available, and offline if not puts “online!” if wlst.online? puts “offline!” if wlst.offline_domain?

wlst.connect_online # Conect online only

wlst.connect_offline # connect offline only


State
-----

The backend functions generally know about both offline and online, the idea being that you can have one set of code that works in both states.

wlst.start_edit # ensure we’re in an edit session - if you’re offline, this does nothing wlst.save_domain # In online, this does activate(). In offline, this does saveDomain().


Connecting to other things
--------------------------
WLST Session supports a high level node manager API connection:

wlst.connect_nm(hostname: “test1.mintpress.io”, password: secret, domain_name: ‘test_domain’)

“‘

This is often used for server start/stop actions and deployment actions.

Environment Varaibles

  • MINTPRESS_EXCLUSIVE_WLST - This will cause start_edit() to wait until an edit session is availale. Note this can wait forever if your domain never unlocks!