4 Replies Latest reply on Apr 23, 2009 11:35 AM by 693682

    Writing a JSR168 portlet WITHOUT using Jdeveloper or "wizards"

      I have a JSR168 portlet that is built using Maven (http://maven.apache.org/ if you don't know what that is).

      It deploys and operates perfectly well into a portlet container such as Pluto (the standard, reference container from Apache).

      Pluto supplies a Maven plugin, that takes the vanilla web.xml and other configuration e.g. portlet.xml and adds the necessary configuration to run the portlet in the container. I believe there is an Ant plugin that does exactly the same thing.

      It adds the following conf to teh web.xml;




      This is the "magic" that glues my portlet to the portlet container.

      What I wish to know, is how to make my JSR168 portlet deploy into Oracle Portal 10g without EVER using JDeveloper. What is the 'magic' I have to apply to my web.xml or portlet.xml or other configuration that will men I can deploy my portlet war into the app server and make it talk turkey with the portal container. I can cope with just having a customised web.xml that I have to copy into the WAR file if need be ... if I could find some guidance what should be in that file.

      It seems that every search I've done in google or though the doco we have here starts with "Start Jdeveloper and select XXX in the portlet wizard".

      I do not use Jdeveloper and nor will I. I will continue to build my Java code in a correct fashion, i.e. on the command line with my standard build tools that don't involve the IDE. Don't get me wrong, I use an IDE, but one should never be mandated. In my book, "wizards" are about the worst imaginable way to get any programming task completed.
        • 1. Re: Writing a JSR168 portlet WITHOUT using Jdeveloper or "wizards"
          With a bit of experimentation, we found the short answer is not to do ANYTHING extra to the web.xml or the portlet.xml. We used our plain-vanilla web.xml that was e.g. used for the input to the Pluto plugin step mentioned above. So in our source control, we've got nothing container-specific for any container in our web.xml or portlet.xml.

          To get this JSR portlet running on Oracle Portal we had to do the following:

          1. Create a new OC4J instance.

          2. Install the portlet container to the OC4J instance. Refer portal development guide section 6.3. This is a separately downloaded component from OTN. (URL in the doco)

          3. Deploy portlet WAR to the OC4J instance.

          4. In deployment process the portlet container will generate WSRP endpoints for you automatically. Note these enpoint URLs for the next step.

          5. Within Portal, register a WSRP provider for the new portlet. The WSRP urls are found back in the configuration screens in step 4.

          6. Once registered the portlet will appear in the portlet staging area and can be added as normal.

          7. This step is still to come ... how to do at least 4 to 6 from the command line.

          We intend to have a continuous integration server, e.g. Hudson or Cruisecontrol, deploy successfully building portlet WARs automatically to the Oracle Portal as above on completion of all successful unit tests ... and then hopefully run the integration tests on the portal pages. Automatically after every check in.
          • 2. Re: Writing a JSR168 portlet WITHOUT using Jdeveloper or "wizards"
            Steps 3 and 4 will be done with dcmctl.

            Automating steps 5 and 6 with scripted deployment to the Portal remains to be seen.

            Anyone with insight into such a requirement would be good to hear from. We've had an initial look around the PDK but nothing presents itself.
            • 3. Re: Writing a JSR168 portlet WITHOUT using Jdeveloper or "wizards"
              You don't need JDeveloper to write a JSR 168 portlet. You can use any Java IDE, like Eclipse.
              You can even write portlets with a text editor and compile them on the command line.
              The you need to package your EAR file.

              The EAR file needs to be deployed in a WSRP container. This can be done on the command line.
              Alternatively, if you are using Enterprise Manager, it is also possible to deploy EAR files using OEM's web interface. No JDeveloper or command line is required.

              Best regards,
              • 4. Re: Writing a JSR168 portlet WITHOUT using Jdeveloper or "wizards"
                Hi Marcel

                With respect, it's patently obvious that we know how to develop a portlet without Jdeveloper, because if you read the message you would have been able to discern that this is the way we are accustomed to doing it, and it's faster, easier and more portable that way. I've been doing J2EE development since the first version of the spec and well before there was an Oracle implementation of it.

                You don't actually need an EAR file, as a WAR will suffice and the dcmctl command-line utility can supply everything else in its arguments (like, context-path and the like), and it allows each WAR artifact to be deployed in different times, i.e. when they are built on the integration server. I find EAR files usually too heavyweight especially as I rarely write EJBs, as opposed to using e.g. Spring.

                Using the web browser is not an option for automated deployment and acceptance testing from an integration build server.

                Configuring the portal side of things looks decidedly a different matter and I've not found anyway to do it from the command line, it demands the browser, which is a let-down.

                It's terribly disappointing the paucity of information about automation of deployment as opposed to the positively verdant amount of presentations, tutorials and documentation that assumes top-to-bottom Oracle tooling and environment and browser-based configuration. Even where it's actually possible Oracle doesn't seem to want to tell people about it or do as I believe they should, which is regard this form of deployment and configuration as the default way to teach developers how to use their products. None of this helps build and deploy to Oracle products using test-driven development, continuous integration, and automated acceptance testing, all of which are usually regarded as essential parts of a modern developers toolkit by the best minds in the business.

                So after we're left alone to discover how to do this by ourselves for a month you can forgive my disappointment at being lectured like I was some neophyte who doesn't know how to make a WAR file with textedit.