On Sep 27, 2010, at 4:34 PM, Valentin Mahrwald wrote: > > On 27 Sep 2010, at 16:28, Lin Sun wrote: > >> Hi >> >> Yes I totally agree we need a test case for this to demonstrate we >> (can) support this, when isolation is turned on. I suspect the >> current code won't work as it is today. > > Most certainly today it will fail. The Blueprint code as it stands has a > global namespace handler registry that is populated exclusively from the > framework that the Blueprint bundle lives in. Custom handlers inside an EBA > would work neither at resolution time nor at runtime. > As David points out, the current model is ill suited for resolving against > custom namespaces inside EBAs. In my mind part of the reason why namespace > handlers have become so weird is that most of them try to accomplish two > things through a single interface: > 1) transforming custom blueprint xml into standard blueprint xml. > 2) set up runtime objects behind the scene when the blueprint starts. >
The one I wrote (xbean-blueprint) (or modified from xbean-spring) does neither of these. It takes an entire document in an alternate schema (except for the root blueprint element) and directly constructs blueprint bean descriptors. I haven't looked but I thought this was how all namespace handlers work. Modifying a dom tree at runtime seems really weird to me. This process really needs access to the bean classes to check for annotations, although my current implementation works around this (poorly) > If we could somehow separate the two concerns, a solution would be easier. > For example the transformation step could then be accomplished through a > runtime independent mechanism like an XSLT, which we could use at resolution > time without having to worry about having to load classes or even install > bundles somewhere. The transformed xml would probably need a new hook in core > blueprint to call out to handlers when the blueprint is actually loaded, but > that would still be much cleaner. Just my 1cent worth. > How will annotation scanning namespace handlers that add blueprint beans or register beans specified in blueprint xml as services work in this environment? thanks david jencks > ... > > Custom namespace handlers in the runtime framework would be an interesting > test case. That ought to work with the present code ;) > > >> Basically in the test case, the eba will contain a custom namespace >> handler and some blueprint definition XML that uses the custom >> element. The EBA installer would install this custom namespace >> handler as part of the EBA in its isolated framework and configure the >> application policy properly. The blueprint namespace handler should >> be able to detect and register the custom namespace handler that is >> provided by the isolated framework and invoke the custom namespace >> handler when processing the custom element. It is possible we could >> fail in one or more of these steps.... >> >> Lin >> >> On Mon, Sep 27, 2010 at 4:12 PM, Alasdair Nottingham <[email protected]> wrote: >>> 1) I don't know how the blueprint code handles this situation when the >>> parsing service is being used, as opposed to setting up a blueprint. A >>> test case is a good way in my view to work this out. It would also >>> help us to scope what, if any, limitation exists. >>> 2) If namespace handlers were standardized then I believe it would >>> increase the likely hood of people wanting to include namespace >>> handlers and include them in applications. It is therefore relevant >>> because it affects, in my mind at least, the priority of worrying >>> about this "limitation". >>> >>> Alasdair >>> >>> On 27 September 2010 20:52, David Jencks <[email protected]> wrote: >>>> Not sure how a test case will clarify the situation. You are saying the >>>> eba scan of blueprint plans should not install any bundles in the eba. My >>>> scenario is that a namespace handler impl is in one of the eba bundles and >>>> it adds all the services exported by the blueprint plan. How can you >>>> discover these without loading the namespace handler from one of the eba >>>> bundles, which you've said shouldn't happen? I don't see standardization >>>> of namespace handlers are relevant, this seems like an important >>>> requirement for the interaction of EBA and blueprint that ought to be >>>> ironed out in the future specs. >>>> >>>> david jencks >>>> >>>> On Sep 27, 2010, at 12:28 PM, Alasdair Nottingham wrote: >>>> >>>>> I think we need a test case, it is possible it won't work as it can't >>>>> find the namespace handler to parse the code, also if it adds services or >>>>> references we may not add them to the resolve process, so bad things >>>>> could happen. I don't think applications will do this right now since >>>>> namespace handlers are not standardised. >>>>> >>>>> Alasdair >>>>> >>>>> On 27 Sep 2010, at 20:06, Lin Sun <[email protected]> wrote: >>>>> >>>>>> I think that should be possible. We just need to make sure the name >>>>>> space handler registered in the isolated environment are detectable by >>>>>> the namespace handler registry thus can be properly registered. >>>>>> >>>>>> Lin >>>>>> >>>>>> On Mon, Sep 27, 2010 at 2:55 PM, David Jencks <[email protected]> >>>>>> wrote: >>>>>>> Does this behavior mean that an EBA can't package a namespace handler >>>>>>> that one of its other bundles uses? Is this prohibited or even a bad >>>>>>> idea for other reasons? >>>>>>> >>>>>>> thanks >>>>>>> david jencks >>>>>>> >>>>>>> On Sep 27, 2010, at 11:39 AM, Alasdair Nottingham wrote: >>>>>>> >>>>>>>> No, it is so the resolver can resolve dangling service references, >>>>>>>> installing the bundles would be bad because it would violate the >>>>>>>> contract of the Aries application installer which allows you to >>>>>>>> resolve without installing the application. Also when we are >>>>>>>> installing in an isolated way we need to know the resolution prior to >>>>>>>> installation, so we would need to install, uninstall then reinstall. >>>>>>>> >>>>>>>> Your namespace handler must cope, what is the problem? >>>>>>>> >>>>>>>> Alasdair >>>>>>>> >>>>>>>> On 27 Sep 2010, at 19:34, Joe Bohn <[email protected]> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Can you be more specific on the need for the EBA installer to parse >>>>>>>>> the blueprint xml? Is it to validate that services exported by the >>>>>>>>> EBA are actually defined in some bundle? >>>>>>>>> >>>>>>>>> If that is the case, then would it be possible to install the >>>>>>>>> bundle(s) first and validate exported services against those >>>>>>>>> registered by the various bundles? >>>>>>>>> >>>>>>>>> Joe >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/27/10 2:16 PM, Alasdair Nottingham wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I think the simple answer is probably yes. I think it is called once >>>>>>>>>> to know how to resolve the application, and the second time because >>>>>>>>>> we have installed the framework. >>>>>>>>>> >>>>>>>>>> Alasdair >>>>>>>>>> >>>>>>>>>> On 27 Sep 2010, at 19:02, Joe Bohn<[email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> When processing an application (EBA) we parse all of the >>>>>>>>>>> blueprint.xml (including custom namespaces) as part of the >>>>>>>>>>> application processing for all bundles within the EBA. The net >>>>>>>>>>> result is that we do all of this parsing twice because we also must >>>>>>>>>>> parse and processes the information in the BlueprintContainer. >>>>>>>>>>> >>>>>>>>>>> Why is it necessary to parse the blueprint.xml during EBA >>>>>>>>>>> installation in the application module? >>>>>>>>>>> >>>>>>>>>>> I stumbled on this because I was making some modifications to a >>>>>>>>>>> custom namespace handler and noticed that it was being invoked >>>>>>>>>>> twice for the same elements. It seems that this is not desirable. >>>>>>>>>>> Should all namespace handlers be coded in such a way that they can >>>>>>>>>>> be invoked multiple times for the exact same elements? >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Joe >>>>>>>>>> >>>>>>> >>>>>>> >>>> >>>> >>> >>> >>> >>> -- >>> Alasdair Nottingham >>> [email protected] >>> >
