Running (into problems with) WebSphere8.5 on Linux using Cargo 1.4.11

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Running (into problems with) WebSphere8.5 on Linux using Cargo 1.4.11

Andreas Tschabuschnig
Before saying anything at all, I'd like to start with a huge thank you
to all the developers of Cargo for doing a stellar job. Within a
handful of days I managed to switch important parts of our integration
testing infrastructure from using internal tools to Cargo. At least
those using Tomcat and JBoss.

The next on my list is WebSphere, and it is giving me a little bit of
trouble. I have been trying to start an ear file using an already
installed WebSphere application server, and using the ZipUrlInstaller,
both with the same result.

After adding the native lib folder to the PATH variable, I'm getting
stuck at the profile manager, which always fails with:
> profilePath: The profile path is not valid.

Looking at the debug output and the source code, I don't see how I
could override this value, and CARGO-147 mentions troubles with the
profile manager, but doesn't give much help to troubleshoot this.
Calling manageprofiles.sh directly produces the same result. Unless
-profilePath is given it fails.

Tested on CentOS and Ubuntu server, using WebSphere 8.5.0 and 8.5.5

Any help would be highly appreciated.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Running (into problems with) WebSphere8.5 on Linux using Cargo 1.4.11

S. Ali Tokmen
Hi Andreas

Thanks for your message.

The CARGO WebSphere container is indeed the most recent addition and is unfortunately the most unstable for now - Petr is working on improving it, you can look at CARGO-1285 to have an idea on what he is doing.

On the other hand, we had successful executions of the WebSphere container (on Windows, but hopefully CentOS should also work). What type of configuration are you using, standalone or existing local configuration? I am assuming that with the ZipUrlInstaller you most likely have standalone but wanted to double check...

Perhaps sharing the whole configuration can be helpful too.

Please advise

S. Ali Tokmen
http://ali.tokmen.com/
http://contact.ali.tokmen.com/
On 22/12/14 20:00, Andreas Tschabuschnig wrote:
Before saying anything at all, I'd like to start with a huge thank you
to all the developers of Cargo for doing a stellar job. Within a
handful of days I managed to switch important parts of our integration
testing infrastructure from using internal tools to Cargo. At least
those using Tomcat and JBoss.

The next on my list is WebSphere, and it is giving me a little bit of
trouble. I have been trying to start an ear file using an already
installed WebSphere application server, and using the ZipUrlInstaller,
both with the same result.

After adding the native lib folder to the PATH variable, I'm getting
stuck at the profile manager, which always fails with:
profilePath: The profile path is not valid.
Looking at the debug output and the source code, I don't see how I
could override this value, and CARGO-147 mentions troubles with the
profile manager, but doesn't give much help to troubleshoot this.
Calling manageprofiles.sh directly produces the same result. Unless
-profilePath is given it fails.

Tested on CentOS and Ubuntu server, using WebSphere 8.5.0 and 8.5.5

Any help would be highly appreciated.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




Reply | Threaded
Open this post in threaded view
|

Re: Running (into problems with) WebSphere8.5 on Linux using Cargo 1.4.11

Petr Široký
In reply to this post by Andreas Tschabuschnig
Hello Andreas,

> profilePath: The profile path is not valid.
I stumbled upon the same error  when trying to let the cargo create the profile from scratch. I am still not sure what is the root cause though. I will keep digging into this and once I have some news I will let you know. Or if you find a way to avoid/fix/workaround this error, please let me know :)

Thanks,
Petr


On 22 December 2014 at 19:00, Andreas Tschabuschnig <[hidden email]> wrote:
Before saying anything at all, I'd like to start with a huge thank you
to all the developers of Cargo for doing a stellar job. Within a
handful of days I managed to switch important parts of our integration
testing infrastructure from using internal tools to Cargo. At least
those using Tomcat and JBoss.

The next on my list is WebSphere, and it is giving me a little bit of
trouble. I have been trying to start an ear file using an already
installed WebSphere application server, and using the ZipUrlInstaller,
both with the same result.

After adding the native lib folder to the PATH variable, I'm getting
stuck at the profile manager, which always fails with:
> profilePath: The profile path is not valid.

Looking at the debug output and the source code, I don't see how I
could override this value, and CARGO-147 mentions troubles with the
profile manager, but doesn't give much help to troubleshoot this.
Calling manageprofiles.sh directly produces the same result. Unless
-profilePath is given it fails.

Tested on CentOS and Ubuntu server, using WebSphere 8.5.0 and 8.5.5

Any help would be highly appreciated.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Running (into problems with) WebSphere8.5 on Linux using Cargo 1.4.11

Andreas Tschabuschnig
@Ali
I tried with both, an existing installation, that is known to work
with currently used proprietary tools, and a standalone installation,
using the tar.gz that was used to setup the existing installation.
The maven configuration is mostly using defaults and looking something
like this for the standalone installation:
          <plugins>
            <plugin>
                <groupId>org.codehaus.cargo</groupId>
                <artifactId>cargo-maven2-plugin</artifactId>
                <version>1.4.11</version>
                <configuration>
                    <container>
                        <containerId>websphere85x</containerId>
                        <zipUrlInstaller>

<url>file:///home/atschabu/was855-linux-x86-64.tar.gz</url>
                        </zipUrlInstaller>
                    </container>
                    <configuration>
                        <properties>
                            <cargo.servlet.port>8090</cargo.servlet.port>
                    </properties>
                </configuration>
                <deployables>
                    <deployable>
                        <pingURL>http://localhost:8090/ping</pingURL>
                        <pingTimeout>600000</pingTimeout>
                        <location>test.ear</location>
                    </deployable>
                </deployables>
            </configuration>
        </plugin>

So far I stumbled upon the following issues:
* It is necessary to add the native lib folder to the PATH variable,
even if using the ZipUrlInstaller. Which means I have to add a folder
to PATH that doesn't exist yet, and will get extracted. The installer
might be able to set it so it is available for the remaining maven
session.
** Not really an issue, as error message is hard to misinterpret, more
an inconvenience than issue.
* All the scripts and executables within bin/ and java/ are not
executable, while they do have an executable flag within the tar file.
I assume the unzip process is not preserving the file permission
flags. Needed to add executable flag, and rerun maven plugin to
continue. This will produce issues within a CI environment.


@Petr
you wrote:
> when trying to let the cargo create the profile from scratch.
Is there a way to provide an existing profile? It looks like Cargo is
always deleting the existing one and creating a new one. If I could
create it before hand, and have Cargo use an existing one, this might
solve my issue.

I made a change to the source, to provide -profilePath. Now, instead
of failing, it never finishes ... :(


On Tue, Dec 23, 2014 at 2:53 PM, Petr Široký <[hidden email]> wrote:

> Hello Andreas,
>
>> profilePath: The profile path is not valid.
> I stumbled upon the same error  when trying to let the cargo create the
> profile from scratch. I am still not sure what is the root cause though. I
> will keep digging into this and once I have some news I will let you know.
> Or if you find a way to avoid/fix/workaround this error, please let me know
> :)
>
> Thanks,
> Petr
>
>
> On 22 December 2014 at 19:00, Andreas Tschabuschnig <[hidden email]>
> wrote:
>>
>> Before saying anything at all, I'd like to start with a huge thank you
>> to all the developers of Cargo for doing a stellar job. Within a
>> handful of days I managed to switch important parts of our integration
>> testing infrastructure from using internal tools to Cargo. At least
>> those using Tomcat and JBoss.
>>
>> The next on my list is WebSphere, and it is giving me a little bit of
>> trouble. I have been trying to start an ear file using an already
>> installed WebSphere application server, and using the ZipUrlInstaller,
>> both with the same result.
>>
>> After adding the native lib folder to the PATH variable, I'm getting
>> stuck at the profile manager, which always fails with:
>> > profilePath: The profile path is not valid.
>>
>> Looking at the debug output and the source code, I don't see how I
>> could override this value, and CARGO-147 mentions troubles with the
>> profile manager, but doesn't give much help to troubleshoot this.
>> Calling manageprofiles.sh directly produces the same result. Unless
>> -profilePath is given it fails.
>>
>> Tested on CentOS and Ubuntu server, using WebSphere 8.5.0 and 8.5.5
>>
>> Any help would be highly appreciated.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Running (into problems with) WebSphere8.5 on Linux using Cargo 1.4.11

Petr Široký
>>> Is there a way to provide an existing profile? It looks like Cargo is
>>> always deleting the existing one and creating a new one. If I could
>>> create it before hand, and have Cargo use an existing one, this might
>>> solve my issue.
Yes, there is. You can use an existing configuration for the container. See below for example (attaching the plugin configuration so it is easier to see where the config needs to go):

<plugin>
  <groupId>org.codehaus.cargo</groupId>
  <artifactId>cargo-maven2-plugin</artifactId>
  <configuration>
    <container>
      <containerId>websphere85x</containerId>
      <type>installed</type>
      <home>${was85x.home.dir}</home>
    </container>
    <configuration>
      <type>existing</type>
      <home>${was85x.home.dir}/profiles/${was85x.profile}</home>
      <properties>
        <cargo.java.home>${was85x.home.dir}/java_1.7_64</cargo.java.home>
        <cargo.jvm.args>-Xms2g -Xmx2g -XX:MaxPermSize=512m</cargo.jvm.args>
        <!--<cargo.websphere.administrator.user>websphere</cargo.websphere.administrator.user>-->
        <!--<cargo.websphere.administrator.password>websphere</cargo.websphere.administrator.password>-->
        <cargo.websphere.profile>${was85x.profile}</cargo.websphere.profile>
        <cargo.websphere.node>testing-localhostNode02</cargo.websphere.node>
        <cargo.websphere.cell>testing-localhostNode02Cell</cargo.websphere.cell>
        <cargo.websphere.server>testing-server1</cargo.websphere.server>
        <!--<cargo.websphere.classloader.mode>PARENT_LAST</cargo.websphere.classloader.mode>-->
        <!--<cargo.websphere.war.classloader.policy>SINGLE</cargo.websphere.war.classloader.policy>-->
      </properties>
    </configuration>
  </configuration>
</plugin>

HTH,
Petr

On 23 December 2014 at 18:06, Andreas Tschabuschnig <[hidden email]> wrote:
@Ali
I tried with both, an existing installation, that is known to work
with currently used proprietary tools, and a standalone installation,
using the tar.gz that was used to setup the existing installation.
The maven configuration is mostly using defaults and looking something
like this for the standalone installation:
          <plugins>
            <plugin>
                <groupId>org.codehaus.cargo</groupId>
                <artifactId>cargo-maven2-plugin</artifactId>
                <version>1.4.11</version>
                <configuration>
                    <container>
                        <containerId>websphere85x</containerId>
                        <zipUrlInstaller>

<url>file:///home/atschabu/was855-linux-x86-64.tar.gz</url>
                        </zipUrlInstaller>
                    </container>
                    <configuration>
                        <properties>
                            <cargo.servlet.port>8090</cargo.servlet.port>
                    </properties>
                </configuration>
                <deployables>
                    <deployable>
                        <pingURL>http://localhost:8090/ping</pingURL>
                        <pingTimeout>600000</pingTimeout>
                        <location>test.ear</location>
                    </deployable>
                </deployables>
            </configuration>
        </plugin>

So far I stumbled upon the following issues:
* It is necessary to add the native lib folder to the PATH variable,
even if using the ZipUrlInstaller. Which means I have to add a folder
to PATH that doesn't exist yet, and will get extracted. The installer
might be able to set it so it is available for the remaining maven
session.
** Not really an issue, as error message is hard to misinterpret, more
an inconvenience than issue.
* All the scripts and executables within bin/ and java/ are not
executable, while they do have an executable flag within the tar file.
I assume the unzip process is not preserving the file permission
flags. Needed to add executable flag, and rerun maven plugin to
continue. This will produce issues within a CI environment.


@Petr
you wrote:
> when trying to let the cargo create the profile from scratch.
Is there a way to provide an existing profile? It looks like Cargo is
always deleting the existing one and creating a new one. If I could
create it before hand, and have Cargo use an existing one, this might
solve my issue.

I made a change to the source, to provide -profilePath. Now, instead
of failing, it never finishes ... :(


On Tue, Dec 23, 2014 at 2:53 PM, Petr Široký <[hidden email]> wrote:
> Hello Andreas,
>
>> profilePath: The profile path is not valid.
> I stumbled upon the same error  when trying to let the cargo create the
> profile from scratch. I am still not sure what is the root cause though. I
> will keep digging into this and once I have some news I will let you know.
> Or if you find a way to avoid/fix/workaround this error, please let me know
> :)
>
> Thanks,
> Petr
>
>
> On 22 December 2014 at 19:00, Andreas Tschabuschnig <[hidden email]>
> wrote:
>>
>> Before saying anything at all, I'd like to start with a huge thank you
>> to all the developers of Cargo for doing a stellar job. Within a
>> handful of days I managed to switch important parts of our integration
>> testing infrastructure from using internal tools to Cargo. At least
>> those using Tomcat and JBoss.
>>
>> The next on my list is WebSphere, and it is giving me a little bit of
>> trouble. I have been trying to start an ear file using an already
>> installed WebSphere application server, and using the ZipUrlInstaller,
>> both with the same result.
>>
>> After adding the native lib folder to the PATH variable, I'm getting
>> stuck at the profile manager, which always fails with:
>> > profilePath: The profile path is not valid.
>>
>> Looking at the debug output and the source code, I don't see how I
>> could override this value, and CARGO-147 mentions troubles with the
>> profile manager, but doesn't give much help to troubleshoot this.
>> Calling manageprofiles.sh directly produces the same result. Unless
>> -profilePath is given it fails.
>>
>> Tested on CentOS and Ubuntu server, using WebSphere 8.5.0 and 8.5.5
>>
>> Any help would be highly appreciated.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Running (into problems with) WebSphere8.5 on Linux using Cargo 1.4.11

S. Ali Tokmen
Hi Andreas

Note that Petr has shown here an existing local configuration, which is what I also mainly used for my tests (in Windows):
  • In Windows, you need to install WebSphere anyway - you can't just unzip it
  • Once WebSphere is installed, your paths for the container as well as the configuration are "dictated" by the WebSphere profile name you use
I don't know if this at least helps with your setting up the proper testing configuration for WebSphere.

Thank you

S. Ali Tokmen
http://ali.tokmen.com/
http://contact.ali.tokmen.com/
On 23/12/14 19:13, Petr Široký wrote:
>>> Is there a way to provide an existing profile? It looks like Cargo is
>>> always deleting the existing one and creating a new one. If I could
>>> create it before hand, and have Cargo use an existing one, this might
>>> solve my issue.
Yes, there is. You can use an existing configuration for the container. See below for example (attaching the plugin configuration so it is easier to see where the config needs to go):

<plugin>
  <groupId>org.codehaus.cargo</groupId>
  <artifactId>cargo-maven2-plugin</artifactId>
  <configuration>
    <container>
      <containerId>websphere85x</containerId>
      <type>installed</type>
      <home>${was85x.home.dir}</home>
    </container>
    <configuration>
      <type>existing</type>
      <home>${was85x.home.dir}/profiles/${was85x.profile}</home>
      <properties>
        <cargo.java.home>${was85x.home.dir}/java_1.7_64</cargo.java.home>
        <cargo.jvm.args>-Xms2g -Xmx2g -XX:MaxPermSize=512m</cargo.jvm.args>
        <!--<cargo.websphere.administrator.user>websphere</cargo.websphere.administrator.user>-->
        <!--<cargo.websphere.administrator.password>websphere</cargo.websphere.administrator.password>-->
        <cargo.websphere.profile>${was85x.profile}</cargo.websphere.profile>
        <cargo.websphere.node>testing-localhostNode02</cargo.websphere.node>
        <cargo.websphere.cell>testing-localhostNode02Cell</cargo.websphere.cell>
        <cargo.websphere.server>testing-server1</cargo.websphere.server>
        <!--<cargo.websphere.classloader.mode>PARENT_LAST</cargo.websphere.classloader.mode>-->
        <!--<cargo.websphere.war.classloader.policy>SINGLE</cargo.websphere.war.classloader.policy>-->
      </properties>
    </configuration>
  </configuration>
</plugin>

HTH,
Petr

On 23 December 2014 at 18:06, Andreas Tschabuschnig <[hidden email]> wrote:
@Ali
I tried with both, an existing installation, that is known to work
with currently used proprietary tools, and a standalone installation,
using the tar.gz that was used to setup the existing installation.
The maven configuration is mostly using defaults and looking something
like this for the standalone installation:
          <plugins>
            <plugin>
                <groupId>org.codehaus.cargo</groupId>
                <artifactId>cargo-maven2-plugin</artifactId>
                <version>1.4.11</version>
                <configuration>
                    <container>
                        <containerId>websphere85x</containerId>
                        <zipUrlInstaller>

<url>file:///home/atschabu/was855-linux-x86-64.tar.gz</url>
                        </zipUrlInstaller>
                    </container>
                    <configuration>
                        <properties>
                            <cargo.servlet.port>8090</cargo.servlet.port>
                    </properties>
                </configuration>
                <deployables>
                    <deployable>
                        <pingURL>http://localhost:8090/ping</pingURL>
                        <pingTimeout>600000</pingTimeout>
                        <location>test.ear</location>
                    </deployable>
                </deployables>
            </configuration>
        </plugin>

So far I stumbled upon the following issues:
* It is necessary to add the native lib folder to the PATH variable,
even if using the ZipUrlInstaller. Which means I have to add a folder
to PATH that doesn't exist yet, and will get extracted. The installer
might be able to set it so it is available for the remaining maven
session.
** Not really an issue, as error message is hard to misinterpret, more
an inconvenience than issue.
* All the scripts and executables within bin/ and java/ are not
executable, while they do have an executable flag within the tar file.
I assume the unzip process is not preserving the file permission
flags. Needed to add executable flag, and rerun maven plugin to
continue. This will produce issues within a CI environment.


@Petr
you wrote:
> when trying to let the cargo create the profile from scratch.
Is there a way to provide an existing profile? It looks like Cargo is
always deleting the existing one and creating a new one. If I could
create it before hand, and have Cargo use an existing one, this might
solve my issue.

I made a change to the source, to provide -profilePath. Now, instead
of failing, it never finishes ... :(


On Tue, Dec 23, 2014 at 2:53 PM, Petr Široký <[hidden email]> wrote:
> Hello Andreas,
>
>> profilePath: The profile path is not valid.
> I stumbled upon the same error  when trying to let the cargo create the
> profile from scratch. I am still not sure what is the root cause though. I
> will keep digging into this and once I have some news I will let you know.
> Or if you find a way to avoid/fix/workaround this error, please let me know
> :)
>
> Thanks,
> Petr
>
>
> On 22 December 2014 at 19:00, Andreas Tschabuschnig <[hidden email]>
> wrote:
>>
>> Before saying anything at all, I'd like to start with a huge thank you
>> to all the developers of Cargo for doing a stellar job. Within a
>> handful of days I managed to switch important parts of our integration
>> testing infrastructure from using internal tools to Cargo. At least
>> those using Tomcat and JBoss.
>>
>> The next on my list is WebSphere, and it is giving me a little bit of
>> trouble. I have been trying to start an ear file using an already
>> installed WebSphere application server, and using the ZipUrlInstaller,
>> both with the same result.
>>
>> After adding the native lib folder to the PATH variable, I'm getting
>> stuck at the profile manager, which always fails with:
>> > profilePath: The profile path is not valid.
>>
>> Looking at the debug output and the source code, I don't see how I
>> could override this value, and CARGO-147 mentions troubles with the
>> profile manager, but doesn't give much help to troubleshoot this.
>> Calling manageprofiles.sh directly produces the same result. Unless
>> -profilePath is given it fails.
>>
>> Tested on CentOS and Ubuntu server, using WebSphere 8.5.0 and 8.5.5
>>
>> Any help would be highly appreciated.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




Reply | Threaded
Open this post in threaded view
|

Re: Running (into problems with) WebSphere8.5 on Linux using Cargo 1.4.11

Andreas Tschabuschnig
Hi Ali and Petr,

I didn't realize there was a <type> for <configuration> as well ... I
guess that is a classic issue of RTFM, which was most likely caused by
me getting spoiled by how easy JBoss and Tomcat got configured with
defaults ;)

Now ... using a pre-installed Websphere 8.5.5 on a CentOS box, I
successfully created a profile (using Cargo's default values to reduce
clutter in the pom file):
    bin/manageprofiles.sh -create -profileName cargoProfile -nodeName
cargoNode -cellName cargoNodeCell -serverName cargoServer
-winserviceCheck false -enableService false -portsFile
/tmp/portdef.props

Using the <type = existing> and <home> pointing to the profile
directory I got one step further, namely an OutOfMemoryError in the
maven plugin, which was solved by setting memory options in MAVEN_OPTS
to a whopping 3GiB. Note that the .ear file to be deployed has about
400MiB.

Caused by: java.lang.OutOfMemoryError: Java heap space
  at java.util.Arrays.copyOf(Arrays.java:2271)
  at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:113)
  at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
  at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:140)
  at org.codehaus.cargo.module.DefaultJarArchive.streamToByteArray(DefaultJarArchive.java:304)
  at org.codehaus.cargo.module.DefaultJarArchive.<init>(DefaultJarArchive.java:87)
  at org.codehaus.cargo.module.webapp.DefaultWarArchive.<init>(DefaultWarArchive.java:89)
  at org.codehaus.cargo.module.application.DefaultEarArchive.getWebModule(DefaultEarArchive.java:104)
  at org.codehaus.cargo.container.websphere.WebSphere85xInstalledLocalDeployer.deploy(WebSphere85xInstalledLocalDeployer.java:125)
  at org.codehaus.cargo.container.spi.deployer.AbstractDeployer.redeploy(AbstractDeployer.java:234)
  at org.codehaus.cargo.container.websphere.WebSphere85xInstalledLocalContainer.doStart(WebSphere85xInstalledLocalContainer.java:116)
  at org.codehaus.cargo.container.spi.AbstractInstalledLocalContainer.startInternal(AbstractInstalledLocalContainer.java:294)
  at org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:225)
  at org.codehaus.cargo.maven2.ContainerStartMojo.executeLocalContainerAction(ContainerStartMojo.java:96)
  at org.codehaus.cargo.maven2.ContainerStartMojo.doExecute(ContainerStartMojo.java:63)
  at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:432)
  at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
  at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
...

After increasing mavens memory (and that of my server profile) I
successfully deployed my ear file on WebSphere! Unfortunately it
doesn't stop the server automatically. Unlike the other containers I
tested, which shut down the application server before finishing Maven,
WebSphere was still running, and my application was still available.
Calling goal 'stop' did the trick, but is slightly inconsistent with
Cargo's documentation and expected behavior.

To summarize ...
Prerequisites:
* Install WebSphere 8.5.x
* Add the native lib folder to the PATH variable
* Create profile
* Optional: increase memory options in server.xml
* Optional: increase memory for Maven
* Workaround CARGO-1285: configure them in server.xml
* Workaround: call 'mvn org.codehaus.cargo:cargo-maven2-plugin:stop'
to stop server

Using Petr's plugin configuration, with <cargo.websphere.x> variables
set according to existing profile, the server started.

I'm not quite clear though, what effect the configuration properties
'cargo.jvm.args' and 'cargo.servlet.port' have for WebSphere, as both
are currently configured within the profile. Will those be enabled as
part of CARGO-1285?

On Fri, Dec 26, 2014 at 8:58 AM, S. Ali Tokmen <[hidden email]> wrote:

> Hi Andreas
>
> Note that Petr has shown here an existing local configuration, which is what
> I also mainly used for my tests (in Windows):
>
> In Windows, you need to install WebSphere anyway - you can't just unzip it
> Once WebSphere is installed, your paths for the container as well as the
> configuration are "dictated" by the WebSphere profile name you use
>
> I don't know if this at least helps with your setting up the proper testing
> configuration for WebSphere.
>
> Thank you
>
> S. Ali Tokmen
> http://ali.tokmen.com/
> http://contact.ali.tokmen.com/
>
> On 23/12/14 19:13, Petr Široký wrote:
>
>>>> Is there a way to provide an existing profile? It looks like Cargo is
>>>> always deleting the existing one and creating a new one. If I could
>>>> create it before hand, and have Cargo use an existing one, this might
>>>> solve my issue.
> Yes, there is. You can use an existing configuration for the container. See
> below for example (attaching the plugin configuration so it is easier to see
> where the config needs to go):
>
> <plugin>
>   <groupId>org.codehaus.cargo</groupId>
>   <artifactId>cargo-maven2-plugin</artifactId>
>   <configuration>
>     <container>
>       <containerId>websphere85x</containerId>
>       <type>installed</type>
>       <home>${was85x.home.dir}</home>
>     </container>
>     <configuration>
>       <type>existing</type>
>       <home>${was85x.home.dir}/profiles/${was85x.profile}</home>
>       <properties>
>         <cargo.java.home>${was85x.home.dir}/java_1.7_64</cargo.java.home>
>         <cargo.jvm.args>-Xms2g -Xmx2g -XX:MaxPermSize=512m</cargo.jvm.args>
>
> <!--<cargo.websphere.administrator.user>websphere</cargo.websphere.administrator.user>-->
>
> <!--<cargo.websphere.administrator.password>websphere</cargo.websphere.administrator.password>-->
>         <cargo.websphere.profile>${was85x.profile}</cargo.websphere.profile>
>         <cargo.websphere.node>testing-localhostNode02</cargo.websphere.node>
>
> <cargo.websphere.cell>testing-localhostNode02Cell</cargo.websphere.cell>
>         <cargo.websphere.server>testing-server1</cargo.websphere.server>
>
> <!--<cargo.websphere.classloader.mode>PARENT_LAST</cargo.websphere.classloader.mode>-->
>
> <!--<cargo.websphere.war.classloader.policy>SINGLE</cargo.websphere.war.classloader.policy>-->
>       </properties>
>     </configuration>
>   </configuration>
> </plugin>
>
> HTH,
> Petr
>
> On 23 December 2014 at 18:06, Andreas Tschabuschnig <[hidden email]>
> wrote:
>>
>> @Ali
>> I tried with both, an existing installation, that is known to work
>> with currently used proprietary tools, and a standalone installation,
>> using the tar.gz that was used to setup the existing installation.
>> The maven configuration is mostly using defaults and looking something
>> like this for the standalone installation:
>>           <plugins>
>>             <plugin>
>>                 <groupId>org.codehaus.cargo</groupId>
>>                 <artifactId>cargo-maven2-plugin</artifactId>
>>                 <version>1.4.11</version>
>>                 <configuration>
>>                     <container>
>>                         <containerId>websphere85x</containerId>
>>                         <zipUrlInstaller>
>>
>> <url>file:///home/atschabu/was855-linux-x86-64.tar.gz</url>
>>                         </zipUrlInstaller>
>>                     </container>
>>                     <configuration>
>>                         <properties>
>>                             <cargo.servlet.port>8090</cargo.servlet.port>
>>                     </properties>
>>                 </configuration>
>>                 <deployables>
>>                     <deployable>
>>                         <pingURL>http://localhost:8090/ping</pingURL>
>>                         <pingTimeout>600000</pingTimeout>
>>                         <location>test.ear</location>
>>                     </deployable>
>>                 </deployables>
>>             </configuration>
>>         </plugin>
>>
>> So far I stumbled upon the following issues:
>> * It is necessary to add the native lib folder to the PATH variable,
>> even if using the ZipUrlInstaller. Which means I have to add a folder
>> to PATH that doesn't exist yet, and will get extracted. The installer
>> might be able to set it so it is available for the remaining maven
>> session.
>> ** Not really an issue, as error message is hard to misinterpret, more
>> an inconvenience than issue.
>> * All the scripts and executables within bin/ and java/ are not
>> executable, while they do have an executable flag within the tar file.
>> I assume the unzip process is not preserving the file permission
>> flags. Needed to add executable flag, and rerun maven plugin to
>> continue. This will produce issues within a CI environment.
>>
>>
>> @Petr
>> you wrote:
>> > when trying to let the cargo create the profile from scratch.
>> Is there a way to provide an existing profile? It looks like Cargo is
>> always deleting the existing one and creating a new one. If I could
>> create it before hand, and have Cargo use an existing one, this might
>> solve my issue.
>>
>> I made a change to the source, to provide -profilePath. Now, instead
>> of failing, it never finishes ... :(
>>
>>
>> On Tue, Dec 23, 2014 at 2:53 PM, Petr Široký <[hidden email]>
>> wrote:
>> > Hello Andreas,
>> >
>> >> profilePath: The profile path is not valid.
>> > I stumbled upon the same error  when trying to let the cargo create the
>> > profile from scratch. I am still not sure what is the root cause though.
>> > I
>> > will keep digging into this and once I have some news I will let you
>> > know.
>> > Or if you find a way to avoid/fix/workaround this error, please let me
>> > know
>> > :)
>> >
>> > Thanks,
>> > Petr
>> >
>> >
>> > On 22 December 2014 at 19:00, Andreas Tschabuschnig <[hidden email]>
>> > wrote:
>> >>
>> >> Before saying anything at all, I'd like to start with a huge thank you
>> >> to all the developers of Cargo for doing a stellar job. Within a
>> >> handful of days I managed to switch important parts of our integration
>> >> testing infrastructure from using internal tools to Cargo. At least
>> >> those using Tomcat and JBoss.
>> >>
>> >> The next on my list is WebSphere, and it is giving me a little bit of
>> >> trouble. I have been trying to start an ear file using an already
>> >> installed WebSphere application server, and using the ZipUrlInstaller,
>> >> both with the same result.
>> >>
>> >> After adding the native lib folder to the PATH variable, I'm getting
>> >> stuck at the profile manager, which always fails with:
>> >> > profilePath: The profile path is not valid.
>> >>
>> >> Looking at the debug output and the source code, I don't see how I
>> >> could override this value, and CARGO-147 mentions troubles with the
>> >> profile manager, but doesn't give much help to troubleshoot this.
>> >> Calling manageprofiles.sh directly produces the same result. Unless
>> >> -profilePath is given it fails.
>> >>
>> >> Tested on CentOS and Ubuntu server, using WebSphere 8.5.0 and 8.5.5
>> >>
>> >> Any help would be highly appreciated.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe from this list, please visit:
>> >>
>> >>     http://xircles.codehaus.org/manage_email
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Running (into problems with) WebSphere8.5 on Linux using Cargo 1.4.11

S. Ali Tokmen
Hi Andreas

We're glad you made it :) Indeed, the WebSphere container of CARGO is
probably the hardest to use; be it for installing and configuring. I've
updated http://cargo.codehaus.org/WebSphere+8.5.x with your experience -
so more people are aware of what to do and not do.

CARGO-1285 indeed tries to cover setting properties such as
cargo.jvm.args or cargo.servlet.port for an existing configuration. On
the other hand, please remember that these are properties you can
specify when creating the WebSphere profile using  WebSphere's
configuration commands.

As for the stop bug, can you please tell us how you start the container?
Perhaps there is something we forgot - as indeed that works well with
all other containers.

Thank you

S. Ali Tokmen
http://ali.tokmen.com/
http://contact.ali.tokmen.com/

On 29/12/14 20:44, Andreas Tschabuschnig wrote:

> Hi Ali and Petr,
>
> I didn't realize there was a <type> for <configuration> as well ... I
> guess that is a classic issue of RTFM, which was most likely caused by
> me getting spoiled by how easy JBoss and Tomcat got configured with
> defaults ;)
>
> Now ... using a pre-installed Websphere 8.5.5 on a CentOS box, I
> successfully created a profile (using Cargo's default values to reduce
> clutter in the pom file):
>     bin/manageprofiles.sh -create -profileName cargoProfile -nodeName
> cargoNode -cellName cargoNodeCell -serverName cargoServer
> -winserviceCheck false -enableService false -portsFile
> /tmp/portdef.props
>
> Using the <type = existing> and <home> pointing to the profile
> directory I got one step further, namely an OutOfMemoryError in the
> maven plugin, which was solved by setting memory options in MAVEN_OPTS
> to a whopping 3GiB. Note that the .ear file to be deployed has about
> 400MiB.
>
> Caused by: java.lang.OutOfMemoryError: Java heap space
>   at java.util.Arrays.copyOf(Arrays.java:2271)
>   at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:113)
>   at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
>   at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:140)
>   at org.codehaus.cargo.module.DefaultJarArchive.streamToByteArray(DefaultJarArchive.java:304)
>   at org.codehaus.cargo.module.DefaultJarArchive.<init>(DefaultJarArchive.java:87)
>   at org.codehaus.cargo.module.webapp.DefaultWarArchive.<init>(DefaultWarArchive.java:89)
>   at org.codehaus.cargo.module.application.DefaultEarArchive.getWebModule(DefaultEarArchive.java:104)
>   at org.codehaus.cargo.container.websphere.WebSphere85xInstalledLocalDeployer.deploy(WebSphere85xInstalledLocalDeployer.java:125)
>   at org.codehaus.cargo.container.spi.deployer.AbstractDeployer.redeploy(AbstractDeployer.java:234)
>   at org.codehaus.cargo.container.websphere.WebSphere85xInstalledLocalContainer.doStart(WebSphere85xInstalledLocalContainer.java:116)
>   at org.codehaus.cargo.container.spi.AbstractInstalledLocalContainer.startInternal(AbstractInstalledLocalContainer.java:294)
>   at org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:225)
>   at org.codehaus.cargo.maven2.ContainerStartMojo.executeLocalContainerAction(ContainerStartMojo.java:96)
>   at org.codehaus.cargo.maven2.ContainerStartMojo.doExecute(ContainerStartMojo.java:63)
>   at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:432)
>   at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>   at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ...
>
> After increasing mavens memory (and that of my server profile) I
> successfully deployed my ear file on WebSphere! Unfortunately it
> doesn't stop the server automatically. Unlike the other containers I
> tested, which shut down the application server before finishing Maven,
> WebSphere was still running, and my application was still available.
> Calling goal 'stop' did the trick, but is slightly inconsistent with
> Cargo's documentation and expected behavior.
>
> To summarize ...
> Prerequisites:
> * Install WebSphere 8.5.x
> * Add the native lib folder to the PATH variable
> * Create profile
> * Optional: increase memory options in server.xml
> * Optional: increase memory for Maven
> * Workaround CARGO-1285: configure them in server.xml
> * Workaround: call 'mvn org.codehaus.cargo:cargo-maven2-plugin:stop'
> to stop server
>
> Using Petr's plugin configuration, with <cargo.websphere.x> variables
> set according to existing profile, the server started.
>
> I'm not quite clear though, what effect the configuration properties
> 'cargo.jvm.args' and 'cargo.servlet.port' have for WebSphere, as both
> are currently configured within the profile. Will those be enabled as
> part of CARGO-1285?
>
> On Fri, Dec 26, 2014 at 8:58 AM, S. Ali Tokmen <[hidden email]> wrote:
>> Hi Andreas
>>
>> Note that Petr has shown here an existing local configuration, which is what
>> I also mainly used for my tests (in Windows):
>>
>> In Windows, you need to install WebSphere anyway - you can't just unzip it
>> Once WebSphere is installed, your paths for the container as well as the
>> configuration are "dictated" by the WebSphere profile name you use
>>
>> I don't know if this at least helps with your setting up the proper testing
>> configuration for WebSphere.
>>
>> Thank you
>>
>> S. Ali Tokmen
>> http://ali.tokmen.com/
>> http://contact.ali.tokmen.com/
>>
>> On 23/12/14 19:13, Petr Široký wrote:
>>
>>>>> Is there a way to provide an existing profile? It looks like Cargo is
>>>>> always deleting the existing one and creating a new one. If I could
>>>>> create it before hand, and have Cargo use an existing one, this might
>>>>> solve my issue.
>> Yes, there is. You can use an existing configuration for the container. See
>> below for example (attaching the plugin configuration so it is easier to see
>> where the config needs to go):
>>
>> <plugin>
>>   <groupId>org.codehaus.cargo</groupId>
>>   <artifactId>cargo-maven2-plugin</artifactId>
>>   <configuration>
>>     <container>
>>       <containerId>websphere85x</containerId>
>>       <type>installed</type>
>>       <home>${was85x.home.dir}</home>
>>     </container>
>>     <configuration>
>>       <type>existing</type>
>>       <home>${was85x.home.dir}/profiles/${was85x.profile}</home>
>>       <properties>
>>         <cargo.java.home>${was85x.home.dir}/java_1.7_64</cargo.java.home>
>>         <cargo.jvm.args>-Xms2g -Xmx2g -XX:MaxPermSize=512m</cargo.jvm.args>
>>
>> <!--<cargo.websphere.administrator.user>websphere</cargo.websphere.administrator.user>-->
>>
>> <!--<cargo.websphere.administrator.password>websphere</cargo.websphere.administrator.password>-->
>>         <cargo.websphere.profile>${was85x.profile}</cargo.websphere.profile>
>>         <cargo.websphere.node>testing-localhostNode02</cargo.websphere.node>
>>
>> <cargo.websphere.cell>testing-localhostNode02Cell</cargo.websphere.cell>
>>         <cargo.websphere.server>testing-server1</cargo.websphere.server>
>>
>> <!--<cargo.websphere.classloader.mode>PARENT_LAST</cargo.websphere.classloader.mode>-->
>>
>> <!--<cargo.websphere.war.classloader.policy>SINGLE</cargo.websphere.war.classloader.policy>-->
>>       </properties>
>>     </configuration>
>>   </configuration>
>> </plugin>
>>
>> HTH,
>> Petr
>>
>> On 23 December 2014 at 18:06, Andreas Tschabuschnig <[hidden email]>
>> wrote:
>>> @Ali
>>> I tried with both, an existing installation, that is known to work
>>> with currently used proprietary tools, and a standalone installation,
>>> using the tar.gz that was used to setup the existing installation.
>>> The maven configuration is mostly using defaults and looking something
>>> like this for the standalone installation:
>>>           <plugins>
>>>             <plugin>
>>>                 <groupId>org.codehaus.cargo</groupId>
>>>                 <artifactId>cargo-maven2-plugin</artifactId>
>>>                 <version>1.4.11</version>
>>>                 <configuration>
>>>                     <container>
>>>                         <containerId>websphere85x</containerId>
>>>                         <zipUrlInstaller>
>>>
>>> <url>file:///home/atschabu/was855-linux-x86-64.tar.gz</url>
>>>                         </zipUrlInstaller>
>>>                     </container>
>>>                     <configuration>
>>>                         <properties>
>>>                             <cargo.servlet.port>8090</cargo.servlet.port>
>>>                     </properties>
>>>                 </configuration>
>>>                 <deployables>
>>>                     <deployable>
>>>                         <pingURL>http://localhost:8090/ping</pingURL>
>>>                         <pingTimeout>600000</pingTimeout>
>>>                         <location>test.ear</location>
>>>                     </deployable>
>>>                 </deployables>
>>>             </configuration>
>>>         </plugin>
>>>
>>> So far I stumbled upon the following issues:
>>> * It is necessary to add the native lib folder to the PATH variable,
>>> even if using the ZipUrlInstaller. Which means I have to add a folder
>>> to PATH that doesn't exist yet, and will get extracted. The installer
>>> might be able to set it so it is available for the remaining maven
>>> session.
>>> ** Not really an issue, as error message is hard to misinterpret, more
>>> an inconvenience than issue.
>>> * All the scripts and executables within bin/ and java/ are not
>>> executable, while they do have an executable flag within the tar file.
>>> I assume the unzip process is not preserving the file permission
>>> flags. Needed to add executable flag, and rerun maven plugin to
>>> continue. This will produce issues within a CI environment.
>>>
>>>
>>> @Petr
>>> you wrote:
>>>> when trying to let the cargo create the profile from scratch.
>>> Is there a way to provide an existing profile? It looks like Cargo is
>>> always deleting the existing one and creating a new one. If I could
>>> create it before hand, and have Cargo use an existing one, this might
>>> solve my issue.
>>>
>>> I made a change to the source, to provide -profilePath. Now, instead
>>> of failing, it never finishes ... :(
>>>
>>>
>>> On Tue, Dec 23, 2014 at 2:53 PM, Petr Široký <[hidden email]>
>>> wrote:
>>>> Hello Andreas,
>>>>
>>>>> profilePath: The profile path is not valid.
>>>> I stumbled upon the same error  when trying to let the cargo create the
>>>> profile from scratch. I am still not sure what is the root cause though.
>>>> I
>>>> will keep digging into this and once I have some news I will let you
>>>> know.
>>>> Or if you find a way to avoid/fix/workaround this error, please let me
>>>> know
>>>> :)
>>>>
>>>> Thanks,
>>>> Petr
>>>>
>>>>
>>>> On 22 December 2014 at 19:00, Andreas Tschabuschnig <[hidden email]>
>>>> wrote:
>>>>> Before saying anything at all, I'd like to start with a huge thank you
>>>>> to all the developers of Cargo for doing a stellar job. Within a
>>>>> handful of days I managed to switch important parts of our integration
>>>>> testing infrastructure from using internal tools to Cargo. At least
>>>>> those using Tomcat and JBoss.
>>>>>
>>>>> The next on my list is WebSphere, and it is giving me a little bit of
>>>>> trouble. I have been trying to start an ear file using an already
>>>>> installed WebSphere application server, and using the ZipUrlInstaller,
>>>>> both with the same result.
>>>>>
>>>>> After adding the native lib folder to the PATH variable, I'm getting
>>>>> stuck at the profile manager, which always fails with:
>>>>>> profilePath: The profile path is not valid.
>>>>> Looking at the debug output and the source code, I don't see how I
>>>>> could override this value, and CARGO-147 mentions troubles with the
>>>>> profile manager, but doesn't give much help to troubleshoot this.
>>>>> Calling manageprofiles.sh directly produces the same result. Unless
>>>>> -profilePath is given it fails.
>>>>>
>>>>> Tested on CentOS and Ubuntu server, using WebSphere 8.5.0 and 8.5.5
>>>>>
>>>>> Any help would be highly appreciated.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>>     http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>     http://xircles.codehaus.org/manage_email
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Running (into problems with) WebSphere8.5 on Linux using Cargo 1.4.11

Andreas Tschabuschnig
Thanks for the great support, I didn't expect to be able to accomplish
this in such short time.

Concerning the stop bug, I'm calling
    mvn org.codehaus.cargo:cargo-maven2-plugin:start
org.codehaus.mojo:exec-maven-plugin:exec
where the exec goal calls a shell script that initiates the
integration tests and returns once finished. At this point my Maven
build finishes, but WebSphere stays alive and kicking. So I also call
    mvn org.codehaus.cargo:cargo-maven2-plugin:stop
when running WebSphere based builds, which seems to be working nicely.

Concerning properties, I'm still figuring out how to nicely automate
it, but I guess I just make a call to the WSAdmin thingy, while
CARGO-1285 is unresolved. Everything works now, it is just a matter of
making it 'nicer'.

Concerning documentation, it might be worth adding the additional
properties added by CARGO-1284 as well, which are kind of hidden
within the JavaDoc right now.

On Tue, Dec 30, 2014 at 11:13 AM, S. Ali Tokmen <[hidden email]> wrote:

> Hi Andreas
>
> We're glad you made it :) Indeed, the WebSphere container of CARGO is
> probably the hardest to use; be it for installing and configuring. I've
> updated http://cargo.codehaus.org/WebSphere+8.5.x with your experience -
> so more people are aware of what to do and not do.
>
> CARGO-1285 indeed tries to cover setting properties such as
> cargo.jvm.args or cargo.servlet.port for an existing configuration. On
> the other hand, please remember that these are properties you can
> specify when creating the WebSphere profile using  WebSphere's
> configuration commands.
>
> As for the stop bug, can you please tell us how you start the container?
> Perhaps there is something we forgot - as indeed that works well with
> all other containers.
>
> Thank you
>
> S. Ali Tokmen
> http://ali.tokmen.com/
> http://contact.ali.tokmen.com/
>
> On 29/12/14 20:44, Andreas Tschabuschnig wrote:
>> Hi Ali and Petr,
>>
>> I didn't realize there was a <type> for <configuration> as well ... I
>> guess that is a classic issue of RTFM, which was most likely caused by
>> me getting spoiled by how easy JBoss and Tomcat got configured with
>> defaults ;)
>>
>> Now ... using a pre-installed Websphere 8.5.5 on a CentOS box, I
>> successfully created a profile (using Cargo's default values to reduce
>> clutter in the pom file):
>>     bin/manageprofiles.sh -create -profileName cargoProfile -nodeName
>> cargoNode -cellName cargoNodeCell -serverName cargoServer
>> -winserviceCheck false -enableService false -portsFile
>> /tmp/portdef.props
>>
>> Using the <type = existing> and <home> pointing to the profile
>> directory I got one step further, namely an OutOfMemoryError in the
>> maven plugin, which was solved by setting memory options in MAVEN_OPTS
>> to a whopping 3GiB. Note that the .ear file to be deployed has about
>> 400MiB.
>>
>> Caused by: java.lang.OutOfMemoryError: Java heap space
>>   at java.util.Arrays.copyOf(Arrays.java:2271)
>>   at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:113)
>>   at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
>>   at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:140)
>>   at org.codehaus.cargo.module.DefaultJarArchive.streamToByteArray(DefaultJarArchive.java:304)
>>   at org.codehaus.cargo.module.DefaultJarArchive.<init>(DefaultJarArchive.java:87)
>>   at org.codehaus.cargo.module.webapp.DefaultWarArchive.<init>(DefaultWarArchive.java:89)
>>   at org.codehaus.cargo.module.application.DefaultEarArchive.getWebModule(DefaultEarArchive.java:104)
>>   at org.codehaus.cargo.container.websphere.WebSphere85xInstalledLocalDeployer.deploy(WebSphere85xInstalledLocalDeployer.java:125)
>>   at org.codehaus.cargo.container.spi.deployer.AbstractDeployer.redeploy(AbstractDeployer.java:234)
>>   at org.codehaus.cargo.container.websphere.WebSphere85xInstalledLocalContainer.doStart(WebSphere85xInstalledLocalContainer.java:116)
>>   at org.codehaus.cargo.container.spi.AbstractInstalledLocalContainer.startInternal(AbstractInstalledLocalContainer.java:294)
>>   at org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:225)
>>   at org.codehaus.cargo.maven2.ContainerStartMojo.executeLocalContainerAction(ContainerStartMojo.java:96)
>>   at org.codehaus.cargo.maven2.ContainerStartMojo.doExecute(ContainerStartMojo.java:63)
>>   at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:432)
>>   at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>>   at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>> ...
>>
>> After increasing mavens memory (and that of my server profile) I
>> successfully deployed my ear file on WebSphere! Unfortunately it
>> doesn't stop the server automatically. Unlike the other containers I
>> tested, which shut down the application server before finishing Maven,
>> WebSphere was still running, and my application was still available.
>> Calling goal 'stop' did the trick, but is slightly inconsistent with
>> Cargo's documentation and expected behavior.
>>
>> To summarize ...
>> Prerequisites:
>> * Install WebSphere 8.5.x
>> * Add the native lib folder to the PATH variable
>> * Create profile
>> * Optional: increase memory options in server.xml
>> * Optional: increase memory for Maven
>> * Workaround CARGO-1285: configure them in server.xml
>> * Workaround: call 'mvn org.codehaus.cargo:cargo-maven2-plugin:stop'
>> to stop server
>>
>> Using Petr's plugin configuration, with <cargo.websphere.x> variables
>> set according to existing profile, the server started.
>>
>> I'm not quite clear though, what effect the configuration properties
>> 'cargo.jvm.args' and 'cargo.servlet.port' have for WebSphere, as both
>> are currently configured within the profile. Will those be enabled as
>> part of CARGO-1285?
>>
>> On Fri, Dec 26, 2014 at 8:58 AM, S. Ali Tokmen <[hidden email]> wrote:
>>> Hi Andreas
>>>
>>> Note that Petr has shown here an existing local configuration, which is what
>>> I also mainly used for my tests (in Windows):
>>>
>>> In Windows, you need to install WebSphere anyway - you can't just unzip it
>>> Once WebSphere is installed, your paths for the container as well as the
>>> configuration are "dictated" by the WebSphere profile name you use
>>>
>>> I don't know if this at least helps with your setting up the proper testing
>>> configuration for WebSphere.
>>>
>>> Thank you
>>>
>>> S. Ali Tokmen
>>> http://ali.tokmen.com/
>>> http://contact.ali.tokmen.com/
>>>
>>> On 23/12/14 19:13, Petr Široký wrote:
>>>
>>>>>> Is there a way to provide an existing profile? It looks like Cargo is
>>>>>> always deleting the existing one and creating a new one. If I could
>>>>>> create it before hand, and have Cargo use an existing one, this might
>>>>>> solve my issue.
>>> Yes, there is. You can use an existing configuration for the container. See
>>> below for example (attaching the plugin configuration so it is easier to see
>>> where the config needs to go):
>>>
>>> <plugin>
>>>   <groupId>org.codehaus.cargo</groupId>
>>>   <artifactId>cargo-maven2-plugin</artifactId>
>>>   <configuration>
>>>     <container>
>>>       <containerId>websphere85x</containerId>
>>>       <type>installed</type>
>>>       <home>${was85x.home.dir}</home>
>>>     </container>
>>>     <configuration>
>>>       <type>existing</type>
>>>       <home>${was85x.home.dir}/profiles/${was85x.profile}</home>
>>>       <properties>
>>>         <cargo.java.home>${was85x.home.dir}/java_1.7_64</cargo.java.home>
>>>         <cargo.jvm.args>-Xms2g -Xmx2g -XX:MaxPermSize=512m</cargo.jvm.args>
>>>
>>> <!--<cargo.websphere.administrator.user>websphere</cargo.websphere.administrator.user>-->
>>>
>>> <!--<cargo.websphere.administrator.password>websphere</cargo.websphere.administrator.password>-->
>>>         <cargo.websphere.profile>${was85x.profile}</cargo.websphere.profile>
>>>         <cargo.websphere.node>testing-localhostNode02</cargo.websphere.node>
>>>
>>> <cargo.websphere.cell>testing-localhostNode02Cell</cargo.websphere.cell>
>>>         <cargo.websphere.server>testing-server1</cargo.websphere.server>
>>>
>>> <!--<cargo.websphere.classloader.mode>PARENT_LAST</cargo.websphere.classloader.mode>-->
>>>
>>> <!--<cargo.websphere.war.classloader.policy>SINGLE</cargo.websphere.war.classloader.policy>-->
>>>       </properties>
>>>     </configuration>
>>>   </configuration>
>>> </plugin>
>>>
>>> HTH,
>>> Petr
>>>
>>> On 23 December 2014 at 18:06, Andreas Tschabuschnig <[hidden email]>
>>> wrote:
>>>> @Ali
>>>> I tried with both, an existing installation, that is known to work
>>>> with currently used proprietary tools, and a standalone installation,
>>>> using the tar.gz that was used to setup the existing installation.
>>>> The maven configuration is mostly using defaults and looking something
>>>> like this for the standalone installation:
>>>>           <plugins>
>>>>             <plugin>
>>>>                 <groupId>org.codehaus.cargo</groupId>
>>>>                 <artifactId>cargo-maven2-plugin</artifactId>
>>>>                 <version>1.4.11</version>
>>>>                 <configuration>
>>>>                     <container>
>>>>                         <containerId>websphere85x</containerId>
>>>>                         <zipUrlInstaller>
>>>>
>>>> <url>file:///home/atschabu/was855-linux-x86-64.tar.gz</url>
>>>>                         </zipUrlInstaller>
>>>>                     </container>
>>>>                     <configuration>
>>>>                         <properties>
>>>>                             <cargo.servlet.port>8090</cargo.servlet.port>
>>>>                     </properties>
>>>>                 </configuration>
>>>>                 <deployables>
>>>>                     <deployable>
>>>>                         <pingURL>http://localhost:8090/ping</pingURL>
>>>>                         <pingTimeout>600000</pingTimeout>
>>>>                         <location>test.ear</location>
>>>>                     </deployable>
>>>>                 </deployables>
>>>>             </configuration>
>>>>         </plugin>
>>>>
>>>> So far I stumbled upon the following issues:
>>>> * It is necessary to add the native lib folder to the PATH variable,
>>>> even if using the ZipUrlInstaller. Which means I have to add a folder
>>>> to PATH that doesn't exist yet, and will get extracted. The installer
>>>> might be able to set it so it is available for the remaining maven
>>>> session.
>>>> ** Not really an issue, as error message is hard to misinterpret, more
>>>> an inconvenience than issue.
>>>> * All the scripts and executables within bin/ and java/ are not
>>>> executable, while they do have an executable flag within the tar file.
>>>> I assume the unzip process is not preserving the file permission
>>>> flags. Needed to add executable flag, and rerun maven plugin to
>>>> continue. This will produce issues within a CI environment.
>>>>
>>>>
>>>> @Petr
>>>> you wrote:
>>>>> when trying to let the cargo create the profile from scratch.
>>>> Is there a way to provide an existing profile? It looks like Cargo is
>>>> always deleting the existing one and creating a new one. If I could
>>>> create it before hand, and have Cargo use an existing one, this might
>>>> solve my issue.
>>>>
>>>> I made a change to the source, to provide -profilePath. Now, instead
>>>> of failing, it never finishes ... :(
>>>>
>>>>
>>>> On Tue, Dec 23, 2014 at 2:53 PM, Petr Široký <[hidden email]>
>>>> wrote:
>>>>> Hello Andreas,
>>>>>
>>>>>> profilePath: The profile path is not valid.
>>>>> I stumbled upon the same error  when trying to let the cargo create the
>>>>> profile from scratch. I am still not sure what is the root cause though.
>>>>> I
>>>>> will keep digging into this and once I have some news I will let you
>>>>> know.
>>>>> Or if you find a way to avoid/fix/workaround this error, please let me
>>>>> know
>>>>> :)
>>>>>
>>>>> Thanks,
>>>>> Petr
>>>>>
>>>>>
>>>>> On 22 December 2014 at 19:00, Andreas Tschabuschnig <[hidden email]>
>>>>> wrote:
>>>>>> Before saying anything at all, I'd like to start with a huge thank you
>>>>>> to all the developers of Cargo for doing a stellar job. Within a
>>>>>> handful of days I managed to switch important parts of our integration
>>>>>> testing infrastructure from using internal tools to Cargo. At least
>>>>>> those using Tomcat and JBoss.
>>>>>>
>>>>>> The next on my list is WebSphere, and it is giving me a little bit of
>>>>>> trouble. I have been trying to start an ear file using an already
>>>>>> installed WebSphere application server, and using the ZipUrlInstaller,
>>>>>> both with the same result.
>>>>>>
>>>>>> After adding the native lib folder to the PATH variable, I'm getting
>>>>>> stuck at the profile manager, which always fails with:
>>>>>>> profilePath: The profile path is not valid.
>>>>>> Looking at the debug output and the source code, I don't see how I
>>>>>> could override this value, and CARGO-147 mentions troubles with the
>>>>>> profile manager, but doesn't give much help to troubleshoot this.
>>>>>> Calling manageprofiles.sh directly produces the same result. Unless
>>>>>> -profilePath is given it fails.
>>>>>>
>>>>>> Tested on CentOS and Ubuntu server, using WebSphere 8.5.0 and 8.5.5
>>>>>>
>>>>>> Any help would be highly appreciated.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>>     http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>     http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Running (into problems with) WebSphere8.5 on Linux using Cargo 1.4.11

Andreas Tschabuschnig
I have a hunch, why WebSphere isn't stopping automatically, though I could be completely wrong.

I couldn't find any indications within the Maven plugin, that stop is getting called for any of the other containers, yet they stop automatically (as expected and documented). The main difference I found, is that Tomcat and JBoss are started using a forked, but not spawned Java execution. Therefore the application server is taken down as soon as Maven terminates. WebSphere on the other hand is started indirectly using the WsServerLauncher which creates a spawned and independent JVM for the application server.

This means it might be necessary to implicitly call stop for WebSphere, unless 'cargo.process.spawn' is set to true, in which case it would be expected behavior anyways.

On Tue, Dec 30, 2014 at 7:44 PM, Andreas Tschabuschnig <[hidden email]> wrote:
Thanks for the great support, I didn't expect to be able to accomplish
this in such short time.

Concerning the stop bug, I'm calling
    mvn org.codehaus.cargo:cargo-maven2-plugin:start
org.codehaus.mojo:exec-maven-plugin:exec
where the exec goal calls a shell script that initiates the
integration tests and returns once finished. At this point my Maven
build finishes, but WebSphere stays alive and kicking. So I also call
    mvn org.codehaus.cargo:cargo-maven2-plugin:stop
when running WebSphere based builds, which seems to be working nicely.

Concerning properties, I'm still figuring out how to nicely automate
it, but I guess I just make a call to the WSAdmin thingy, while
CARGO-1285 is unresolved. Everything works now, it is just a matter of
making it 'nicer'.

Concerning documentation, it might be worth adding the additional
properties added by CARGO-1284 as well, which are kind of hidden
within the JavaDoc right now.

On Tue, Dec 30, 2014 at 11:13 AM, S. Ali Tokmen <[hidden email]> wrote:
> Hi Andreas
>
> We're glad you made it :) Indeed, the WebSphere container of CARGO is
> probably the hardest to use; be it for installing and configuring. I've
> updated http://cargo.codehaus.org/WebSphere+8.5.x with your experience -
> so more people are aware of what to do and not do.
>
> CARGO-1285 indeed tries to cover setting properties such as
> cargo.jvm.args or cargo.servlet.port for an existing configuration. On
> the other hand, please remember that these are properties you can
> specify when creating the WebSphere profile using  WebSphere's
> configuration commands.
>
> As for the stop bug, can you please tell us how you start the container?
> Perhaps there is something we forgot - as indeed that works well with
> all other containers.
>
> Thank you
>
> S. Ali Tokmen
> http://ali.tokmen.com/
> http://contact.ali.tokmen.com/
>
> On 29/12/14 20:44, Andreas Tschabuschnig wrote:
>> Hi Ali and Petr,
>>
>> I didn't realize there was a <type> for <configuration> as well ... I
>> guess that is a classic issue of RTFM, which was most likely caused by
>> me getting spoiled by how easy JBoss and Tomcat got configured with
>> defaults ;)
>>
>> Now ... using a pre-installed Websphere 8.5.5 on a CentOS box, I
>> successfully created a profile (using Cargo's default values to reduce
>> clutter in the pom file):
>>     bin/manageprofiles.sh -create -profileName cargoProfile -nodeName
>> cargoNode -cellName cargoNodeCell -serverName cargoServer
>> -winserviceCheck false -enableService false -portsFile
>> /tmp/portdef.props
>>
>> Using the <type = existing> and <home> pointing to the profile
>> directory I got one step further, namely an OutOfMemoryError in the
>> maven plugin, which was solved by setting memory options in MAVEN_OPTS
>> to a whopping 3GiB. Note that the .ear file to be deployed has about
>> 400MiB.
>>
>> Caused by: java.lang.OutOfMemoryError: Java heap space
>>   at java.util.Arrays.copyOf(Arrays.java:2271)
>>   at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:113)
>>   at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
>>   at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:140)
>>   at org.codehaus.cargo.module.DefaultJarArchive.streamToByteArray(DefaultJarArchive.java:304)
>>   at org.codehaus.cargo.module.DefaultJarArchive.<init>(DefaultJarArchive.java:87)
>>   at org.codehaus.cargo.module.webapp.DefaultWarArchive.<init>(DefaultWarArchive.java:89)
>>   at org.codehaus.cargo.module.application.DefaultEarArchive.getWebModule(DefaultEarArchive.java:104)
>>   at org.codehaus.cargo.container.websphere.WebSphere85xInstalledLocalDeployer.deploy(WebSphere85xInstalledLocalDeployer.java:125)
>>   at org.codehaus.cargo.container.spi.deployer.AbstractDeployer.redeploy(AbstractDeployer.java:234)
>>   at org.codehaus.cargo.container.websphere.WebSphere85xInstalledLocalContainer.doStart(WebSphere85xInstalledLocalContainer.java:116)
>>   at org.codehaus.cargo.container.spi.AbstractInstalledLocalContainer.startInternal(AbstractInstalledLocalContainer.java:294)
>>   at org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:225)
>>   at org.codehaus.cargo.maven2.ContainerStartMojo.executeLocalContainerAction(ContainerStartMojo.java:96)
>>   at org.codehaus.cargo.maven2.ContainerStartMojo.doExecute(ContainerStartMojo.java:63)
>>   at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:432)
>>   at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>>   at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>> ...
>>
>> After increasing mavens memory (and that of my server profile) I
>> successfully deployed my ear file on WebSphere! Unfortunately it
>> doesn't stop the server automatically. Unlike the other containers I
>> tested, which shut down the application server before finishing Maven,
>> WebSphere was still running, and my application was still available.
>> Calling goal 'stop' did the trick, but is slightly inconsistent with
>> Cargo's documentation and expected behavior.
>>
>> To summarize ...
>> Prerequisites:
>> * Install WebSphere 8.5.x
>> * Add the native lib folder to the PATH variable
>> * Create profile
>> * Optional: increase memory options in server.xml
>> * Optional: increase memory for Maven
>> * Workaround CARGO-1285: configure them in server.xml
>> * Workaround: call 'mvn org.codehaus.cargo:cargo-maven2-plugin:stop'
>> to stop server
>>
>> Using Petr's plugin configuration, with <cargo.websphere.x> variables
>> set according to existing profile, the server started.
>>
>> I'm not quite clear though, what effect the configuration properties
>> 'cargo.jvm.args' and 'cargo.servlet.port' have for WebSphere, as both
>> are currently configured within the profile. Will those be enabled as
>> part of CARGO-1285?
>>
>> On Fri, Dec 26, 2014 at 8:58 AM, S. Ali Tokmen <[hidden email]> wrote:
>>> Hi Andreas
>>>
>>> Note that Petr has shown here an existing local configuration, which is what
>>> I also mainly used for my tests (in Windows):
>>>
>>> In Windows, you need to install WebSphere anyway - you can't just unzip it
>>> Once WebSphere is installed, your paths for the container as well as the
>>> configuration are "dictated" by the WebSphere profile name you use
>>>
>>> I don't know if this at least helps with your setting up the proper testing
>>> configuration for WebSphere.
>>>
>>> Thank you
>>>
>>> S. Ali Tokmen
>>> http://ali.tokmen.com/
>>> http://contact.ali.tokmen.com/
>>>
>>> On 23/12/14 19:13, Petr Široký wrote:
>>>
>>>>>> Is there a way to provide an existing profile? It looks like Cargo is
>>>>>> always deleting the existing one and creating a new one. If I could
>>>>>> create it before hand, and have Cargo use an existing one, this might
>>>>>> solve my issue.
>>> Yes, there is. You can use an existing configuration for the container. See
>>> below for example (attaching the plugin configuration so it is easier to see
>>> where the config needs to go):
>>>
>>> <plugin>
>>>   <groupId>org.codehaus.cargo</groupId>
>>>   <artifactId>cargo-maven2-plugin</artifactId>
>>>   <configuration>
>>>     <container>
>>>       <containerId>websphere85x</containerId>
>>>       <type>installed</type>
>>>       <home>${was85x.home.dir}</home>
>>>     </container>
>>>     <configuration>
>>>       <type>existing</type>
>>>       <home>${was85x.home.dir}/profiles/${was85x.profile}</home>
>>>       <properties>
>>>         <cargo.java.home>${was85x.home.dir}/java_1.7_64</cargo.java.home>
>>>         <cargo.jvm.args>-Xms2g -Xmx2g -XX:MaxPermSize=512m</cargo.jvm.args>
>>>
>>> <!--<cargo.websphere.administrator.user>websphere</cargo.websphere.administrator.user>-->
>>>
>>> <!--<cargo.websphere.administrator.password>websphere</cargo.websphere.administrator.password>-->
>>>         <cargo.websphere.profile>${was85x.profile}</cargo.websphere.profile>
>>>         <cargo.websphere.node>testing-localhostNode02</cargo.websphere.node>
>>>
>>> <cargo.websphere.cell>testing-localhostNode02Cell</cargo.websphere.cell>
>>>         <cargo.websphere.server>testing-server1</cargo.websphere.server>
>>>
>>> <!--<cargo.websphere.classloader.mode>PARENT_LAST</cargo.websphere.classloader.mode>-->
>>>
>>> <!--<cargo.websphere.war.classloader.policy>SINGLE</cargo.websphere.war.classloader.policy>-->
>>>       </properties>
>>>     </configuration>
>>>   </configuration>
>>> </plugin>
>>>
>>> HTH,
>>> Petr
>>>
>>> On 23 December 2014 at 18:06, Andreas Tschabuschnig <[hidden email]>
>>> wrote:
>>>> @Ali
>>>> I tried with both, an existing installation, that is known to work
>>>> with currently used proprietary tools, and a standalone installation,
>>>> using the tar.gz that was used to setup the existing installation.
>>>> The maven configuration is mostly using defaults and looking something
>>>> like this for the standalone installation:
>>>>           <plugins>
>>>>             <plugin>
>>>>                 <groupId>org.codehaus.cargo</groupId>
>>>>                 <artifactId>cargo-maven2-plugin</artifactId>
>>>>                 <version>1.4.11</version>
>>>>                 <configuration>
>>>>                     <container>
>>>>                         <containerId>websphere85x</containerId>
>>>>                         <zipUrlInstaller>
>>>>
>>>> <url>file:///home/atschabu/was855-linux-x86-64.tar.gz</url>
>>>>                         </zipUrlInstaller>
>>>>                     </container>
>>>>                     <configuration>
>>>>                         <properties>
>>>>                             <cargo.servlet.port>8090</cargo.servlet.port>
>>>>                     </properties>
>>>>                 </configuration>
>>>>                 <deployables>
>>>>                     <deployable>
>>>>                         <pingURL>http://localhost:8090/ping</pingURL>
>>>>                         <pingTimeout>600000</pingTimeout>
>>>>                         <location>test.ear</location>
>>>>                     </deployable>
>>>>                 </deployables>
>>>>             </configuration>
>>>>         </plugin>
>>>>
>>>> So far I stumbled upon the following issues:
>>>> * It is necessary to add the native lib folder to the PATH variable,
>>>> even if using the ZipUrlInstaller. Which means I have to add a folder
>>>> to PATH that doesn't exist yet, and will get extracted. The installer
>>>> might be able to set it so it is available for the remaining maven
>>>> session.
>>>> ** Not really an issue, as error message is hard to misinterpret, more
>>>> an inconvenience than issue.
>>>> * All the scripts and executables within bin/ and java/ are not
>>>> executable, while they do have an executable flag within the tar file.
>>>> I assume the unzip process is not preserving the file permission
>>>> flags. Needed to add executable flag, and rerun maven plugin to
>>>> continue. This will produce issues within a CI environment.
>>>>
>>>>
>>>> @Petr
>>>> you wrote:
>>>>> when trying to let the cargo create the profile from scratch.
>>>> Is there a way to provide an existing profile? It looks like Cargo is
>>>> always deleting the existing one and creating a new one. If I could
>>>> create it before hand, and have Cargo use an existing one, this might
>>>> solve my issue.
>>>>
>>>> I made a change to the source, to provide -profilePath. Now, instead
>>>> of failing, it never finishes ... :(
>>>>
>>>>
>>>> On Tue, Dec 23, 2014 at 2:53 PM, Petr Široký <[hidden email]>
>>>> wrote:
>>>>> Hello Andreas,
>>>>>
>>>>>> profilePath: The profile path is not valid.
>>>>> I stumbled upon the same error  when trying to let the cargo create the
>>>>> profile from scratch. I am still not sure what is the root cause though.
>>>>> I
>>>>> will keep digging into this and once I have some news I will let you
>>>>> know.
>>>>> Or if you find a way to avoid/fix/workaround this error, please let me
>>>>> know
>>>>> :)
>>>>>
>>>>> Thanks,
>>>>> Petr
>>>>>
>>>>>
>>>>> On 22 December 2014 at 19:00, Andreas Tschabuschnig <[hidden email]>
>>>>> wrote:
>>>>>> Before saying anything at all, I'd like to start with a huge thank you
>>>>>> to all the developers of Cargo for doing a stellar job. Within a
>>>>>> handful of days I managed to switch important parts of our integration
>>>>>> testing infrastructure from using internal tools to Cargo. At least
>>>>>> those using Tomcat and JBoss.
>>>>>>
>>>>>> The next on my list is WebSphere, and it is giving me a little bit of
>>>>>> trouble. I have been trying to start an ear file using an already
>>>>>> installed WebSphere application server, and using the ZipUrlInstaller,
>>>>>> both with the same result.
>>>>>>
>>>>>> After adding the native lib folder to the PATH variable, I'm getting
>>>>>> stuck at the profile manager, which always fails with:
>>>>>>> profilePath: The profile path is not valid.
>>>>>> Looking at the debug output and the source code, I don't see how I
>>>>>> could override this value, and CARGO-147 mentions troubles with the
>>>>>> profile manager, but doesn't give much help to troubleshoot this.
>>>>>> Calling manageprofiles.sh directly produces the same result. Unless
>>>>>> -profilePath is given it fails.
>>>>>>
>>>>>> Tested on CentOS and Ubuntu server, using WebSphere 8.5.0 and 8.5.5
>>>>>>
>>>>>> Any help would be highly appreciated.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>>     http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>     http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Running (into problems with) WebSphere8.5 on Linux using Cargo 1.4.11

S. Ali Tokmen
Hi Andreas

Your observation is correct, this is because for all containers CARGO starts the JVM itself, whereas for WebSphere we use the .sh / .cmd files.

This could indeed be improved.

S. Ali Tokmen
http://ali.tokmen.com/
http://contact.ali.tokmen.com/
On 02/01/15 16:30, Andreas Tschabuschnig wrote:
I have a hunch, why WebSphere isn't stopping automatically, though I could be completely wrong.

I couldn't find any indications within the Maven plugin, that stop is getting called for any of the other containers, yet they stop automatically (as expected and documented). The main difference I found, is that Tomcat and JBoss are started using a forked, but not spawned Java execution. Therefore the application server is taken down as soon as Maven terminates. WebSphere on the other hand is started indirectly using the WsServerLauncher which creates a spawned and independent JVM for the application server.

This means it might be necessary to implicitly call stop for WebSphere, unless 'cargo.process.spawn' is set to true, in which case it would be expected behavior anyways.

On Tue, Dec 30, 2014 at 7:44 PM, Andreas Tschabuschnig <[hidden email]> wrote:
Thanks for the great support, I didn't expect to be able to accomplish
this in such short time.

Concerning the stop bug, I'm calling
    mvn org.codehaus.cargo:cargo-maven2-plugin:start
org.codehaus.mojo:exec-maven-plugin:exec
where the exec goal calls a shell script that initiates the
integration tests and returns once finished. At this point my Maven
build finishes, but WebSphere stays alive and kicking. So I also call
    mvn org.codehaus.cargo:cargo-maven2-plugin:stop
when running WebSphere based builds, which seems to be working nicely.

Concerning properties, I'm still figuring out how to nicely automate
it, but I guess I just make a call to the WSAdmin thingy, while
CARGO-1285 is unresolved. Everything works now, it is just a matter of
making it 'nicer'.

Concerning documentation, it might be worth adding the additional
properties added by CARGO-1284 as well, which are kind of hidden
within the JavaDoc right now.

On Tue, Dec 30, 2014 at 11:13 AM, S. Ali Tokmen <[hidden email]> wrote:
> Hi Andreas
>
> We're glad you made it :) Indeed, the WebSphere container of CARGO is
> probably the hardest to use; be it for installing and configuring. I've
> updated http://cargo.codehaus.org/WebSphere+8.5.x with your experience -
> so more people are aware of what to do and not do.
>
> CARGO-1285 indeed tries to cover setting properties such as
> cargo.jvm.args or cargo.servlet.port for an existing configuration. On
> the other hand, please remember that these are properties you can
> specify when creating the WebSphere profile using  WebSphere's
> configuration commands.
>
> As for the stop bug, can you please tell us how you start the container?
> Perhaps there is something we forgot - as indeed that works well with
> all other containers.
>
> Thank you
>
> S. Ali Tokmen
> http://ali.tokmen.com/
> http://contact.ali.tokmen.com/
>
> On 29/12/14 20:44, Andreas Tschabuschnig wrote:
>> Hi Ali and Petr,
>>
>> I didn't realize there was a <type> for <configuration> as well ... I
>> guess that is a classic issue of RTFM, which was most likely caused by
>> me getting spoiled by how easy JBoss and Tomcat got configured with
>> defaults ;)
>>
>> Now ... using a pre-installed Websphere 8.5.5 on a CentOS box, I
>> successfully created a profile (using Cargo's default values to reduce
>> clutter in the pom file):
>>     bin/manageprofiles.sh -create -profileName cargoProfile -nodeName
>> cargoNode -cellName cargoNodeCell -serverName cargoServer
>> -winserviceCheck false -enableService false -portsFile
>> /tmp/portdef.props
>>
>> Using the <type = existing> and <home> pointing to the profile
>> directory I got one step further, namely an OutOfMemoryError in the
>> maven plugin, which was solved by setting memory options in MAVEN_OPTS
>> to a whopping 3GiB. Note that the .ear file to be deployed has about
>> 400MiB.
>>
>> Caused by: java.lang.OutOfMemoryError: Java heap space
>>   at java.util.Arrays.copyOf(Arrays.java:2271)
>>   at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:113)
>>   at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
>>   at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:140)
>>   at org.codehaus.cargo.module.DefaultJarArchive.streamToByteArray(DefaultJarArchive.java:304)
>>   at org.codehaus.cargo.module.DefaultJarArchive.<init>(DefaultJarArchive.java:87)
>>   at org.codehaus.cargo.module.webapp.DefaultWarArchive.<init>(DefaultWarArchive.java:89)
>>   at org.codehaus.cargo.module.application.DefaultEarArchive.getWebModule(DefaultEarArchive.java:104)
>>   at org.codehaus.cargo.container.websphere.WebSphere85xInstalledLocalDeployer.deploy(WebSphere85xInstalledLocalDeployer.java:125)
>>   at org.codehaus.cargo.container.spi.deployer.AbstractDeployer.redeploy(AbstractDeployer.java:234)
>>   at org.codehaus.cargo.container.websphere.WebSphere85xInstalledLocalContainer.doStart(WebSphere85xInstalledLocalContainer.java:116)
>>   at org.codehaus.cargo.container.spi.AbstractInstalledLocalContainer.startInternal(AbstractInstalledLocalContainer.java:294)
>>   at org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:225)
>>   at org.codehaus.cargo.maven2.ContainerStartMojo.executeLocalContainerAction(ContainerStartMojo.java:96)
>>   at org.codehaus.cargo.maven2.ContainerStartMojo.doExecute(ContainerStartMojo.java:63)
>>   at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:432)
>>   at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>>   at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>> ...
>>
>> After increasing mavens memory (and that of my server profile) I
>> successfully deployed my ear file on WebSphere! Unfortunately it
>> doesn't stop the server automatically. Unlike the other containers I
>> tested, which shut down the application server before finishing Maven,
>> WebSphere was still running, and my application was still available.
>> Calling goal 'stop' did the trick, but is slightly inconsistent with
>> Cargo's documentation and expected behavior.
>>
>> To summarize ...
>> Prerequisites:
>> * Install WebSphere 8.5.x
>> * Add the native lib folder to the PATH variable
>> * Create profile
>> * Optional: increase memory options in server.xml
>> * Optional: increase memory for Maven
>> * Workaround CARGO-1285: configure them in server.xml
>> * Workaround: call 'mvn org.codehaus.cargo:cargo-maven2-plugin:stop'
>> to stop server
>>
>> Using Petr's plugin configuration, with <cargo.websphere.x> variables
>> set according to existing profile, the server started.
>>
>> I'm not quite clear though, what effect the configuration properties
>> 'cargo.jvm.args' and 'cargo.servlet.port' have for WebSphere, as both
>> are currently configured within the profile. Will those be enabled as
>> part of CARGO-1285?
>>
>> On Fri, Dec 26, 2014 at 8:58 AM, S. Ali Tokmen <[hidden email]> wrote:
>>> Hi Andreas
>>>
>>> Note that Petr has shown here an existing local configuration, which is what
>>> I also mainly used for my tests (in Windows):
>>>
>>> In Windows, you need to install WebSphere anyway - you can't just unzip it
>>> Once WebSphere is installed, your paths for the container as well as the
>>> configuration are "dictated" by the WebSphere profile name you use
>>>
>>> I don't know if this at least helps with your setting up the proper testing
>>> configuration for WebSphere.
>>>
>>> Thank you
>>>
>>> S. Ali Tokmen
>>> http://ali.tokmen.com/
>>> http://contact.ali.tokmen.com/
>>>
>>> On 23/12/14 19:13, Petr Široký wrote:
>>>
>>>>>> Is there a way to provide an existing profile? It looks like Cargo is
>>>>>> always deleting the existing one and creating a new one. If I could
>>>>>> create it before hand, and have Cargo use an existing one, this might
>>>>>> solve my issue.
>>> Yes, there is. You can use an existing configuration for the container. See
>>> below for example (attaching the plugin configuration so it is easier to see
>>> where the config needs to go):
>>>
>>> <plugin>
>>>   <groupId>org.codehaus.cargo</groupId>
>>>   <artifactId>cargo-maven2-plugin</artifactId>
>>>   <configuration>
>>>     <container>
>>>       <containerId>websphere85x</containerId>
>>>       <type>installed</type>
>>>       <home>${was85x.home.dir}</home>
>>>     </container>
>>>     <configuration>
>>>       <type>existing</type>
>>>       <home>${was85x.home.dir}/profiles/${was85x.profile}</home>
>>>       <properties>
>>>         <cargo.java.home>${was85x.home.dir}/java_1.7_64</cargo.java.home>
>>>         <cargo.jvm.args>-Xms2g -Xmx2g -XX:MaxPermSize=512m</cargo.jvm.args>
>>>
>>> <!--<cargo.websphere.administrator.user>websphere</cargo.websphere.administrator.user>-->
>>>
>>> <!--<cargo.websphere.administrator.password>websphere</cargo.websphere.administrator.password>-->
>>>         <cargo.websphere.profile>${was85x.profile}</cargo.websphere.profile>
>>>         <cargo.websphere.node>testing-localhostNode02</cargo.websphere.node>
>>>
>>> <cargo.websphere.cell>testing-localhostNode02Cell</cargo.websphere.cell>
>>>         <cargo.websphere.server>testing-server1</cargo.websphere.server>
>>>
>>> <!--<cargo.websphere.classloader.mode>PARENT_LAST</cargo.websphere.classloader.mode>-->
>>>
>>> <!--<cargo.websphere.war.classloader.policy>SINGLE</cargo.websphere.war.classloader.policy>-->
>>>       </properties>
>>>     </configuration>
>>>   </configuration>
>>> </plugin>
>>>
>>> HTH,
>>> Petr
>>>
>>> On 23 December 2014 at 18:06, Andreas Tschabuschnig <[hidden email]>
>>> wrote:
>>>> @Ali
>>>> I tried with both, an existing installation, that is known to work
>>>> with currently used proprietary tools, and a standalone installation,
>>>> using the tar.gz that was used to setup the existing installation.
>>>> The maven configuration is mostly using defaults and looking something
>>>> like this for the standalone installation:
>>>>           <plugins>
>>>>             <plugin>
>>>>                 <groupId>org.codehaus.cargo</groupId>
>>>>                 <artifactId>cargo-maven2-plugin</artifactId>
>>>>                 <version>1.4.11</version>
>>>>                 <configuration>
>>>>                     <container>
>>>>                         <containerId>websphere85x</containerId>
>>>>                         <zipUrlInstaller>
>>>>
>>>> <url>file:///home/atschabu/was855-linux-x86-64.tar.gz</url>
>>>>                         </zipUrlInstaller>
>>>>                     </container>
>>>>                     <configuration>
>>>>                         <properties>
>>>>                             <cargo.servlet.port>8090</cargo.servlet.port>
>>>>                     </properties>
>>>>                 </configuration>
>>>>                 <deployables>
>>>>                     <deployable>
>>>>                         <pingURL>http://localhost:8090/ping</pingURL>
>>>>                         <pingTimeout>600000</pingTimeout>
>>>>                         <location>test.ear</location>
>>>>                     </deployable>
>>>>                 </deployables>
>>>>             </configuration>
>>>>         </plugin>
>>>>
>>>> So far I stumbled upon the following issues:
>>>> * It is necessary to add the native lib folder to the PATH variable,
>>>> even if using the ZipUrlInstaller. Which means I have to add a folder
>>>> to PATH that doesn't exist yet, and will get extracted. The installer
>>>> might be able to set it so it is available for the remaining maven
>>>> session.
>>>> ** Not really an issue, as error message is hard to misinterpret, more
>>>> an inconvenience than issue.
>>>> * All the scripts and executables within bin/ and java/ are not
>>>> executable, while they do have an executable flag within the tar file.
>>>> I assume the unzip process is not preserving the file permission
>>>> flags. Needed to add executable flag, and rerun maven plugin to
>>>> continue. This will produce issues within a CI environment.
>>>>
>>>>
>>>> @Petr
>>>> you wrote:
>>>>> when trying to let the cargo create the profile from scratch.
>>>> Is there a way to provide an existing profile? It looks like Cargo is
>>>> always deleting the existing one and creating a new one. If I could
>>>> create it before hand, and have Cargo use an existing one, this might
>>>> solve my issue.
>>>>
>>>> I made a change to the source, to provide -profilePath. Now, instead
>>>> of failing, it never finishes ... :(
>>>>
>>>>
>>>> On Tue, Dec 23, 2014 at 2:53 PM, Petr Široký <[hidden email]>
>>>> wrote:
>>>>> Hello Andreas,
>>>>>
>>>>>> profilePath: The profile path is not valid.
>>>>> I stumbled upon the same error  when trying to let the cargo create the
>>>>> profile from scratch. I am still not sure what is the root cause though.
>>>>> I
>>>>> will keep digging into this and once I have some news I will let you
>>>>> know.
>>>>> Or if you find a way to avoid/fix/workaround this error, please let me
>>>>> know
>>>>> :)
>>>>>
>>>>> Thanks,
>>>>> Petr
>>>>>
>>>>>
>>>>> On 22 December 2014 at 19:00, Andreas Tschabuschnig <[hidden email]>
>>>>> wrote:
>>>>>> Before saying anything at all, I'd like to start with a huge thank you
>>>>>> to all the developers of Cargo for doing a stellar job. Within a
>>>>>> handful of days I managed to switch important parts of our integration
>>>>>> testing infrastructure from using internal tools to Cargo. At least
>>>>>> those using Tomcat and JBoss.
>>>>>>
>>>>>> The next on my list is WebSphere, and it is giving me a little bit of
>>>>>> trouble. I have been trying to start an ear file using an already
>>>>>> installed WebSphere application server, and using the ZipUrlInstaller,
>>>>>> both with the same result.
>>>>>>
>>>>>> After adding the native lib folder to the PATH variable, I'm getting
>>>>>> stuck at the profile manager, which always fails with:
>>>>>>> profilePath: The profile path is not valid.
>>>>>> Looking at the debug output and the source code, I don't see how I
>>>>>> could override this value, and CARGO-147 mentions troubles with the
>>>>>> profile manager, but doesn't give much help to troubleshoot this.
>>>>>> Calling manageprofiles.sh directly produces the same result. Unless
>>>>>> -profilePath is given it fails.
>>>>>>
>>>>>> Tested on CentOS and Ubuntu server, using WebSphere 8.5.0 and 8.5.5
>>>>>>
>>>>>> Any help would be highly appreciated.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>>     http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>     http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>