1 2 Previous Next 16 Replies Latest reply on Feb 12, 2007 4:41 AM by legolas

    Packaging of portlet-instances.xml

    legolas

      Hi all,

      Where does the portlet-instances.xml need to be packaged?

      I read from the docs of JBP2.4.1, that the use of the *-object.xml for defining portlet instances is deprecated and support will be removed from JBP 2.6 on.

      I want to be able to specify which instances I need in my portal outside of my portlet war files.
      Is this possible in JBP 2.6?

      Regards,
      Marcel

        • 1. Re: Packaging of portlet-instances.xml

          portlet-instances.xml file have to be packaged with a war file because they require the portlet to be present and the only way to achieve that is by doing such a deployment.

          otherwise the -instances.xml file could be created before the war file containing the portlet is deployed.

          you still have the option of using programmatic code that will use directly the InstanceContainer interface to create portlet instances programmatically :

          public interface InstanceContainer
          {
          
          ...
          
           /**
           * Return the underlying portlet invoker for the instance container.
           *
           * @return the portlet invoker
           */
           PortletInvoker getPortletInvoker();
          
           /**
           * Create a new instance of the specified portlet.
           *
           * @param id
           * @param portletId the portlet id
           * @return the newly created instance
           * @throws DuplicateInstanceException if the instance already exist
           * @throws IllegalArgumentException if the instance id is null
           */
           InstanceDefinition createDefinition(String id, String portletId) throws DuplicateInstanceException, IllegalArgumentException, PortletInvokerException;
          
          ...
          
          }


          In order to find out the right portlet id to use, you should use the getPortletInvoker() method to retrieve the portlet invoker behind the instance container and on the portlet invoker you have a getPortlets() method which returns all the portlets known by the portlet invoker. It is a set of PortletInfo interface which will give you the portlet name as well as all the metadata provided by the portlet (from portlet.xml and jboss-portlet.xlm for example).


          • 2. Re: Packaging of portlet-instances.xml
            peterj

            Consider this situation. I have a portlet in a war file, and in the portlet-instance.xml file I declare an instance of my portlet, and also create an instance of, for example, CMSPortlet. On 2.4.x, I can deploy my war file and get both my portlet and the CMSPorltet instances. Are you saying that this scenario will no longer work in 2.6?

            • 3. Re: Packaging of portlet-instances.xml

              2.6 work the same as 2.4 works, so there may be some misunderstanding here.

              What is not possible in 2.4 and 2.6 is to create portlet instances in -object.xml outside of war files.

              • 4. Re: Packaging of portlet-instances.xml
                peterj

                Thanks for clearing that up, Julien.

                • 5. Re: Packaging of portlet-instances.xml
                  legolas

                  We would like to NOT define the specific instances including all its parameters in the portlet war file. This would mean that we need to repackage the war file each time an instance needs to be added.
                  We want to create a separate war file that contains the portal definition in a something-object.xml as can be done in JBP2.2, and define in the same war file each portlet instance.
                  Can this only be accomplished using coding?

                  PeterJ's response suggest that I could create a portlet-instance.xml in a war but still create instances deployed in different war files.
                  Is this correct? If so how do I reference a portlet in a different war?

                  Thanx in advance.

                  • 6. Re: Packaging of portlet-instances.xml

                    Today what you want is not possible anymore due to the issue I explained before (portlets may be deployed before the -object.xml file).

                    However it is possible to do it programatically using the services I explained before.

                    What could be possible is to have the insertion of XML files using JMX, on each MBean representing a portlet container, you could ask it to try to create the related instances.

                    Same would apply for portal objects.

                    • 7. Re: Packaging of portlet-instances.xml
                      legolas

                      Thanks Julian for your quick answer.
                      This is the direction I thought we needed to take in case it wasn't possible any more, as seems to be the case.

                      Marcel

                      • 8. Re: Packaging of portlet-instances.xml
                        legolas

                        Hi Julian (or others),

                        Can you please explain what the best way is to get hold of the InstanceContainer object?

                        • 9. Re: Packaging of portlet-instances.xml

                          If you write an MBean, the best way is to inject it into your MBean using :

                           <mbean ...>
                           ...
                           <depends
                           optional-attribute-name="InstanceContainer"
                           proxy-type="attribute">portal:container=Instance</depends>
                           ...
                           <mbean>
                          


                          If you want to do that from a Portlet component, you can inject an MBean service into the servlet context attributes and then make a lookup from the PortletContext. In that case you need to have in your jboss-portlet.xml :

                           <portlet-app>
                           ...
                           <service>
                           <service-name>InstanceContainer</service-name>
                           <service-class>org.jboss.portal.core.model.instance.InstanceContainer</service-class>
                           <service-ref>:container=Instance</service-ref>
                           </service>
                           ...
                           </portlet-app>
                          


                          then in your portlet you can do, usually best placed into the init() method :

                           InstanceContainer container = (InstanceContainer)getPortletContext().getAttribute("InstanceContainer");
                          


                          If you do use portal services, you should also declare the transactional attribute in jboss-portlet.xml that will propagate the portal transaction to the portlet or create a new one like :

                           <portlet>
                           <portlet-name>MyPortlet</portlet-name>
                           <transaction>
                           <trans-attribute>Required</trans-attribute>
                           </transaction>
                           </portlet>
                          


                          or

                           <portlet>
                           <portlet-name>MyPortlet</portlet-name>
                           <transaction>
                           <trans-attribute>RequiresNew</trans-attribute>
                           </transaction>
                           </portlet>
                          



                          • 10. Re: Packaging of portlet-instances.xml
                            peterj

                            To clear up my earlier post, I am not implying that I can have a war file with just a porltet-instances.xml file and an *-object.xml file. That will not work because the Portal ignores portlet-instances.xml files if there is no portlet to deploy. Thus, I need to declare at least one porltet, along with its portlet.xml file, within the war file. Then the portlet-instances.xml file can create instanceso fthat portlet and any other porlets in other war files. Of course, as Julien noted, you can run into a problem if the new war file is deployed before the war file(s) containing the portlets you are referencing.

                            • 11. Re: Packaging of portlet-instances.xml
                              legolas

                              Peter thank you for clarifying that, and Julian thank you for showing how to get hold of the instance container.

                              We will work on an MBean based solution that inserts its definitions using the instance container.

                              Grtz,
                              Marcel

                              • 12. Re: Packaging of portlet-instances.xml
                                legolas

                                Hi,

                                I am currently implementing the above mentioned component, and I would much appreciate if someone can explain me how I can create a typed Value instance for the preferences?

                                Does JBoss portal provides any means for retrieving th etype of a preference value or do I have to implement this myself?

                                Kind regards,
                                Marcel

                                • 13. Re: Packaging of portlet-instances.xml

                                  at the end preferences are stored as strings in the db with an integer which says what data type it is.

                                  this is the potential usage as in reality we only use strings because JSR168 does not support more than that (unless you write your extension).

                                  what is the interface you are using ? Instance.getProperties() and Instance.setProperties(...) ?

                                  • 14. Re: Packaging of portlet-instances.xml
                                    legolas

                                    I have implemented it as follows:

                                    ValueMap preferences = instance.getPreferences();
                                    while (iterator.hasNext())
                                    {
                                     Element preference = (Element) iterator.next();
                                     String name = preference.valueOf(PREFERENCE_NAME);
                                     Value originalValue = preferences.getValue(name);
                                     if (null != originalValue)
                                     {
                                     Class<Value> valueClass = getValueClass(originalValue);
                                     Value value = createValue(preference, valueClass);
                                     preferences.setValue(name, value);
                                     }
                                    }
                                    instance.setPreferences(preferences);
                                    


                                    This prohibits adding undefined preferences, only predefined prefs can now be overridden, and its type is taken over from the original type.
                                    But according to you, this could be simplified to using strings only.


                                    1 2 Previous Next