deployment.xml for an ear - Websphere

This is a discussion on deployment.xml for an ear - Websphere ; I am real new to WebSphere and I am coming in at a different angle so forgive me if this is too obvious. I gave a quick look and search but have not found anything that explains it simply. I ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: deployment.xml for an ear

  1. deployment.xml for an ear

    I am real new to WebSphere and I am coming in at a different angle so forgive me if this is too obvious. I gave a quick look and search but have not found anything that explains it simply.

    I am deconstructing how an ear was deployed. According to a WAS admin there was a deployment.xml file located within the ear. After looking at it I think it is a document that allows hot deploy and configuration settings to be done during ear deployment as opposed to after the fact?

    Here are my questions
    1.) What is deployment.xml for and can it be packaged in an ear
    2.) I am not using a RAD or other tool so is there a redbook or other doc explaining how to create one and the options available to me?
    3.) Below is the contents of the deployment.xml. There is an area called classloader and libraries. There are xmi::id values in here that look like they were either auto generated or that they are well defined. Which is it?
    4.) In the same section it looks like the xml file is setting up a shared library (BlazeLib) for the ear being deployed ... is that the case? I also assume that this shared library would have already been setup through the admin console.


    eployment xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:appdeployment="http://www.ibm.com/websphere/appserver/schemas/5.0/appdeployment.xmi" xmi:id="Deployment_1141420612880">
    3nashwasdevcell0/CBCFCCScoring">












    eployment>


    thanks in advance for your time!

    Doug

  2. Re: deployment.xml for an ear

    Hi Doug,

    1) deployment.xml is a proprietary WAS config file that's placed in the internal copy of the ear that WAS stores within its SM repository. It is packaged in the ear by WAS SM during the application install.
    2) Users do not typically these directly; they're for WAS internal implementation use, and their syntax is not typically documented. In this respect they can be considered internal implementation details of WAS.
    3) The xmi::id values are auto-generated by the internal WAS code (currently it's Eclipse EMF) that writes out the deployment.xml file.
    4) The shared library entries in the deployment.xml you're looking at (hopefully) match what the administrator specified in the admin console or wsadmin command when they installed the application, or later associated the app to a shared library.

    Side note: most typically, these internal WAS config files have an .xmi extension (XML Metadata Interchange) -- examples are ibm-ejb-jar-bnd.xmi, ibm-web-ext.xmi and so on. A few of them have xml extensions, though they are not "true" XML files and are really more like xmi files in that they don't use a DTD or XSD definition file to define their schema. One example is deployment.xml.

    Hope this helps.
    Randy

    dlochart@gmail.com wrote:
    > I am real new to WebSphere and I am coming in at a different angle so forgive me if this is too obvious. I gave a quick look and search but have not found anything that explains it simply.
    >
    > I am deconstructing how an ear was deployed. According to a WAS admin there was a deployment.xml file located within the ear. After looking at it I think it is a document that allows hot deploy and configuration settings to be done during ear deployment as opposed to after the fact?
    >
    > Here are my questions
    > 1.) What is deployment.xml for and can it be packaged in an ear
    > 2.) I am not using a RAD or other tool so is there a redbook or other doc explaining how to create one and the options available to me?
    > 3.) Below is the contents of the deployment.xml. There is an area called classloader and libraries. There are xmi::id values in here that look like they were either auto generated or that they are well defined. Which is it?
    > 4.) In the same section it looks like the xml file is setting up a shared library (BlazeLib) for the ear being deployed ... is that the case? I also assume that this shared library would have already been setup through the admin console.
    >


  3. Re: deployment.xml for an ear

    > Hi Doug,
    >
    > 1) deployment.xml is a proprietary WAS config file
    > that's placed in the internal copy of the ear that
    > WAS stores within its SM repository. It is packaged
    > in the ear by WAS SM during the application install.
    > 2) Users do not typically these directly; they're for
    > WAS internal implementation use, and their syntax is
    > not typically documented. In this respect they can
    > be considered internal implementation details of WAS.
    > 3) The xmi::id values are auto-generated by the
    > internal WAS code (currently it's Eclipse EMF) that
    > writes out the deployment.xml file.
    > 4) The shared library entries in the deployment.xml
    > you're looking at (hopefully) match what the
    > administrator specified in the admin console or
    > wsadmin command when they installed the application,
    > or later associated the app to a shared library.
    >
    > Side note: most typically, these internal WAS config
    > files have an .xmi extension (XML Metadata
    > Interchange) -- examples are ibm-ejb-jar-bnd.xmi,
    > ibm-web-ext.xmi and so on. A few of them have xml
    > extensions, though they are not "true" XML files and
    > are really more like xmi files in that they don't use
    > a DTD or XSD definition file to define their schema.
    > One example is deployment.xml.
    >
    > Hope this helps.
    > Randy


    Thanks Randy,

    It does help a bit and now I have a more refined question. You mentioned that the deployment.xml was placed in the internal copy of the ear. Is it possible for a tool like RAD to include a file like this in the ear before it gets deployed? I ask because the ear in question depends on a shared library (BlazeLib). I believe the library needs to be accessible immediately as the EAR would not deploy and start properly without. In my limited experience with WAS it seems that you associate a shared library with an application after it has been deployed.

    Could a deployment tool have done this or is this strictly a way that WAS tracks server deployment settings?

    Let's say you had an ear that relied on a shared library in order to run/deploy. How do you solve this chicke and egg thing or should the ear be able to deploy anyway?

    thanks again for your time.


  4. Re: deployment.xml for an ear

    That's a good question. I'm not aware of being able to do this, but I've posed the question to a colleague within WAS system management and will reply with any findings.

    One option of course is to pre-deploy the application with the command-line EJBDeploy tool prior to installation (making the shared library classes available on the classpath), then later install the app. WAS SM examines the app and makes an estimation of whether the EJBDeploy tool needs to be run during app install, by pre-selecting or not selecting the 'deploy application during install' checkbox in the WAS admin console. If you've already run EJBDeploy on the app prior to installing it, this checkbox should be de-selected by default and then no EJBDeploy is performed during installation.

    dlochart@gmail.com wrote:
    >
    > It does help a bit and now I have a more refined question. You mentioned that the deployment.xml was placed in the internal copy of the ear. Is it possible for a tool like RAD to include a file like this in the ear before it gets deployed? I ask because the ear in question depends on a shared library (BlazeLib). I believe the library needs to be accessible immediately as the EAR would not deploy and start properly without. In my limited experience with WAS it seems that you associate a shared library with an application after it has been deployed.
    >
    > Could a deployment tool have done this or is this strictly a way that WAS tracks server deployment settings?
    >
    > Let's say you had an ear that relied on a shared library in order to run/deploy. How do you solve this chicke and egg thing or should the ear be able to deploy anyway?
    >
    > thanks again for your time.
    >


  5. Re: deployment.xml for an ear

    Thanks for your insight. I will look into the EJBDeploy tool and see what I can find. I may not have to mimic the behavior of the current deployed ear if not I will packaged all dependent jars inside the ear. If I do I will probably have to use EJBDeploy. When I tried deploying my ear in the same fashion as the one in question it would not deploy because of the missing jars.

    thanks

+ Reply to Thread