Hi,
for connections to the DB use the global configuration file /conf/context.xml of tomcat . I run the export module by selecting "Exclude from the JDB Resurce context file" ( the reason is a bit 'long to be explained..in a nutshell the problem is that for every module you create a new connection pool and not what I want). It works very well...but now I need to encrypt the DB password. If I export a module without deleting the local context, I already have the plug and play functionality ( password are already encrypted ) but I have to keep the current architecture (global context) .. How can I do?

The encrypted password is actually in the web.xml. OD will get it from there. I am a little confused with your request. Are you thinking of putting the use and password in the global context?

Yes..I need to use an encrypted password in the global context.. Is it is possible ??

I'm currently using the settings in the global context because when I export the war module I select "Exclude from the JDB Resurce context file". This way works very well and allows me to have several modules that call a series of stored procedures in the same DB. Each module, however, does not create its own connection pool but always use the same set globally

You can get the password encrypted by using our tool in the Eclipse Preferences->Avaya Aura->Orchestration Designer->Password Encryption. But this is only necessary when you change the password manually in the web.xml of the application. If you put this password somewhere else, OD does not use it.

If the same user and password is being used, you shouldn't need to change the password which is stored in the web.xml of every module and application.

Yes .. I had already seen that utility ... But my need would be right to allow OD to use the encrypted password from the global contextx reading it though. If this is not possible directly with the OD feature, you can suggest me how to do it without making major changes to the modules that have been developed?? (I'm almost 50 interfaces ...) ...

I would need a case like this:
OD using the username and password that are present in the local web.xml (then using the encrypted password), but not finding the local context.xml, solves the JNDI connection string in the global context.xml which are not specified user and password! :)

If you configure the global context correctly, OD should be able find the datasource using JNDI. Can you tell what is not working currently?

This is roughly what we are doing:

Context envContext = (Context)initContext.lookup("java:comp/env");
Datasource dataSource = (DataSource)envContext.lookup("jdbc/mydatasource");
dataSource.getConnection(username, password);


username and password are retrieved from the web.xml at the time when the dbop is being executed.

Using the global configuration (/ conf / context.xml) and exporting the module with the option "Exclude from the context Resurce JDB file" enabled (after you have set up, however, all it takes to create the local JNDI resources), OD works perfectly ! Only by doing so, even if you create the encrypted password in the local file web.xml , OD uses the settings it finds in the global context where the password is not encrypted. I was wondering if you could do a mix of the two features. make sure that the password can be read and deciphered by the local web.xml but the local JNDI resource is then created using strings of connections in the global context. All this because I need to have a single pool CONNECTION even if I use many modules that call a lot of stored procedures ( these stored procedure running on the same DB but they are called from different OD reusable module )

sorry for my bad English, but I hope you understand what is my problem :wink:

I do understand you are trying to share the same connection pool among application and modules. Are you saying you have to specify the username and password in the global context otherwise it wouldn't work?

Honestly, I never thought not to put username and password in the global context .... Tomorrow I try and let you know if everything is OK.
1000 Thanks for the suggestion :D

Hi,
I did some tests and it seems to work :)

I have changed the the global context.txt format from

<Resource name="jdbc/db_ctisvi_ulluser" auth="Container"
type="javax.sql.DataSource" driverClassName="oracle.jdbc.OracleDriver"
url="jdbc:oracle:thin:@rmgens02:1521:ctisvil"
username="ulluser" password="ulluser"
maxActive="4" maxIdle="2" minIdle="1" maxWait="2000" removeAbandoned="true" logAbandoned="true"
removeAbandonedTimeout="300" testOnBorrow="false" validationQuery="select 1 from dual"/>

to....( using the same context content created by OD )

<Resource url="jdbc:oracle:thin:@rmgens02:1521:ctisvil"
type="org.apache.tomcat.dbcp.dbcp.cpdsadapter.DriverAdapterCPDS"
name="jdbc/db_ctisvi_ulluserCPDS"
factory="org.apache.tomcat.dbcp.dbcp.cpdsadapter.DriverAdapterCPDS"
driver="oracle.jdbc.driver.OracleDriver"
auth="Container"/>

<Resource type="org.apache.tomcat.dbcp.dbcp.datasources.PerUserPoolDataSource"
name="jdbc/db_ctisvi_ulluser" factory="org.apache.tomcat.dbcp.dbcp.datasources.PerUserPoolDataSourceFactory"
auth="Container" validationQuery="select 1 from dual"
testOnBorrow="false"
removeAbandonedTimeout="300"
removeAbandoned="true"
logAbandoned="true"
defaultMaxWait="2000"
defaultMaxIdle="1"
defaultMaxActive="5"
dataSourceName="java:/comp/env/jdbc/db_ctisvi_ulluserCPDS"/>

Now the connection works using the encryped password in local web.xml :D ...but there are some differents from some labels ...defaultMaxWait-->maxWait, ecc ) and I would be sure that the management of the pool is not affected
Can I be sure that the management of connections in the pool remains unchanged compared to the first version?
This aspect is very important because, before using the connections of the pool, our client has imposed long periods of testing ...
Best Regards