November 2009 - jboss-dev-forums - Jboss List Archives

[JBoss OSGi Development] - Re: Service integration with MC

by alesj

"adrian(a)jboss.org" wrote : | So we add a "ServiceTracker" to the MDR which for deployments will be in the deployment level (really the application/top level deployment) | for others it will be as you say a default one at the Server level, what osgi calls the "SystemBundle". | You can imagine others might choose to track at some other level. e.g. | for JavaEE we might choose to track at sub-deployment level, what MDR | confusingly calls the deployment level. :-) | | When you do any type of injection (or the api is invoked from somewhere else) | this should invoke the equivalent of get/unget of the ServiceTracker for that context. | | Once that is done, the queries can go through the ServiceTracker at the relevant level. | The deployment level for normal OSGiBundleState and the server level for the SystemBundle. | | You still need a "global" list of services for the getXXXServiceXXX() queries. | That should primarily be based on an index by class (it doesn't have to be | its a performance optimization and only available when you have been asked | to query by class). But once you've subsetted by class then you do a | "read and skip" over those contexts to locate the ones that match any passed filter on the properties (instance level MDR). | I fail to see why I would need to different levels of ServiceTracker. As I also always have to check the "global" list. When would I check just deployment level ServiceTracker? For non-system bundle, to lookup non-osgi services that belong just to this bundle / jar / deployment? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266790#4266790 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266790

16 years, 4 months

1
0
0 / 0

[JBoss Tools Development] - Re: [Struts Flow Editor Bug] any solution or advise for debu

by scabanovich

Thanks, keibun! Your description is very helpful. I have created an issue in JIRA: https://jira.jboss.org/jira/browse/JBIDE-5236 Here is my comment as to what is the cause of the issue: Initially there is null pointer exception in method resolveInternal() of class StrutsProcessHelper, because it treated comment objects in the same way as action objects, which was not correct. The exception was caught by method runTasks() to be logged, but because inconsistency in MANIFEST.MF, instance of log was not initialized, so that another null pointer happens, and having left uncaught, interrupts the update of diagram. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266759#4266759 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266759

16 years, 4 months

1
0
0 / 0

[JBoss Tools Development] - [Struts Flow Editor Bug] any solution or advise for debuggin

by keibun

I found bug in "Struts Flow Editor". my environment is ---------------------- Eclipse: 3.4.2 Struts Tools: 3.0.1 ---------------------- the bug I found is below ------------------------ description: when "Action" has "Comment", drawing "Forward Link" causes some "Forward Link" line vanished. how to reproduce bug: 1. you have "Action1" and "Action2" 2. add Comment to "Action1" 3. draw "Forward Link" line from "Action1" to "Action2". 4. draw "Forward Link" line from "Action2" to "Action1". then line from Action2 to Aciton1 disappear from the screen. I found data file .strutsdia is not valid comparing to real struts-config.xml ------------------------ I want bug fix or adivise for debuggin. I'm very new to Eclipse plugin developement, but I set up my eclipse which can enable step debugging and fixing code. I suspect struts data mode is corrupted when action has comment. for the first step I want to compare data model of struts flow ui between commented and not commented. I want to dump data model at /org.jboss.tools.struts/src/org/jboss/tools/struts/model/handlers/StrutsPasteHandler.java executeHandler(). Is there good way to dump XModelObject tree so as to get useful information? any other useful debug technic is welcome. regard. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266746#4266746 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266746

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Define non OSGi bundle handling by the Framework

by thomas.diesler＠jboss.com

Yes, all this exposes is when we have a certain functionality available in JBoss OSGi. An uncoordinated update of core components would simply result in the MC Framework not being usable in AS. This is something we don't want either ;-) If we need to update a core library in AS (i.e. one that we cannot simply replace), then there should be an AS issue created for that which is a dependency on the some JBoss OSGi release issue. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266726#4266726 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266726

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Define non OSGi bundle handling by the Framework

by alesj

"thomas.diesler(a)jboss.com" wrote : | Anyhow, the MC framework needs to work in AS and the OSGi examples must run in AS. This is not something you can do in an Eclipse unit test. | | It'd be good if you could trigger the integration tests as part of your normal commit routine. | Although I understand and support this, this is not always possible - see my latest commits. For me in order to move fwd, I need to work on Kernel 2.2.x, which is not yet in AS, and will only be available for AS6. The same will probably go for Adrian's work on CL's LifeCycle / Resolver. I guess this requires some automation on whether it even makes sense to run tests on AS. e.g. libs compatibility Since in this case you cannot solve the problem with a simple lib change, as the changes affect the stuff beyond encapsulated MC projects. e.g. ControllerContext::ungetTarget --> AS' JMX + MC int View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266720#4266720 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266720

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Define non OSGi bundle handling by the Framework

by thomas.diesler＠jboss.com

anonymous wrote : | Adrian Brock's 1st Law of Programming. | It it ain't tested it doesn't work. | | 1st Law Corollary | It it ain't tested the feature doesn't exist. ;-) | Sure, these are the laws I also work according to. anonymous wrote : | Why aren't there regression tests for these features in reactor/framework? | JBoss OSGi supports multiple OSGi frameworks, for the reason that standard OSGi is already usable in AS. What we do with the OSGi example and functional test is a specific solution to the general problem of Maven integration testing http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing Anyhow, the MC framework needs to work in AS and the OSGi examples must run in AS. This is not something you can do in an Eclipse unit test. I realize, that the building the installer, installing the framework, starting the target container, running the examples against the target container is not a practical prerequisite for an SVN commit. However, everybody should at least be aware of the functionality that already works and is being tested. One click on the public hudson instance can pickup potential integration issues, which can then be looked at and fixed locally. It'd be good if you could trigger the integration tests as part of your normal commit routine. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266714#4266714 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266714

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: PROPERTY_AUTO_START

by thomas.diesler＠jboss.com

Ok, here is the issue https://jira.jboss.org/jira/browse/JBDEPLOY-225 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266713#4266713 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266713

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Goals of OSGi integration

by thomas.diesler＠jboss.com

Thanks this is very helpful. anonymous wrote : | This worked until the latest changes. | Stuff needs to work in Hudson on all supported target contains http://jbmuc.dyndns.org:8280/hudson/ A successful Eclipse test run, is unfortunately not sufficient as a release criteria. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266711#4266711 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266711

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: No explicit control over bundle.start()

by thomas.diesler＠jboss.com

anonymous wrote : | The OSGi spec takes a different (and probably incorrect :-) view. | I disagree. A bundle that is INSTALLED has no classloader nor bundle context associated with it. You can use PackageAdmin for an attempt to resolve that bundle. If that fails, the bundle is still INSTALLED. If that succeeds the bundle is RESOLVED, you can then use bundle.start() to start the bundle (i.e. call BundleActivator). If that fails the bundle is still RESOLVED. In no case does the bundle get uninstalled if a transition to the RESOLVED or ACTIVE state fails. anonymous wrote : | So the solution is to add an ErrorHandler to the DeploymentControllerContext if it is an OSGi deployment, | Ok, here is the issue https://jira.jboss.org/jira/browse/JBDEPLOY-225 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266710#4266710 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266710

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: How does bundle resolution work

by thomas.diesler＠jboss.com

Ok, but this is not about classloading alone. The modules need to first have a correct wiring. If you install multiple bundles and want to resolve them at the same time there needs to be a non-trivial resolve algorithm that is aware of the rich osgi semantics, the complete set of already resolved bundles plus the set of bundles that still need resolving. Anyhow, I agree that all of this needs to bubble up into the MC and I'll create issues in the MC projects as I encounter them in the OSGi TCK work. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266707#4266707 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266707

16 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2009