[smarlow]

I would consider re-engineering the codebase from MBEAN based to MC, to be out of  scope for AS 5.x.  As that could destabilize the code base and impact existing deployments in a negative way.  The idea of minimizing risk when applying code changes to released versions of a product/project is an old idea that still makes sense (IMHO).

At the moment, we are still figuring out the larger challenge of integrating as strongly as possible, with the xa recovery mechanism.  Well, Jesper has a design in place but we are trying to apply that to the existing code still and it is challenging (there are a lot of moving parts to deal with).  If we didn't have enough challenges already, we could probably figure out a way to re-engineer (safely) from a MBEAN approach to MC.

Perhaps we should have this discussion on the phone if there is still disagreement.  If all involved are willing to speak in person, that would be fine with me too.  Might not be a bad idea to have a few phone meetings to discuss how things are going anyway (if you guys want that :-).

[jesper.pedersen]

After some digging around I managed to get the TransactionManagerService into the JMX component using the system-jmx module in AS.

So no need to extend the current TMS MBean interface with the recovery methods.

Jonathan, I'll keep you in the loop on my progress.

[jesper.pedersen]

Anil, I'm currently looking into the best way to hook up a username/password pair to the component to get a Subject.

Basically I have added recover-user-name and recover-password elements to the xa-datasource definition to allow users to specify a special user name and password for the recovery if that is needed. Default is fallback to the standard user-name and password pair.

Also included is a recover-security-domain, just like the security-domain - and same concept as above.

I have injected the

org.jboss.security.SubjectFactory

instance into the component (org.jboss.resource.connectionmanager.ManagedConnectionFactoryDeployment).

So I'm looking for the simplest solution for the following method:

private Subject getSubject()

At the moment I have:

private Subject getSubject()
{
   if (subjectFactory != null && recoverSecurityDomain != null)
   {
      return subjectFactory.createSubject(recoverSecurityDomain);
   }

   return null;
}

to cover for the recover-security-domain case.

I would like to keep this change inside the component in order to make the minimal changes possible to other components that doesn't need to know about this feature.

[anil.saldhana]

Once you have the SubjectFactory installed and you know what the username/cred combo, is,  what needs to be done before you do getSubject() is the following:

AccessController.doPrivileged( new PrivilegedAction()
{
  public Object run()
  {
     //Create a security context on the association
     SecurityContext securityContext = SecurityContextFactory.createSecurityContext(securityDomainName);
     SecurityContextAssociation.setSecurityContext(securityContext);

     //Now let us add the user name and cred
     securityContext.getSubjectInfo().setPrincipal( principal );
     securityContext.getSubjectInfo().setCredential( credential );

};

The implementation of SubjectFactory basically looks for the username/cred in the current security context on the SecurityContextAssociation.

Corrections:

(12:34:06 PM) jpederse: asaldhan: I'll follow up - the question is about how to get the securityDomainName, principal and credential
(12:34:42 PM) asaldhan: jpederse: good point. I think it may be in the login modules. let me look 
(12:36:24 PM) asaldhan: jpederse: actually, u r supposed to figure out the security domain name. that is it.
(12:36:54 PM) asaldhan: jpederse: then in the security domain, you configure the org.jboss.resource.security.SecureIdentityLoginModule

The javadoc for the SecureIdentityLM is:

<application-policy name = "HsqlDbRealm">
   <authentication>
      <login-module code = "org.jboss.resource.security.SecureIdentityLoginMdule"
         flag = "required">
         <module-option name = "userName">sa</module-option>
         <module-option name = "password">-207a6df87216de44</module-option>
         <module-option name = "managedConnectionFactoryName">jboss.jca:servce=LocalTxCM,name=DefaultDS</module-option>
      </login-module>
   </authentication>
</application-policy>

 This uses a hard-coded cipher algo of Blowfish, and key derived from the
 phrase 'jaas is the way'. Adjust to your requirements.

[jesper.pedersen]

The question is how to best get the securityDomainName, principal and credential variables from within ManagedConnectionFactoryDeployment setup in the correct way in the two use-cases

1. username / password
2. security-domain

specified in the -ds.xml file.

[anil.saldhana]

The ds xml file needs to have the following two:

• Username/Cred
• Security Domain Name

Typically the security domain underneath has one of the many JCA login modules.  Primarily the SecureIdentityLoginModule is used which is configured with a username/cred.  So basically, the username/cred configured in the SILM is added to the subject that is popped into the ManagedConnectionFactory (that JCA uses to deal with EIS).

So why do we need username/cred in the ds.xml,  it is for cases when you want to use your own homegrown login module (that is not part of the JBoss JCA login modules).

[jesper.pedersen]

Here is an use-case:

<datasources>
  <xa-datasource>
    <jndi-name>PostgresDS</jndi-name>
    <track-connection-by-tx>true</track-connection-by-tx> 
    <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    <xa-datasource-property name="ServerName">server_name</xa-datasource-property>
    <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">database_name</xa-datasource-property>
    <xa-datasource-property name="User">user</xa-datasource-property>
    <xa-datasource-property name="Password">password</xa-datasource-property>

    <metadata>
       <type-mapping>PostgreSQL 8.0</type-mapping>
    </metadata>

  </xa-datasource>
</datasources>

There isn't a security-domain defined here.

[jesper.pedersen]

[14:07] <jpederse> asaldhan: so can I pass a null string as securityDomainName to createSecurityContext ?
[14:07] <asaldhan> jpederse: pass any dummy
[14:08] <jpederse> asaldhan: k, but I''m not seeing any setPrincipal() / setCredential() on SubjectInfo
[14:09] <asaldhan> jpederse: did u set it on SecurityContextAssociation?
[14:10] <jpederse> asaldhan: how ? It only takes the SecurityContext
[14:11] <jpederse> asaldhan: also; do I need the SecurityContextAssociation part at all ? I just need the Subject as a local variable
[14:11] <jpederse> asaldhan: this is not run in a context of something
[14:12] <jpederse> asaldhan: Its "ManagedConnection mc = mcf.createManagedConnection(subject, null)"
[14:14] <asaldhan> jpederse: but the creation of subject has to go through authentication.  So at that time, the subjectfactory will look at the SCA for the latest SC and picks username/cred from there. After you have the subject, u then pass it to MCF
[14:14] <asaldhan> jpederse: so u need to do the SCA/SC/princ/cred
[14:15] <jpederse> asaldhan: k, then I just need to find the place where I input my username and password strings
[14:16] <jpederse> asaldhan: as the securityDomainName is null
[14:16] <asaldhan> jpederse: I have told u the sequence, I think u will have to figure out where to do the necessary things.  The SDN should not be null. U r probably doing it wrong someplace
[14:17] <jpederse> asaldhan: look at my latest post - there isn't a security-domain configured in the -ds.xml
[14:17] <asaldhan> jpederse: there are two pieces:  security to check whether u can create a subject. Once u have a subject, u pass it to the MCF.  The MCF deals with the EIS.
[14:17] <jpederse> asaldhan: that is the common case for AS
[14:18] <asaldhan> jpederse: in that case, it probably just defaults to "other"
[14:18] <jpederse> asaldhan: yes, and I need the create the Subject - based on the information from the two use-cases
[14:18] <jpederse> asaldhan: I'm not talking about application-policy's
[14:18] <asaldhan> jpederse: if u have the AS setup, try debugging and seeing what the SD is for the case when -ds.xml does not have SD.
[14:18] <asaldhan> jpederse: the security domain translates to app policy
[14:19] <asaldhan> jpederse: SD = app policy defs
[14:19] <jpederse> asaldhan: yeah, I know - so it is probably the "other" case
[14:19] <asaldhan> jpederse: best is to debug the classic ds.xml usecases.[14:20] <jpederse> asaldhan: yeah, that would be the next thing
[14:21] <jpederse> asaldhan: and what about the principal / credential case ? I need to plug them in where ?
[14:22] <asaldhan> jpederse: dont know how the current ds setup does it.

[jhalliday]

>  [e-mail]:jesperpedersen/eap.git


That seems to be an eap copy with no updates. Where can I get the current code? Thanks.

[jesper.pedersen]

Commit 104307 and 104379 on JBPAPP_5_1 contains the feature.

[jhalliday]

Thanks Jesper. I took a quick look at those changesets and I have two points:

I may be misunderstandin ghte model, but it seems that ManagedConnectionFactoryDeployment.getXAResources() creates a new connection on each call, which is good in that if the db crashes and recovers whilst the app servers stays up, the system will effectively reconnect rather than continuing to use a stale connection. However, as far as I can tell, it's never disposing those connections. Since the recovery system will make one pass every two minutes by default, it's going to leak pretty badly.  The integration SPI does not allow for explicit disposal, so the best bet is probably to keep a handle on the last connection used and on each call to getXAResources either validate it (i.e. ping the db to make sure it's still there) and reuse it, or explicitly release it and get a new one.

The XAResourceWrapperImpl usage appears to be applied only to XAResources used for recovery, not he ones used during normal transaction usage. It would be helpful to have the same wrapping applied to the XAResource handed out to the transaction manager during normal operation, as that would allow correlation in the logs between the tx run and the recovery. I'm guessing that's a fairly minor cutnpaste type fix - any chance of squeezing it in?

Thanks

Jonathan

[jesper.pedersen]

I may be misunderstandin ghte model, but it seems that ManagedConnectionFactoryDeployment.getXAResources() creates a new connection on each call, which is good in that if the db crashes and recovers whilst the app servers stays up, the system will effectively reconnect rather than continuing to use a stale connection. However, as far as I can tell, it's never disposing those connections. Since the recovery system will make one pass every two minutes by default, it's going to leak pretty badly.  The integration SPI does not allow for explicit disposal, so the best bet is probably to keep a handle on the last connection used and on each call to getXAResources either validate it (i.e. ping the db to make sure it's still there) and reuse it, or explicitly release it and get a new one.

Fixed. Thanks.

As to the explicit close case - I need to know when recovery have been done in order to cleanup and destroy the managed connection, and the JCA API doesn't have an SPI for that (yet). Maybe we could add recoveryBegin() and recoveryEnded() to our interface ?

As to the validate case - I'll think about what we can do to best handle this case and commit something, if we aren't going with the idea above.

The XAResourceWrapperImpl usage appears to be applied only to XAResources used for recovery, not he ones used during normal transaction usage. It would be helpful to have the same wrapping applied to the XAResource handed out to the transaction manager during normal operation, as that would allow correlation in the logs between the tx run and the recovery. I'm guessing that's a fairly minor cutnpaste type fix - any chance of squeezing it in?

Normal transaction usage is handled in the TxConnectionManager class, where the interface is used (if enabled). So we should be good in that case

There is room for a lot of improvements both in the JCA spec and the JCA container to make life easier for our users - I'll keep this in mind for the new implementation.

[jesper.pedersen]

A couple of additonal commits.

• 104797: Remove support for "RecoverUser" and "RecoverPassword". Split the <security-domain> into two sub use-cases
• 104799: Try to reconnect if mc.getXAResource() fails
• 104802: Covered the unauthenticated security domain use-case