2 Replies Latest reply on Oct 6, 2010 3:48 PM by jeanluc

    Avoiding hardcoded server URL in external-authentication-config.xml

    jeanluc

      I've just started looking at integrating PicketLink with a Seam app.

       

      One problem found so far is that the external-authentication-config.xml file contains deployment-time information, i.e. the server name and port.

      This is an issue because my project (an "enterprisey" one ) is to be deployed in multiple environments and, as such, the same EAR is supposed to be used in all of them.

       

      One workaround is to externalize the URL into a build-time configuration file, parse external-authentication-config.xml during the Maven build and replace it then. This still requires different builds.

       

      Is there any better solution?

       

      Thanks.

      JL

        • 1. Re: Avoiding hardcoded server URL in external-authentication-config.xml
          marcelkolsteren

          Hi Jean Luc,

           

          Some other solutions (not necessarily better):

           

          • Deploy the ear file in exploded form, and use a deployment script that does a search & replace in the external-authentication-config.xml of the exploded ear.
          • Make use of the multi-tenant functionality of the PicketLink Seam module. You can define multiple service providers in one configuration file, each with a different host name. This feature has originally been created for applications that need to serve different companies (tenants). Per request, the host name of the request is used to choose the corresponding service provider configuration. I expect that this also works for multi-environment deployments (for example development, test, production).

           

          I prefer the first solution and use it for deploying to the development, test and production environment.

          1 of 1 people found this helpful
          • 2. Re: Avoiding hardcoded server URL in external-authentication-config.xml
            jeanluc

            Thanks Marcel,

             

            Option 1 doesn't work for us (the EARs are prepared and version-controlled prior to deployment) but the multi-tenant approach sounds interesting. I'll try it when I get to that stage.

             

            Thanks,

            JL