Adding binary dependencies

[thomas.diesler]

Folks,

JBoss OSGi releases are QAed against a matrix of runtimes. For the MC based Framework, this is currently AS520 and AS600

http://jbmuc.dyndns.org:8280/hudson/job/jbossosgi-matrix-jbossmc

Any binary dependency we introduce, must either be available already in AS or be installed by the installer. For core services this might not always be possible.

For example, we cannot use a SNAPSHOT version of jboss-vfs if that cannot be used by the AS instances JBoss OSGi supports.

As a consequence, I had to rollback the recent update to jboss-vfs.

cheers

[alesj]

and you also understand and agree on how kernel updates should be handled.

This will never scale -- AS' MC update lifecycle is completely different as how we change things in OSGi.
Or, it should be -- otherwise you'll never be able to move logic that can be generalized from OSGi to MC.

There was already a topic on this, I don't wanna look for it now - better things to do.

But afair it was said that those tests should not run off trunk, but some stable branch.
I don't know why we're going in circles if this was already said - as that's the only logical choice.

[thomas.diesler]

Sorry, I don't quite understand what you are suggesting. Are you really saying it is ok to break Hudson test coverage of OSGi/AS integration, I hope not.

Given that we will need frequent updates to the MC layer that somehow need to make it into AS, lets focus on what could work:

#1 Updates to MC must always be backward compatible to whatever is installed in AS. It is ok to create a SNAPSHOT dependency on MC stuff in framework/trunk if the same SNAPSHOT is installed in AS. This is what I suggested.

#2 It is ok to create a SNAPSHOT dependency on MC stuff in framework/trunk and temporarily install that SNAPSHOT in AS through the OSGi installer. The existing AS testsuite won't be affected. The next AS release must contain a tagged version of MC that contains the changes. A JBoss OSGi release can never replace critical components provided by AS because running the OSGi installer would then potentially break an existing AS installation.

Perhaps you have another posibility in mind, lets hear that as well.

Whatever procedure we decide on, we cannot throw Hudson QA over board and this is what happened now by creating a dependency on a kernel SNAPSHOT that is not available in AS. Again, please fix the Hudson run and suggest an alternative procedure we can follow that somehow preserves a working QA environment, if the above suggestions don't work for you.

#1 might be too disruptive to all the other projects that integrate with AS. With #2 we are initially not disruptive to others, but come in late in the game when AS wants to make a release. This is what happened lately with the (broken) jboss-cl release, which if you asked Brian or Jason was not a good procedure to follow. An early jboss-cl SNAPSHOT in AS might have revealed the latest issues earlier.

[alesj]

Sorry, I don't quite understand what you are suggesting. Are you really saying it is ok to break Hudson test coverage of OSGi/AS integration, I hope not.

This Hudson test coverage is either overrated or done wrong.

With OSGi component, we're not just adding new service/feature,

we're modifying the underlying kernel/core of AS.

At least this is how it's gonna be, until we know existing MC api can handle all we need to simply impl OSGi on top.

And while we're generalizing OSGi features to become MC features,

you cannot expect full api backwards compatibility or that we won't hit some errors.

This is like saying we need to keep MC inline with AS all the time, having Hudson runs to prove it, etc.

As you can see, we don't have that, as it would never work.

Same goes for OSGi, which is just another tight integration point of MC - as is VFS, CL, Deployers, MDR, ...

What we do in MC is mock most of the scenarios,

which is what we're also doing in OSGi framework, so that's OK.

I do understand your need for additional testing, as we have more than framework usage (embedded, runtime),

but this still doesn't justify limitations put on framework wrt MC component updates.

Whatever procedure we decide on, we cannot throw Hudson QA over board and this is what happened now by creating a dependency on a kernel SNAPSHOT that is not available in AS. Again, please fix the Hudson run and suggest an alternative procedure we can follow that somehow preserves a working QA environment, if the above suggestions don't work for you.

For me this Hudson presents an env where you test additional JEE services/features on top of 3 existing frameworks.

And as such needs to run off stable framework releases -- e.g. you're also not running against Felix's trunk. ;-)

To test the framework/trunk itself, that it runs flawlessly in AS (+ that OSGi_JEE stuff),

I don't see any good option else than to trust framework's testsuite and TCK.

Existing AS branches/tags/trunk don't cut it,

the only thing that might work is to maintain a separate branch which would be inline with MC.

But since it would also need to be inline with AS/trunk, this would present a big overhead wrt resources available.

[thomas.diesler]

Please take into consideration that consumers of the jboss osgi distribution, which we had 4800+ for Beta5, only care about the OSGi integration in AS. There are multiple standalone OSGi runtimes available, which are at this point in time far superior to the native jboss core framework. If the native core framework does not work in AS it might not be there at all.

After a long conversation with Dimitris, we agreed that osgi cannot drop random snapshots of critical components into AS. This would create too many moving targets for other folks.

Following that conversation, I added a new pack to the installer that overwrites the kernel componenets that you indicated. The result was, that AS did indeed start (the good news) but service handling was fundametally broken (the bad news). The osgi management console did not start and none of the osgi examples that we ship would run.

From 10.000 ft you changed stuff in the framework that requires an unpdate on kernel components. You verified this in a local mvn run and perhaps in your IDE. You assumed that those changes were also valid when deployed into AS. The latter unfortunately is an invalid assumption that we can detect with the Hudson run.

As it stands now, I had to rollback those changes and must kindly ask you to redo this such that it also works in AS. A good sanity check is that the osgi management console actually shows up on http://localhost:8090/jboss-osgi In which case you can have good confidence that critical bundles installed and started correctly and the necessary services are available.

If you need the installer to overwrite stuff in AS you can do it like this

    <!--
      ********************************* 
      *                               *
      * JBossAS Overwrites            *
      *                               *
      *********************************
    -->

    <!-- 
       This pack MUST NOT be part of an JBoss OSGi release 
    -->
    <pack name="JBossMC SNAPSHOT overwrites" required="no" preselected="yes">
      <description>Temporarily overwrite AS provided jars with SNAPSHOT versions</description>
      
      <fileset condition="isJBossMC" dir="@{deploy.artifacts.dir}/lib" targetdir="${jbossInstallPath}/lib"
        override="true">
        <include name="jboss-jmx-mc-int.jar" />
      </fileset>
    </pack>

Here is the latest Hudson run that shows that everthing is good in AS

http://jbmuc.dyndns.org:8280/hudson/job/jbossosgi-matrix-jbossmc/73/

[alesj]

Please take into consideration that consumers of the jboss osgi distribution, which we had 4800+ for Beta5, only care about the OSGi integration in AS. There are multiple standalone OSGi runtimes available, which are at this point in time far superior to the native jboss core framework. If the native core framework does not work in AS it might not be there at all.

I fail to see how this relates to framework/trunk.

I highly doubt there will be consumers that will like to run framework/trunk snapshot in AS,

or even less likely to actually contribute something AS related to framework.

If such consumers exist, then I'm sure they will know how to handle this obstacle of not having Hudson run to prove them that framework/trunk is fully operational in current AS, but will have to settle for extensive testsuite.

The consumers you mention use existing releases, not moving targets. ;-)

As for our/my work goes, I know I'll break some things -- as the latest JMX stuff proves it.

But for this I don't need Hudson run every 5min.

I need it once I'm done and ready to see how current framework/trunk snapshot behaves in AS.

I'll they pick the failing details and fix them, until there is no failure left.

But this is impossible to do, if you constantly revert things.

[dimitris]

I don't get all the jurgon used in this thread, but I think we have too many moving pieces here:

JBoss OSGi uses MC, but needs to be tested on top of AS that uses MC.

How best to make sure the MC changes that go in the next AS release do not break the next (and even the existing?) version of JBoss OSGi?

Thomas wants to have some form of Continuous Integration (CI). I believe he has proposed a hudson run that takes the latest snapshot from MC, installs it on AS and tests that to make sure cuurent MC changes don't break the next release of OSGi.

On the other hand, MC needs to have an eye on those OSGi QA runs, to make sure it doesn't cut a release that breaks the latest OSGi.

If I understood that correctly, what is the problem with that?

[alesj]

Thomas wants to have some form of Continuous Integration (CI). I believe he has proposed a hudson run that takes the latest snapshot from MC, installs it on AS and tests that to make sure cuurent MC changes don't break the next release of OSGi.

This - "takes the latest snapshot from MC, installs it on AS" - is not an option, at least not in generic sense.

It will never work - I can tell you from the last-2-years-MC-updates-in-AS experience.

It usually takes us a few fix-releases and a good couple of days to get it right to get MC fully working in AS.

On the other hand, MC needs to have an eye on those OSGi QA runs, to make sure it doesn't cut a release that breaks the latest OSGi.

This is why we have an extensive (mock AS) testsuite in framework/trunk and TCK.

Testing of OSGi_MC_Facade in AS should only be done once we feel it's ready.

[dimitris]

Thomas wants to have some form of Continuous Integration (CI). I believe he has proposed a hudson run that takes the latest snapshot from MC, installs it on AS and tests that to make sure cuurent MC changes don't break the next release of OSGi.

This - "takes the latest snapshot from MC, installs it on AS" - is not an option, at least not in generic sense.

It will never work - I can tell you from the last-2-years-MC-updates-in-AS experience.

It usually takes us a few fix-releases and a good couple of days to get it right to get MC fully working in AS.

Can you be more specific why this won't work? Do you want to have MC trunk in an intermediate state with snapshots and tagged released that are fed into other testsuites (e.g. AS, EJB3) until you are satisfied you have a good release to be used by AS and/or OSGi?

So in the meantime what JBoss OSGi should be testing against? How to guard against OSGi not working because of an incompatible (let's say) MC change released?

[alesj]

Can you be more specific why this won't work? Do you want to have MC trunk in an intermediate state with snapshots and tagged released that are fed into other testsuites (e.g. AS, EJB3) until you are satisfied you have a good release to be used by AS and/or OSGi?

AS running on current MC snapshots will never work.

Just look at how this current AS6_trunk switch to MC 2.2.x was going.

While it might appear that AS runs fine, you cannot know until AS' Hudson proves it.

When working on making MC generalize OSGi features - which is our end goal - we are using snapshots in between,

as my/our changes usually span across whole MC sub-projects, also changing them on daily bases.

Other testsuites - AS, EJB3, ... - should have no such MC snapshot dependency,

as they should only depend on stable API, as they are not so thight integrators as our OSGi Facade.

So in the meantime what JBoss OSGi should be testing against? How to guard against OSGi not working because of an incompatible (let's say) MC change released?

Re-read my previous post: "This is why we have an extensive (mock AS) testsuite in framework/trunk  and TCK."

As all of our MC stuff, we have extensive "embedded" tests in the (sub)project itself, and the same goes for OSGi_Facade.

We need to decide what we wanna do.

(1) persuing the full OSGi_Facade based on generalized MC, passing as much of TCK as possible, while still having decent integration tests, and eventually push this features to AS as well

(2) or, jumping from story to story, doing a bit of AS integration, hence complaining how we're breaking this while we persue (1), and a bit of OSGi core framework, hence saying we don't care about (2) atm

[alesj]

Following that conversation, I added a new pack to the installer that overwrites the kernel componenets that you indicated. The result was, that AS did indeed start (the good news) but service handling was fundametally broken (the bad news). The osgi management console did not start and none of the osgi examples that we ship would run.

Is there an exception I could have a look at?

As I just re-run the whole scenario (it took me a while since I had to fix a lot of the stuff manually due to revert+refactor combo),

and it's like you said, the AS boots up fine, but the Jetty's jboss-osgi page is not accessible.

But I don't see any stacktrace or other info that would tell me what's wrong.

This is the only thing I get, after a while since it's asynch

2010-02-10 16:31:53,768 ERROR [org.apache.aries.blueprint.container.BlueprintContainerImpl] (pool-7-thread-2) Unable to start blueprint container for bundle org.apache.aries.blueprint: java.util.concurrent.TimeoutException
    at org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:270)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:637)

But I doubt this is the cause.

[alesj]

OK, the jboss-osgi console is responsive for me,

but now I get this:

HTTP ERROR 500

Problem accessing /jboss-osgi/bundles. Reason:

    Cannot load 'org.jboss.osgi.framework.service.internal.StartLevelImpl' from: Bundle{jboss-osgi-webconsole-1.0.2}

Caused  by:

java.lang.IllegalStateException: Cannot load 'org.jboss.osgi.framework.service.internal.StartLevelImpl' from: Bundle{jboss-osgi-webconsole-1.0.2}
     at org.jboss.osgi.framework.bundle.MDRUtils.isAssignableTo(MDRUtils.java:167)
     at org.jboss.osgi.framework.bundle.MDRUtils.isAssignableTo(MDRUtils.java:292)
     at org.jboss.osgi.framework.bundle.ServiceManagerPluginImpl.getServices(ServiceManagerPluginImpl.java:380)
     at org.jboss.osgi.framework.bundle.ServiceManagerPluginImpl.getServiceReferences(ServiceManagerPluginImpl.java:191)
     at org.jboss.osgi.framework.bundle.AbstractBundleState.getServiceReferences(AbstractBundleState.java:511)
     at org.jboss.osgi.framework.bundle.OSGiBundleContextWrapper.getServiceReferences(OSGiBundleContextWrapper.java:157)
     at org.osgi.util.tracker.ServiceTracker.getInitialReferences(ServiceTracker.java:362)
     at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:311)
     at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:273)
     at org.apache.felix.webconsole.internal.BaseWebConsolePlugin.getService(BaseWebConsolePlugin.java:89)
     at org.apache.felix.webconsole.internal.BaseWebConsolePlugin.getStartLevel(BaseWebConsolePlugin.java:73)
     at org.apache.felix.webconsole.internal.core.BundlesServlet.renderContent(BundlesServlet.java:289)
     at org.apache.felix.webconsole.AbstractWebConsolePlugin.doGet(AbstractWebConsolePlugin.java:127)
     at org.apache.felix.webconsole.internal.core.BundlesServlet.doGet(BundlesServlet.java:117)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
     at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:329)
     at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
     at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:389)
     at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.handle(HttpServiceServletHandler.java:64)
     at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
     at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
     at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.handle(HttpServiceContext.java:111)
     at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:64)
     at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
     at org.mortbay.jetty.Server.handle(Server.java:326)
     at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534)
     at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:864)
     at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:539)
     at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
     at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
     at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
     at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520)

---

Powered by Jetty://


Could be that I'm working on an old revision (which includes service-mix).

Any ideas on why it cannot load that class?

[alesj]

Any ideas on why it cannot load that class?

OK, I think I know why I get that -- fixing it now.

[alesj]

OK, I think I know why I get that -- fixing it now.

Why would ServiceTracker return null?

java.lang.NullPointerException
     at org.apache.felix.webconsole.internal.core.BundlesServlet.renderContent(BundlesServlet.java:289)
     at org.apache.felix.webconsole.AbstractWebConsolePlugin.doGet(AbstractWebConsolePlugin.java:127)
     at org.apache.felix.webconsole.internal.core.BundlesServlet.doGet(BundlesServlet.java:117)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
     at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:329)
     at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
     at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:389)
     at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.handle(HttpServiceServletHandler.java:64)
     at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
     at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
     at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.handle(HttpServiceContext.java:111)
     at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:64)
     at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
     at org.mortbay.jetty.Server.handle(Server.java:326)
     at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534)
     at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:864)
     at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:539)
     at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
     at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
     at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
     at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520)

As that what's now happening for StartLevel.

Previous problem was that it was picking up service plugin StartLevelImpl,

which also exposes impl details.

I made that autowire-candidate="false", which means it should now only pick up the registered OSGi StartLevel.

But it's not -- hence the null.

[alesj]

Previous problem was that it was picking up service plugin StartLevelImpl,

which also exposes impl details.

I made that autowire-candidate="false", which means it should now only pick up the registered OSGi StartLevel.

But it's not -- hence the null.

Ah, brain-dead ... our plugins are picked up via auto-wire. :-)

It needs an explicit add via installs (which is a workaround and should be fixed) -- but it works now!!