5 Replies Latest reply on Mar 3, 2009 12:53 PM by jesper.pedersen

    [JBAS-5221] tx-connection-factory/no-tx-connection-factory n

    jesper.pedersen
    jesper.pedersen Feb 23, 2009 2:29 PM

      Scott, I have begun to look at this task.

      Can you specify a bit more what you are looking for ? Is it the setManagedConnectionFactoryProperties method you are looking for ?

      Also is the code currently using the correct API ?

      • 2033 Views
      • Tags:
        • 1. Re: [JBAS-5221] tx-connection-factory/no-tx-connection-facto
          emuckenhuber
          emuckenhuber Feb 24, 2009 5:47 AM (in response to jesper.pedersen)

          I was wondering about this property too, as this seems a bit confusing. Because which of the following is the correct property to edit:

          managedObject.getProperty("driver-class");
// or:
managedObject.getProperty("config-property").get("DriverClass");


          From a attachment persistence standpoint we could also get some issues with this:
          e.g. if setManagedConnectionFactoryProperties is writing the changes back to the attachment. And you just update "driver-class", without refreshing the MO (and therefore "config-property") - it could persist two different values for "driver-class" (should be the same problem if you do it the other way around).


            • Actions
          • 2. Re: [JBAS-5221] tx-connection-factory/no-tx-connection-facto
            starksm64
            starksm64 Feb 27, 2009 12:47 PM (in response to jesper.pedersen)

            This looks out of date at this point as the config-property is common across all of the jca deployment types and handled by the custom ConnectionFactoryProperty. I don't see any related failures in the profile service tests.

            As Emanuel notes, there are some issues with essentially duplicate properties with different names when config-property is an alias for specifying another metadata property. Ideally the config-property would have those specified in a consistent manner as a MapCompositeType, and would incorporate cf specific property descriptions from the rar metadata, but that is another issue.

              • Actions
            • 3. Re: [JBAS-5221] tx-connection-factory/no-tx-connection-facto
              jesper.pedersen
              jesper.pedersen Mar 2, 2009 1:42 PM (in response to jesper.pedersen)

              After having looked at this - I think that the best solution would to be refactor the layer such that the management view ends up with a view that represents the deployment (-ds.xml).

              This would mean that the 'config-property' entry will only be available for tx-connection-factory and no-tx-connection-factory deployments.

              That way we don't have two ways of doing the same thing - like Emanuel's post shows.

              Lets focus on getting the management view for datasource deployments correct for 5.1.0.Beta1 as they will cover most deployment. If time permit we can look into incorporating specific property descriptions.

              We can pick up the remaining areas for the 5.1.0.CR1 release.

                • Actions
              • 4. Re: [JBAS-5221] tx-connection-factory/no-tx-connection-facto
                starksm64
                starksm64 Mar 2, 2009 2:06 PM (in response to jesper.pedersen)

                Sounds good

                  • Actions
                • 5. Re: [JBAS-5221] tx-connection-factory/no-tx-connection-facto
                  jesper.pedersen
                  jesper.pedersen Mar 3, 2009 12:53 PM (in response to jesper.pedersen)

                  The feature is tired in with the deployer, so that layer also have to be changed if the clean up is going to happen.

                  Something for the 6.0 - making sure that things are kept separate.

                    • Actions