1 2 3 Previous Next 30 Replies Latest reply on Mar 8, 2011 7:06 AM by gaol Go to original post
      • 15. Re: IronJacamar RHQ plugin development
        jesper.pedersen

        Cool.

         

        However, we will need another structure in the view - currently it looks like the structure used for <= AS 6.

         

        resourceadapter.rar   <-- clicking on this will show all config properties for the RA
          - Managed Connection Factories
            - class name <-- clicking on this will show all config properties for the MCF
          - Connection Factories
            - jndi name
              - PoolConfiguration
              - Pool
          - Admin Object
            - class name <-- clicking on this will show all config properties for the AO
        

         

        There is no "Datasources" under a resource adapter.

         

        Since there are no connection factories in the model start with the others. And forget about the "No Tx / Tx" part - we will show an attribute on the resource adapter overview for that.

         

        We will take datasources later, once resource adapters are up and running.

        • 16. IronJacamar RHQ plugin development
          gaol

          OK, the view structure will be changed accordinglly.

          Yes, the class name can be used to display in the view.

           

          One issue:

          The Connector.getManagedConnectionFactory().getManagedConnectionFactory() is null in the rhq environment, the referent object in the associated WeakReference is cleared for unkown reason, but it works fine in unit test evironment.

          • 17. Re: IronJacamar RHQ plugin development
            gaol

            Without the WeakReference issue mentioned in above comment, the view structure screen shot will be like:

             

            view_structure_c1.png

            • 18. Re: IronJacamar RHQ plugin development
              jesper.pedersen

              Ok, we will have to look into why the reference is null. Either the resource adapter isn't deployed anymore, or there is no managed connection factory for the archive. You can try and set a break point and see if that will give you an idea.

               

              The view structure is better - however, the configuration part on the right side of the screen is still showing all the "old" values - like jndi name and so on. It needs to show the config-property's of the managed connection factory, like:

               

              <config-property>
                <config-property-name>myStringProperty</config-property-name>
                <config-property-type>java.lang.String</config-property-type>
                <config-property-value>JEFF</config-property-value>
              </config-property>
              

               

              The same when you press the resource adapter view.

              • 19. Re: IronJacamar RHQ plugin development
                gaol

                view_with_config.png

                 

                This is the view of the ManagedConnectionFactory defined in resource: notransaction.rar. There is only one config property defined in this resource.

                 

                For the WeakReference issue, I am sure the .rar resources have the managed connection factories defined, and they are deployed without prolbems after debugging, I will research more on this issue to figure out any clue.

                 

                For the config-property defined in the ManagedConnectionFactory, does any of the config-property definition in ra.xml match one instance variable in the ManagedConnectionFactory Java class? In the example:

                 

                 

                 

                {code:xml}

                <config-property>

                  <config-property-name>myStringProperty</config-property-name>

                  <config-property-type>java.lang.String</config-property-type>

                  <config-property-value>JEFF</config-property-value>

                </config-property>

                {code}

                 

                there will be a method:

                 

                {code}

                public String getMyStringProperty(){

                    return this.myStringProperty;

                }

                {code}

                 

                defined in the associated ManagedConnectionFactory or AdminObject class.

                 

                If so, how to do if we want to add new config-property using this plugin?

                • 20. Re: IronJacamar RHQ plugin development
                  jesper.pedersen

                  Yup, looks good -- remember to add support for JCA 1.6 config-property's

                   

                  • dynamic: Enable write access to the property
                  • confidential: Write out in UI as '********'

                   

                  The values are retrieved or set using their Java bean method (getX/isX/setX).

                   

                  There shouldn't be a way to add new properties to either the resource adapter nor managed connection factory instances.

                  • 21. IronJacamar RHQ plugin development
                    gaol

                    There are some issues on the dynamic & confidential support, please refer to the mail list thread: https://fedorahosted.org/pipermail/rhq-users/2011-February/000319.html

                     

                    The read only & confidential depends on the deployed resource instances, but these attributes are pre-defined as meta data in the rhq-plugin.xml, which will be persisted when the plugin is installed.

                     

                    We can not change the read only state after the plugin insatlled.

                    • 22. IronJacamar RHQ plugin development
                      jesper.pedersen

                      Well, a resource adapter / managed connection factory property is either read-only, read-write or confidential, so we don't need to be able to change its state.

                       

                      If this isn't supported atm, you will need to open a feature request against version 4.

                       

                      And then continue having all properties as read-only for the moment.

                      • 23. IronJacamar RHQ plugin development
                        gaol
                        If this isn't supported atm, you will need to open a feature request against version 4.

                         

                        And then continue having all properties as read-only for the moment.

                        Open a feature proposal at link: https://bugzilla.redhat.com/show_bug.cgi?id=677916

                        • 24. Re: IronJacamar RHQ plugin development
                          gaol

                          There are some plans after discussion with Young:

                          1.  For the code structure, we will create 2 sub packages for implementation of AS7, ironjacamar standalone separately. The most common functions will be abstracted to the package: org.jboss.jca.rhq.core,

                           

                          And the build process will create 2 jars like:

                          • ironjacamar-rhq-plugin-as7.jar   // used in AS 7
                          • ironjacamar-rhq-plugin-standalone.jar  // used in ironjacamar standalone mode

                           

                          except we can find a way to know which situation the current runtime environment is in.

                           

                           

                          2. If the org.jboss.jca.core.api.management.ManagementRepository can be transferred to RHQ plugin in all situations, we can use it directly without abstracting our own model for this RHQ plugin. This class is used only for RHQ to discover JCA resources.

                           

                          We suggest some changes on jca management model to remove the WeakReference to the real JCA objects, instead using a string to indicate where we can find the JCA objects, take the org.jboss.jca.core.api.management.ResourceAdapter as an example:

                           

                          {code}

                          public class ResourceAdapter{

                           

                            /** This is used as resource meta data, displayed in the navigation tree  **/

                            private String raClassName;

                           

                            /** This is the location where we can find the real javax.resource.spi.ResourceAdapter

                             *  It will be a ObjectName string in ironjacamar standalone situation

                             *  It will be a URI string in AS 7 to the associated ManagedResource

                             **/

                            private String raLocation;

                           

                            private List<ConfigProperty> configProperties;

                          }

                          {code}

                           

                          All config-properties in the JCA objects are needed when user wants to see them(by clicking configuration tab in the RHQ UI page), the value should be retrieved at this time to keep up-to-date.

                           

                          Current design of jca management model assumes RHQ plugin is in same JVM as JCA container. In case of remote, will the jca objects be transferred to RHQ together with ManagementRepository? It is not good to transfer the whole object back, we only need some meta data information to display for now. All other information should be retrieved when needed. Besides, some config-property information in the JCA object transferred together with ManagementRepository may not be fresh.

                          • 25. Re: IronJacamar RHQ plugin development
                            jesper.pedersen

                            Until the feature request is resolved just do the best we can in this area.

                            • 26. Re: IronJacamar RHQ plugin development
                              jesper.pedersen

                              1.  For the code structure, we will create 2 sub packages for implementation of AS7, ironjacamar standalone separately. The most common functions will be abstracted to the package: org.jboss.jca.rhq.core,

                               

                              And the build process will create 2 jars like:

                              • ironjacamar-rhq-plugin-as7.jar   // used in AS 7
                              • ironjacamar-rhq-plugin-standalone.jar  // used in ironjacamar standalone mode

                               

                              except we can find a way to know which situation the current runtime environment is in.

                               

                              That is the job of the Discover process - default being a discovery against an in-vm instance. I'll take a look at this soon.

                               

                              2. If the org.jboss.jca.core.api.management.ManagementRepository can be transferred to RHQ plugin in all situations, we can use it directly without abstracting our own model for this RHQ plugin. This class is used only for RHQ to discover JCA resources.

                               

                              ManagementRepository is the instance that lives in the same VM as the container, and will delegate all calls in-vm.

                               

                              So in case of a plugin connecting to a remove instance you'll need a "proxy" to handle that communication:

                               

                               

                              In-VM:
                              ------
                              RHQ Plugin -> Embedded discovery -> ManagementRepository
                              
                              Remote VM:
                              ----------
                              RHQ Plugin -> Remote discovery -> Network transport -> RemoteManagementRepository -> ManagementRepository
                              
                              

                               

                              Of course we can have a facade for ManagementRepository in the plugin such that communication can be optimized in the remote scenario, since in some instances a query for configuration property names will limit network bandwidth.

                               

                              The ManagementRepository should always delegate calls to dynamic attributes and operations. In most cases we can handle that by supplying a WeakReference to the actual object, and just call directly. We just need to expose the information we need in the right locations - like the .api...Pool class.

                               

                              However, currently the focus on the purely embedded case - using IronJacamar/Embedded for testing, and IronJacamar/AS7 for real data.

                              • 27. Re: IronJacamar RHQ plugin development
                                yang.yong

                                Hi Jesper,

                                 

                                Returning ManagementRepository works well in ronJacamar/Embedded environment, but for IronJacamar/AS7 and IronJacamar/standalone environments, I think it is not suitable to return ManagementRepository instance, because we have to face many problems. In fact there are 2 ways to return a ManagementRepository instance, we can analyze these 2 ways.

                                  1) Serailize.

                                     In this situation, we have to make all IronJacamar Management POJO classes serializable even if the referenced classes, and may cause network bandwidth issue and dirty local data issue, so this is not a good enough plan.

                                 

                                  2) return a (Dynamic) Proxy object

                                     A proxy object will delegate all invocations to remote IronJacamar Management Model and don't have any local data, the problem is we have to map objects between "AS Detyped MetaValue object" and "IronJacamar management POJO", but actually we can resolve Detyped MetaValue and show the value in the console UI directly, this looks like an extra work.

                                 

                                So, after discuss with lgao, our plan is creating an abstract layer to encapsulate all common methods,and the separate implementations of AS7/Standalone/embedded to 3 sub-packages , and in the implementation classes of the sub-packages, can implement the abstract methods(for example methods to get and resolve data) by using the best way in each enironment separately, for example, use as7 management api in IronJacamar/AS7, use jmx in IronJacamar/Standalone, and directly call ManagementRepository in IronJacamar/Embedded for testing. This structure looks simple and clear, and easy to maintain.

                                 

                                Package sturcture:

                                ...rhq                (abstract classes encapsulate all common methods here)
                                    |
                                    - as7             (implementation for as7 here)
                                    |
                                    - standalone      (implementation for IronJacamar standalone here)
                                    |
                                    - embedded        (implementation for IronJacamar embeddded testing here)
                                
                                • 28. Re: IronJacamar RHQ plugin development
                                  jesper.pedersen

                                  I think you misunderstood me.

                                   

                                  The network transport part is specific to IronJacamar - our own protocol - to retrieve information or invoke operations. There is no serialization of the ManagementRepository going on - nor proxy stuff.

                                   

                                  The packages you mentions are correct - they contains the functionality needed to discover the environment, like the embedded container.

                                   

                                  F.ex. the "as7" and "standalone" will have a discovery implementation for accessing remote containers based on the "manual add" functionality (http://pilhuhn.blogspot.com/search?q=manualadd).

                                   

                                  The focus should be on the core and embedded packages first, as we need that for testing the plugin, and defining which functionality we need from the IronJacamar container. Once that is done we will do an as7.InVMDiscovery class for AS 7 specific discovery. After that an as7.RemoteDiscovery class.

                                   

                                  The "standalone" package has the lowest priority as the standalone distribution doesn't feature a RHQ platform at the moment. It is correct that a bridge between the plugin and JMX would be the quickest solution.

                                  • 29. Re: IronJacamar RHQ plugin development
                                    jesper.pedersen

                                    Gao, regarding JBJCA-507 - there are a couple of things with the JIRA we need to clear up.

                                     

                                    First the WeakReference issue - those are WeakReferences because the management layer can't keep a deployment active. That is the job of the services around that area.

                                     

                                    So my guess is that the resource adapter you are using is not fully implemented with the constructs you need for your test case. F.ex. make sure that the ManagedConnectionFactory is used ResourceAdaperAssociation, and the ManagedConnectionFactory is included as a variable in your ConnectionFactory's. The same goes for AdminObject's. If that doesn't help then we need to investigate further why those references are null. You can use the code generator or see the HelloWorld example in order to get started.

                                     

                                    It is correct that in some cases the objects will only be used during startup, and hence not valid once management kicks in. In those scenarios we need to back the view (f.ex. ResourceAdapter) with a read-only model based on the metadata (ra.xml / ironjacamar.xml).

                                     

                                    So in the end there will a valid view of the deployments without having to construct it - the management layer needs to look at the "live" objects in the container.

                                     

                                    Hope this helps !