1 2 Previous Next 17 Replies Latest reply on Jul 12, 2006 1:15 AM by weston.price

    JBAS-3343

    weston.price

      This is a tricky one for a few reasons.

      The spec states that the ResourceAdapter should be initialized first, it's properties applied and retained. When the ManagedConnectionFactory is initialized it's properties should be set BUT if a property value is not provided, and it also exists in the ResourceAdapter, the RA property should be applied. The properties used at runtime are a union of the RA and MCF.

      We definitely don't do the first one, hence the JIRA task, but we also don't allow for the second condition at all. Typical case would be an RA with the following properties:

      RA
      ServerName = "localhost"
      Port = "8080"


      MCF
      ServerName = ""
      Port = ""

      (Yes, yes, stupid example I know)


      The spec seems to suggest that the RA values would be applied here in lieu of the MCF providing these values in the descriptor. Otherwise, what would be the point of applying the values from the RA at all? Of course, if any of these were set via *-ds.xml, they would override what has already been applied. After checking *both* the RA and the MCF for the existence of the property.


      While we don't recommend modifying the contents of the ra.xml that come with our adapters, clients could most certainly do this. Further the
      managed connection factory properties element constructed via XSLT will have to check both the RA and the MCF being that the property could live in both/either place.

      Unless I am complicating this scenario, it appears to be a hole that is at presently unaccounted for.

      The ConfigPropertyMetaData collections that live off the ConnectorMetaData and ConnectionDefinitionMetaData can actually help. Being that we have both collections at the time of the deployment, I can look for a disjoint between the two. This is of course after implementing equals(), hashCode(). If there are no elements in common then all is well. If there are elements in common, it's a matter of going back to the RA checking if the property was provided, etc, etc.


      The strangest edge case would be the following:

      RA
      FirstProp = ""

      MCF
      FirstProp = ""

      *-ds.xml contains the config-property FirstProp with the appropriate name and type. Now...here is the rub...which one gets set? The RA or the MCF? The spec says that the MCF should take precedence in the case of intersecting names (which is really the only case that matters) but in this scenario, coupled with our deployment, it is not all that clear.


      Some of this stuff needed to be cleaned up a bit anyway, so I guess it's a good thing.

      Sorry for the long post.







        • 1. Re: JBAS-3343
          weston.price

          And for some reason...as if literally on cue...we get 2 questions about this in the user forum, and the JIRA task itself...

          One thing we could do is add a new element to the *-ds.xml file specifically naming RA level properties. Something like:

          <ra-config-property>

          Or, add a 'scope' attribute to the existing element. I am inclined to the former just because it is more clear.

          • 2. Re: JBAS-3343
            weston.price

            One more time...;-)

            This is where the MBean repository, or exposure of the ResourceAdapter itself would help. Right now, the only way 'in' to the adapter is via the ManagedConnectionFactory MBean which is starting to sort of look like Swiss cheese. This is in large part due to the fact that there is no other place to 'put' stuff as it relates to a RAR deployment as a whole.

            • 3. Re: JBAS-3343
              weston.price

              Sigh...sorry, I can't resist.

              This also came up in another discussion I had today via email (Sorry Adrian, I didn't start the thread so yell at the EJB3 guys for this :-) )

              In JBoss 4.0.x we had standardjboss.xml allowing for container configurations that would be universally applied across EJB deployments unless overridden by jboss.xml. With the advent of EJB3, this mechanism has essentially dissapeared and again, as if on cue, we had a client asking how can they configure an inflow deployment without having to replicate properties in the ActivationConfig for every MDB. This is really where RA level properties would come into play in for an ActivationSpec. In fact, the spec basically calls for this capability so we may have to end up doing something for this anyway.

              • 4. Re: JBAS-3343

                 

                "weston.price@jboss.com" wrote:

                We definitely don't do the first one, hence the JIRA task, but we also don't allow for the second condition at all. Typical case would be an RA with the following properties:

                RA
                ServerName = "localhost"
                Port = "8080"


                MCF
                ServerName = ""
                Port = ""

                (Yes, yes, stupid example I know)


                What are you talking about?

                We apply the rar properties from the ra.xml to the ResourceAdapter
                We also apply the rar properties onto the MCF, there are tests for this.

                Your example is stupid. In this case, if they specify
                ServerName="" on the MCF then that is the ServerName.
                If they want the rar value then they shouldn't specify it on the MCF.

                The jira issue is about modifying the ResourceAdapter properties
                without having to modify the ra.xml, e.g. using an alt-dd
                or jboss-ra.xml, etc.

                • 5. Re: JBAS-3343

                   

                  "weston.price@jboss.com" wrote:
                  And for some reason...as if literally on cue...we get 2 questions about this in the user forum, and the JIRA task itself...

                  One thing we could do is add a new element to the *-ds.xml file specifically naming RA level properties. Something like:

                  <ra-config-property>

                  Or, add a 'scope' attribute to the existing element. I am inclined to the former just because it is more clear.



                  You can't specify rar properties in the -ds.xml
                  (managed connection factory)
                  It is too late. The rar is already initialized and start() invoked.

                  • 6. Re: JBAS-3343
                    weston.price

                    Where in RAR deployment do we apply the properties for a ResourceAdapter? We definitely do it for the ManagedConnectionFactory, but not for the adapter.

                    • 7. Re: JBAS-3343
                      weston.price

                      Sigh...ok...now I am a complete idiot...

                      I see it....Damnit...

                      • 8. Re: JBAS-3343
                        weston.price

                        Ok, so I propose the following:

                        *-ds.xml is modified

                        Adding

                        <ra-config-property>

                        </ra-config-property>

                        <config-property scope="ra"/>

                        This will give us enough to set the property on the adatper.

                        Agreed?

                        • 9. Re: JBAS-3343
                          weston.price

                          Sigh...ok...this morning sucks...

                          Now that I have proven beyond a shadow of a doubt how utterly f*(@*$ stupid I really am...is there anything wrong with overriding the ResourceAdapter with *-ds.xml properties when we start the deployment?

                          • 10. Re: JBAS-3343

                            No. See my earlier comments.

                            The order is:

                            ResourceAdapter deployer
                            1) Create rar
                            2) Apply properties (ra.xml)
                            3) Apply overrides (THIS IS MISSING AND IS JBAS-3343)
                            4) rar.start()

                            ManagedConnectionFactory deployer
                            11) Create MCF (waits for rar to full start)
                            12) Apply properties from rar (ra.xml)
                            13) Apply properties from mcf (ra.xml)
                            14) Apply overrides (-ds.xml)

                            The simplest solution is to allow a jboss-ra.xml inside the rar.
                            Another would be to have an alternate dds with the
                            rar not getting directly deployed, e.g.

                            <rar>
                             <rar-file>/some/path/to/rar</rar-file>
                             <ra-config-property>
                             etc.
                            


                            • 11. Re: JBAS-3343
                              weston.price

                              Right, right...I got it...after I hear something about 50 times I usually understand...

                              I was already working on a jboss-ra.xml, this would seem to be the best case to introduce it.

                              Could you talk about the second case a bit more. This would seem to be the most interesting. Adding jboss-ra.xml is fine but I just want to understand what you thoughts on the alternative approach would be.


                              • 12. Re: JBAS-3343

                                The second approach is a way to do what JSR88 does.
                                i.e. You have the original jar + an appserver specific desriptor

                                This avoids having to modify somebody else's archive
                                e.g. opening the jar add META-INF/jboss-ra.xml
                                and then rejaring

                                You have an alternate descriptor + deployer, e.g. jboss-rar.xml
                                that points at the rar (not in the deploy directory)
                                and add overriding configuration in the same descriptor.

                                • 13. Re: JBAS-3343
                                  starksm64

                                  This second way is what you should look at because its the way deployers/components need to operate in jboss5 with the profile service. Given a rar to deploy/add to a profile, there has to be a management view that externalizes the settings that can be set by management tools. This info needs to be stored in the associated server profile outside of the rar.

                                  I'm working on merging the current profile service work with the virtual deployment framework in the system2 module to tie this together.

                                  • 14. Re: JBAS-3343
                                    weston.price

                                    Ok. But using this approach would require that the RAR not be in the deploy directory (as you said) and they use the alternateDD/jar to point to the RAR and then override. At least from what I am hearing. I guess I am not clear on what the Deployer actually gets in the DeploymentInfo. Just the alternateDD, or is it actually packed in a RAR that just provides the 'wrapping'? I will take a look at JSR88.

                                    No reason why we couldn't support both approaches. Do the jboss-ra.xml stuff first and then add the alternate DD support.

                                    Man, I am wicked sorry about the idiocy on this one. I have no clue what I was thinking. You can shoot me when you come to Westford...you sort of already did in making me get up and talk in front of people..;-)




                                    1 2 Previous Next