Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Virgo » Random Problem While Booting Virgo(Uses violation problem with uses conflict for import that occurs randomly when booting the Virgo server.)
Random Problem While Booting Virgo [message #1044214] Thu, 18 April 2013 16:13 Go to next message
FreeSpeech Mising name is currently offline FreeSpeech Mising nameFriend
Messages: 2
Registered: September 2009
Junior Member
Hi all,

The problem seems to be random since I can boot the server multiple times and in about one third of the booting it will be successful. Otherwise, I will always get the error :

BundleDependenciesException: Unable to satisfy dependencies of bundle 'com.omnimed.healthrecord.webapp' at version '9.0.0': Cannot resolve: com.omnimed.healthrecord.webapp
    Resolver report:
        Uses violation: <Import-Package: org.apache.myfaces.application; version="0.0.0"> in bundle <com.webapp_9.0.0[1366218801653]>
             Resolver reported uses conflict for import constrained to bundle <org.apache.myfaces.core.impl> constrained bundle version range "[2.1.7,2.1.7]"
        Uses violation: <Import-Package: org.apache.myfaces.config; version="0.0.0"> in bundle <com.webapp_9.0.0[1366218801653]>
             Resolver reported uses conflict for import constrained to bundle <org.apache.myfaces.core.impl> constrained bundle version range "[2.1.7,2.1.7]"

        at org.eclipse.virgo.kernel.install.pipeline.stage.resolve.internal.QuasiResolveStage.process(
        at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessGraph(
        at org.eclipse.virgo.kernel.install.pipeline.internal.CompensatingPipeline.doProcessGraph(
        at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(
        at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessGraph(
        at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(
        at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.driveInstallPipeline(
        at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.doInstall(
        at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.install(
        at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.deploy(

The following settings have been tried to give more time to the server to boot in a effort to diagnose that possibility :

org.eclipse.virgo.kernel.startup.wait.limit from 300 (default) to 1000
deployer.timeout from 0 to 300 (default)

The testing environment consist of the Virgo Server 3.6.0 watching the repositories of a remote Virgo Server 2.1.1. We also configured the server to auto-start when the OS reboots by creating an entry in the /etc/init.d that uses a file in the bin folder of the server and adding the configuration in the file to ensure that the arguments we want are used instead of the default one. We tried impacting the configuration files in a minimal way.

Here's the :

                -Dorg.apache.el.parser.COERCE_TO_ZERO=false \
                -Djava.rmi.server.hostname=id.adress.of.server \
                -Xverify:none \
                -server \
                -Xms128m \
                -Xmx2048m \
                -Xss192k \
                -XX:NewRatio=2 \
                -XX:PermSize=512m \
                -XX:MaxPermSize=728m \
                -XX:MaxGCPauseMillis=10 \
                -XX:+CMSIncrementalPacing \
                -XX:CMSIncrementalDutyCycleMin=0 \
                -XX:+UseParallelGC \
                -XX:+UseFastAccessorMethods \
                -XX:+UseStringCache \
                -XX:+OptimizeStringConcat \
                -XX:+UseCompressedStrings \

Here's the change to the :

        # If we get here we have the correct Java version.

        if [ -z "$NO_START_FLAG" ]
                # Ensure that the tmp directory exists
                mkdir -p $TMP_DIR

                    -Xmx512m \

                cd $KERNEL_HOME; exec $JAVA_EXECUTABLE \
                        $JAVA_OPTS \
                        $DEBUG_OPTS \
                        $JMX_OPTS \
                        -XX:+HeapDumpOnOutOfMemoryError \
                        -XX:ErrorFile=$KERNEL_HOME/serviceability/error.log \
                        -XX:HeapDumpPath=$KERNEL_HOME/serviceability/heap_dump.hprof \
              $AUTH_LOGIN \
                        -Dorg.eclipse.virgo.kernel.authentication.file=$AUTH_FILE \
              $TMP_DIR \
                        -Dorg.eclipse.virgo.kernel.home=$KERNEL_HOME \
                        -Dorg.eclipse.virgo.kernel.config=$CONFIG_DIR \
              "file:$JAVA_PROFILE" \
            -Declipse.ignoreApp=true \
            -Dosgi.install.area=$KERNEL_HOME \
            -Dosgi.configuration.area=$CONFIG_AREA \
            -Dssh.server.keystore="$CONFIG_DIR/hostkey.ser" \
            -Dosgi.frameworkClassPath=$FWCLASSPATH \
            -Djava.endorsed.dirs="$KERNEL_HOME/lib/endorsed" \
            -classpath $CLASSPATH \
                        $MY_ARGS \ <-------------------------------------------------------OUR MODIF !!!!!
                        org.eclipse.equinox.launcher.Main \
            -noExit \
                        $LAUNCH_OPTS \

In our development environment, everything works fine. Is it a booting sequence problem when the server gets the remotely hosted jars ? By this I 'suppose' that the server tries to resolve the dependencies while loading them, which seems kind of weird, but I just ask ! Maybe it could affect the content of the remote-xyz.descriptors ?! Maybe there's not enough memory, but JConsole shows differently or I'm missing something !

Thanks in advance for your help and I'm open to test many configurations !!
Re: Random Problem While Booting Virgo [message #1058251 is a reply to message #1044214] Mon, 13 May 2013 11:11 Go to previous message
Glyn Normington is currently offline Glyn NormingtonFriend
Messages: 1222
Registered: July 2009
Senior Member
One possibility is that the Equinox resolver is sometimes timing out during its resolution process. I think there is a way to configure the timeout in Equinox, but I can't find the configuration parameter in the public documentation. But see bug 359862 for details.
Previous Topic:Redeploy / ClassLoader problem
Next Topic:bundle in ext directory cannot be resolved
Goto Forum:

Current Time: Mon Jun 18 10:05:25 GMT 2018

Powered by FUDForum. Page generated in 0.01548 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top