You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Aled Sage <al...@cloudsoftcorp.com> on 2019/12/02 10:38:58 UTC

Re: Brooklyn 1.0 is shaping up <-- karaf version bump

Hi all,

I see there was great progress with the karaf version bump last week and 
over the weekend, e.g. [1, 2].

Looking at brooklyn master karaf dependency versions using `find 
${BROOKLYN_HOME}/system/ -name "*.jar"` and running a little program to 
find multiple versions, I see the following concerning duplicates:

system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle: 
[1.2.2, 1.2]
system//javax/mail/mail: [1.4.7, 1.4.4]

The full list is:

system//org/ow2/asm/asm: [5.2, 7.1]
system//org/ow2/asm/asm-util: [5.2, 7.1]
system//org/ow2/asm/asm-tree: [5.2, 7.1]
system//org/ow2/asm/asm-analysis: [5.2, 7.1]
system//org/ow2/asm/asm-commons: [5.2, 7.1]
system//org/yaml/snakeyaml: [1.23, 1.17]
system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.jzlib: 
[1.1.3_2, 1.0.7_1]
system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okhttp: 
[3.4.1_1, 2.2.0_1]
system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okio: 
[1.9.0_1, 1.2.0_1]
system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle: 
[1.2.2, 1.2]
system//javax/mail/mail: [1.4.7, 1.4.4]
system//javax/ws/rs/javax.ws.rs-api: [2.0.1, 2.1.1]

Compare this with Brooklyn version 1.0.0-M1:

system//org/ow2/asm/asm-all: [5.2, 5.0.2]
system//org/yaml/snakeyaml: [1.17, 1.22]
system//org/apache/servicemix/specs/org.apache.servicemix.specs.activation-api-1.1: 
[2.5.0, 2.6.0]
system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.jzlib: 
[1.1.3_2, 1.0.7_1]
system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okhttp: 
[3.4.1_1, 2.2.0_1]
system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okio: 
[1.9.0_1, 1.2.0_1]
system//org/apache/aries/org.apache.aries.util: [1.1.3, 1.1.0]
system//com/google/code/gson/gson: [2.5, 2.3]

I'll take a look at these and see if they really are a problem or not.

Aled

[1] https://github.com/apache/brooklyn-server/pull/1068

[2] https://github.com/apache/brooklyn-server/pull/1069




On 02/12/2019 09:27, Aled Sage wrote:
> Hi,
>
> Thanks Ludo, all: - great list, and +1 from me.
>
> I think most of those sound fairly small and manageable.
>
> The one that stands out as potentially hard is the "Karaf version 
> bump" (which would fix the "Two different versions of jetty-server"). 
> We've had problems in the past getting all versions consistent, and 
> karaf to start up fast and cleanly (without it restarting a bunch of 
> bundles). Changing the version is really easy - getting all versions 
> of all bundles to be consistent can be a pain! But it's worth doing.
>
> Aled
>
>
> On 01/12/2019 14:47, Geoff Macartney wrote:
>> We should definitely include
>> https://issues.apache.org/jira/browse/BROOKLYN-597 "Remove MD5 and SHA-1
>> checksums" as part of 1.0.0.  I'd be happy to do this but I see it's got
>> you assigned to it Richard. Do you have work in progress on this, or 
>> would
>> you like me to look into it? I have a notion that I might polish up the
>> signing procedure a bit.
>>
>> Cheers
>> Geoff
>>
>> On Sun, 1 Dec 2019 at 14:13, Geoff Macartney <ge...@gmail.com>
>> wrote:
>>
>>> Hi Ludo,
>>>
>>> I am indeed pleased to see this!  I had been thinking of mailing the
>>> community again on the matter after Christmas was out of the way, 
>>> let's let
>>> 2020 be the year of Brooklyn 1.0.0!
>>>
>>> That's a great list of things to address. One thing to add would be
>>> removing some deprecated code. Do you think they are all small 
>>> changes, or
>>> do any require extensive work or have a wide impact?
>>>
>>> The reason I ask is that I think it would be good to restrict 
>>> ourselves to
>>> relatively easy and limited impact changes between now and 1.0.0. My 
>>> fear
>>> is that larger changes will take a longer time and push back a 
>>> release even
>>> further. It seems to me things are quite stable now; I'd say let's 
>>> polish
>>> it up and release it rather than try to make significant improvements.
>>>
>>> What does everyone think?
>>>
>>> Cheers
>>> Geoff
>>>
>>>
>>>
>>>
>>> On Thu, 28 Nov 2019 at 11:04, Ludovic Farine <lu...@cloudsoft.io> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> Hope you are all doing well!
>>>>
>>>> Christmas is fast approaching and well hopefully a gift we would 
>>>> all like
>>>> to have: Brooklyn 1.0.0 release :) Geoff would be pleased to hear!
>>>>
>>>> Working towards this goal of first official release, these are a 
>>>> few bug
>>>> fixes and improvements that I believe are worth considering
>>>> (non-exhaustive
>>>> and not ordered wishlist!) :
>>>>
>>>> Bug fixes:
>>>>
>>>>     -
>>>>
>>>>     Broken icon links for ELK and DNS entities
>>>>     -
>>>>
>>>>     REST API Swagger error
>>>>     -
>>>>
>>>>     Two different versions of jetty-server
>>>>     -
>>>>
>>>>     Karaf version bump
>>>>
>>>>
>>>> Improvements:
>>>>
>>>>     -
>>>>
>>>>     Session Management: introduce expiry settings for inactivity or
>>>> repeated
>>>>     background API calls
>>>>     -
>>>>
>>>>     User Experience: blueprints ordered by date deployed, cookies to
>>>>     remember preferred sort criteria and palette preferences
>>>>
>>>>
>>>> Clean-up:
>>>>
>>>>     -
>>>>
>>>>     Review existing open Pull Requests
>>>>     -
>>>>
>>>>     Fix most of the Jenkins tests
>>>>
>>>>
>>>> What are your thoughts on this scope? Any other suggestions you 
>>>> would like
>>>> to deliver in this next release?
>>>>
>>>> Looking forward to get the community engaging in the next weeks and
>>>> months.
>>>>
>>>> Remember you can participate with others on the official Slack channel
>>>> *#brooklyn* on the official Apache group. Sign up here
>>>> https://s.apache.org/slack-invite to join the discussion!
>>>>
>>>> Thanks
>>>>
>>>> Ludo
>>>>
>>>>
>>>> -- 
>>>>
>>>> Ludovic Farine
>>>>
>>>> Senior Technical Project Manager
>>>>
>>>>
>>>> Cloudsoft <https://cloudsoft.io/> | Bringing Business to the Cloud
>>>>
>>>> E: ludo@cloudsoft.io
>>>>
>>>> T: +44 7584 748013
>>>>
>>>> L: https://www.linkedin.com/in/ludovicfarine/
>>>>

Re: Brooklyn 1.0 is shaping up <-- karaf version bump

Posted by Geoff Macartney <ge...@gmail.com>.
That's brilliant news Aled,

I'm just catching up with this now, and first of all read the email you
sent describing the problem, and it sounded like a real nightmare. Glad to
hear you've got it working. Congrats on solving it!  What a fix though -
`javax.xml.bind*;version=!,` would confuse the life out of me if I came
across it in a pom.  If you're raising a PR for this can you put comments
that explain it a bit, and maybe link to the list archive of your email?

I remember wrestling with `dependency="true"` before now myself. That's a
nice explanation.

Best,
Geoff




On Thu, 5 Dec 2019 at 23:14, Aled Sage <al...@gmail.com> wrote:

> Hi all,
>
> Good news - I have it working. I need to do some more testing, and need
> to look at releasing winrm4j 0.8.0.
>
> I got some great pointers from the CXF mailing list (thanks Alexey
> Markevich!) [1].
>
> The solution is for winrm4j to include:
>
>        <plugin>
>          <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
>          <configuration>
>            <instructions>
>                <Import-Package>
>                  javax.xml.bind*;version=!,
>                  *
>                </Import-Package>
>            </instructions>
>          </configuration>
>        </plugin>
>
> This prevents the package-import for javax.xml.bind.annotation to not
> define a specific version range.
>
> ---
>
> The missing understanding for me was what dependency=true means [2].
>
> For example, in cxf-specs:
>
>      <bundle start-level="10"
>
> dependency="true">mvn:jakarta.xml.bind/jakarta.xml.bind-api/${cxf.jaxb.version}</bundle>
>
> It means that the bundle will only be installed if it is really needed -
> i.e. it provides packages that are not being exported by other bundles.
>
> Because winrm4j now had:
>
>      javax.xml.bind.annotation;version="[2.3,3)"
>
> It meant that the javax.xml.bind.annotation from
> org.apache.felix.framework didn't match. It needed jakarta.xml.bind-api
> to meet the package import dependency.
>
> By excluding the version range for javax.xml.bind.annotation, it was
> happy to just use org.apache.felix.framework.
>
> Aled
>
> [1]
>
> http://mail-archives.apache.org/mod_mbox/cxf-users/201912.mbox/%3C9a1d1ab6-8d00-234d-29b0-c86c31506c87%40gmail.com%3E
>
> [2]
>
> http://karaf.922171.n3.nabble.com/features-xml-dependency-quot-true-quot-td3286359.html
>
>
>
> On 04/12/2019 20:28, Aled Sage wrote:
> >
> > *T**_L;DR_*
> >
> > I was trying to upgrade to CXF 3.3.2 (from 3.2.8) because
> > https://karaf.apache.org/news.html announcement about Karaf 4.2.7
> > lists CXF version 3.3.2.
> >
> > But I've hit a big problem.
> >
> > winrm4j fails in Karaf with CXF 3.3.2: JAXB service construction fails
> > when parsing annotations.
> >
> > Should we abandon the CXF upgrade and stick with 3.2.8?
> >
> > I'll report it to the CXF mailing list, so perhaps reserve judgement
> > to see what they say.
> >
> > _*DETAILS OF ERROR*_
> >
> > The upgrade involved upgrading winrm4j to use CXF 3.3.2, which seemed
> > to go fine (all tests pass outside of Karaf).
> >
> > However, when I test use of WinRM inside Brooklyn Karaf, it fails with
> > the error below:
> >
> > ```
> > 2019-12-03T11:44:16,468 wmhGA3U2-[ut059oi7tk,ltajipcuun] WARN  103
> > i.c.w.c.WinRmClient [ager-Ak6FHXbO-32] Error creating WinRm service
> > with mbean strategy (trying other strategies):
> > org.apache.cxf.service.factory.ServiceConstructionException
> > org.apache.cxf.service.factory.ServiceConstructionException: null
> >         at
> > org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:355)
> > ~[!/:3.3.2]
> >         at
> >
> org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86)
>
> > ~[!/:3.3.2]
> >         at
> >
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:426)
>
> > ~[!/:3.3.2]
> >         at
> >
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:528)
>
> > ~[!/:3.3.2]
> >         at
> >
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:263)
>
> > ~[!/:3.3.2]
> >         at
> >
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
>
> > ~[?:?]
> >         at
> >
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
>
> > ~[!/:3.3.2]
> >         at
> >
> org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91)
> > ~[!/:3.3.2]
> >         at
> >
> org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:159)
>
> > ~[!/:3.3.2]
> >         at
> >
> org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142)
>
> > ~[?:?]
> >         at
> >
> org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:95)
>
> > ~[!/:3.3.2]
> >         at
> >
> io.cloudsoft.winrm4j.client.WinRmFactory.doCreateServiceWithBean(WinRmFactory.java:97)
>
> > ~[!/:?]
> >         at
> >
> io.cloudsoft.winrm4j.client.WinRmFactory.createService(WinRmFactory.java:33)
>
> > [!/:?]
> >         at
> >
> io.cloudsoft.winrm4j.client.WinRmFactory.newInstance(WinRmFactory.java:21)
> > [!/:?]
> >         at
> > io.cloudsoft.winrm4j.client.WinRmClient.getService(WinRmClient.java:191)
> > [!/:?]
> >         at
> > io.cloudsoft.winrm4j.client.WinRmClient.<init>(WinRmClient.java:172)
> > [!/:?]
> >         at
> >
> io.cloudsoft.winrm4j.client.WinRmClientBuilder.build(WinRmClientBuilder.java:194)
>
> > [!/:?]
> >         at
> > io.cloudsoft.winrm4j.winrm.WinRmTool.executeCommand(WinRmTool.java:298)
> > [!/:?]
> >         at
> > io.cloudsoft.winrm4j.winrm.WinRmTool.executeCommand(WinRmTool.java:216)
> > [!/:?]
> >         at
> >
> org.apache.brooklyn.util.core.internal.winrm.winrm4j.Winrm4jTool$1.apply(Winrm4jTool.java:119)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.util.core.internal.winrm.winrm4j.Winrm4jTool$1.apply(Winrm4jTool.java:117)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.util.core.internal.winrm.winrm4j.Winrm4jTool.exec(Winrm4jTool.java:185)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.util.core.internal.winrm.winrm4j.Winrm4jTool.executeCommand(Winrm4jTool.java:117)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.location.winrm.WinRmMachineLocation.executeCommand(WinRmMachineLocation.java:308)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.location.jclouds.JcloudsLocation$5.call(JcloudsLocation.java:2518)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.location.jclouds.JcloudsLocation$5.call(JcloudsLocation.java:2514)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.util.repeat.Repeater.runKeepingError(Repeater.java:399)
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.location.jclouds.JcloudsLocation.waitForReachable(JcloudsLocation.java:2741)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.location.jclouds.JcloudsLocation.waitForWinRmAvailable(JcloudsLocation.java:2567)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.location.jclouds.DefaultConnectivityResolver.checkCredential(DefaultConnectivityResolver.java:404)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.location.jclouds.DefaultConnectivityResolver.resolve(DefaultConnectivityResolver.java:196)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.location.jclouds.JcloudsLocation.obtainOnce(JcloudsLocation.java:807)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.location.jclouds.JcloudsLocation.obtain(JcloudsLocation.java:614)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ObtainLocationTask.call(MachineLifecycleEffectorTasks.java:448)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ObtainLocationTask.call(MachineLifecycleEffectorTasks.java:437)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.util.core.task.Tasks.withBlockingDetails(Tasks.java:114)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ProvisionMachineTask.call(MachineLifecycleEffectorTasks.java:418)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ProvisionMachineTask.call(MachineLifecycleEffectorTasks.java:393)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.util.core.task.DynamicSequentialTask$DstJob.call(DynamicSequentialTask.java:364)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at
> >
> org.apache.brooklyn.util.core.task.BasicExecutionManager$SubmissionCallable.call(BasicExecutionManager.java:565)
>
> > [!/:1.0.0-SNAPSHOT]
> >         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > [?:1.8.0_201]
> >         at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
> > [?:1.8.0_201]
> >         at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>
> > [?:1.8.0_201]
> >         at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]
> > Caused by:
> > com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException: 2
> > counts of IllegalAnnotationExceptions
> >         at
> >
> com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:91)
>
> > ~[?:1.8.0_201]
> >         at
> >
> com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:445)
>
> > ~[?:1.8.0_201]
> >         at
> >
> com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:277)
>
> > ~[?:1.8.0_201]
> >         at
> >
> com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:124)
>
> > ~[?:1.8.0_201]
> >         at
> >
> com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1123)
>
> > ~[?:1.8.0_201]
> >         at
> >
> com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:147)
>
> > ~[?:1.8.0_201]
> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > ~[?:1.8.0_201]
> >         at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> > ~[?:1.8.0_201]
> >         at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> > ~[?:1.8.0_201]
> >         at java.lang.reflect.Method.invoke(Method.java:498)
> ~[?:1.8.0_201]
> >         at
> > javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:222)
> > ~[?:1.8.0_201]
> >         at javax.xml.bind.ContextFinder.find(ContextFinder.java:396)
> > ~[?:1.8.0_201]
> >         at
> > javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:641)
> > ~[?:1.8.0_201]
> >         at
> >
> org.apache.cxf.common.jaxb.JAXBContextCache.createContext(JAXBContextCache.java:357)
>
> > ~[!/:3.3.2]
> >         at
> >
> org.apache.cxf.common.jaxb.JAXBContextCache.getCachedContextAndSchemas(JAXBContextCache.java:246)
>
> > ~[!/:3.3.2]
> >         at
> >
> org.apache.cxf.jaxb.JAXBDataBinding.createJAXBContextAndSchemas(JAXBDataBinding.java:498)
>
> > ~[!/:3.3.2]
> >         at
> > org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:353)
> > ~[!/:3.3.2]
> >         ... 43 more
> > ```
> >
> > Looking via a debugger to get the underlying
> > IllegalAnnotatoinExceptions, I see:
> > ```
> >
> ((com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException)e.getCause()).getErrors()
> >  (java.util.Collections$UnmodifiableRandomAccessList<E>) [Two classes
> > have the same XML type name
> > "{http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd}objectFactory". Use
> > @XmlType.name and @XmlType.namespace to assign different names to them.
> >     this problem is related to the following location:
> >         at io.cloudsoft.winrm4j.client.transfer.ObjectFactory
> >     this problem is related to the following location:
> >         at io.cloudsoft.winrm4j.client.wsman.ObjectFactory, Two
> > classes have the same XML type name
> > "{http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd}objectFactory". Use
> > @XmlType.name and @XmlType.namespace to assign different names to them.
> >     this problem is related to the following location:
> >         at io.cloudsoft.winrm4j.client.wsman.ObjectFactory
> >     this problem is related to the following location:
> >         at io.cloudsoft.winrm4j.client.shell.ObjectFactory]
> > ```
> >
> >
> > _*INVESTIGATION OF ERROR*_
> >
> > This thread gives some pointers:
> >
> https://stackoverflow.com/questions/7361336/two-classes-have-the-same-xml-type-name-objectfactory
> >
> > It suggests looking at how many javax.xml.bind.annotation.XMLRegistry
> > classes you have on your classpath.
> >
> > Via a debugger, I compared what happens in Karaf with CXF 3.3.2 and
> > CXF 3.2.8:
> >
> > ```
> >
> io.cloudsoft.winrm4j.client.wsman.ObjectFactory.class.getAnnotations()[0].annotationType()
> > [CXV 3.2.8 output] (java.lang.Class<T>) interface
> > javax.xml.bind.annotation.XmlRegistry
> > [CXV 3.3.2 output] (java.lang.Class<T>) interface
> > javax.xml.bind.annotation.XmlRegistry
> >
> >
> io.cloudsoft.winrm4j.client.wsman.ObjectFactory.class.getAnnotations()[0].annotationType().getClassLoader()
> > [CXV 3.2.8 output] null
> > [CXV 3.3.2 output]
> > (org.apache.felix.framework.BundleWiringImpl$BundleClassLoader)
> > jakarta.xml.bind-api [108]
> > ```
> >
> > I interpret the null classloader as meaning it is from the system
> > classloader (e.g. `java.lang.Object.class.getClassLoader()` also
> > returns `null`).
> >
> > Looking in Karaf using `bin/client` (with CXF 3.2.8):
> > ```
> > package:exports | grep javax.xml.bind.annotation
> > javax.xml.bind.annotation.adapters    │ 2.2.8    │ 0 │
> > org.apache.felix.framework
> > javax.xml.bind.annotation             │ 2.2.8    │ 0 │
> > org.apache.felix.framework
> >
> > package:imports | grep winrm | grep javax.xml.bind.annotation
> > Package                               │ Version │ Optional │ ID  │
> > Bundle Name
> > javax.xml.bind.annotation.adapters │        │          │ 103 │
> > io.cloudsoft.windows.winrm4j-client
> > javax.xml.bind.annotation │          │          │ 103 │
> > io.cloudsoft.windows.winrm4j-client
> > ```
> >
> > Compare that with CXF 3.3.2:
> > ```
> > package:exports | grep javax.xml.bind.annotation
> > javax.xml.bind.annotation.adapters    │ 2.2.8    │ 0 │
> > org.apache.felix.framework
> > javax.xml.bind.annotation.adapters    │ 2.3.2    │ 108 │
> > jakarta.xml.bind-api
> > javax.xml.bind.annotation             │ 2.2.8    │ 0 │
> > org.apache.felix.framework
> > javax.xml.bind.annotation             │ 2.3.2    │ 108 │
> > jakarta.xml.bind-api
> >
> > package:imports | grep winrm | grep javax.xml.bind.annotation
> > Package                               │ Version │ Optional │ ID  │
> > Bundle Name
> > javax.xml.bind.annotation.adapters │ [2.3.0,3.0.0) │          │ 103 │
> > io.cloudsoft.windows.winrm4j-client
> > javax.xml.bind.annotation │ [2.3.0,3.0.0) │          │ 103 │
> > io.cloudsoft.windows.winrm4j-client
> > ```
> >
> > Looking at where `jakarta.xml.bind-api` comes from in CXF 3.3.2 (it's
> > not there when we use CXF 3.2.8):
> > ```
> > feature:info cxf-specs
> >
> > Running feature:info cxf-specs
> > Feature cxf-specs 3.3.2
> > ...
> > Feature contains followed bundles:
> >   ...
> >   mvn:jakarta.xml.bind/jakarta.xml.bind-api/2.3.2 start-level=10
> > ```
> > (The cxf-specs feature is a dependency of the cxf-core feature.)
> >
> > Looking at the MANIFEST.mf (or the bundle:headers) of `winrm4j-client`:
> > With CXF 3.3.2, it has:
> > ```
> > javax.xml.bind.annotation;version="[2.3,3)"
> > ```
> > With CXF 3.2.8, it has:
> > ```
> > javax.xml.bind.annotation
> > ```
> > (i.e. no version range is specified).
> >
> > I don't think there are code changes causing this - I think it is
> > inferred from the CXF versions (or perhaps because newer maven plugin
> > versions are used?)
> >
> > But even if it didn't specify a version range with CXF 3.3.2, it would
> > prefer the import from the newer version (i.e. from 2.3.2).
> >
> >
> > _*NEXT STEPS*_
> >
> > We should report the issue on the CXF / Karaf mailing list - I'll do
> that.
> >
> > I lean towards not fixing it (unless the CXF community come back with
> > an easy answer).
> >
> > If we did try to fix it, possibilities include:
> >
> >  1. Change winrm4j bundle's package imports to require 2.2.x of
> >     javax.xml.bind.annotation.
> >     But would that be compatible with the rest of the CXF package
> imports?
> >  2. Or some other mechanism to force the annotation parsing to somehow
> >     use javax.xml.bind.annotation.XmlRegistry version 2.2.8 from
> >     org.apache.felix.framework?!
> >  3. Or try to force use of a particular `JAXBContext` - but winrm4j
> >     isn't instantiating the JAXBContext.
> >     (e.g. https://stackoverflow.com/a/7483425/1393883 tries to force a
> >     particular `META-INF/services/javax.xml.bind.JAXBContext` at the
> >     classloader level).
> >
> >
> > Option (2) feels really hard and risky - the feature `cxf-specs` is
> > pulling in `jakarta.xml.bind-api`, and `cxf-core` pulls in the feature
> > `cxf-specs`. That feels very low level! There could be untold
> > consequences of messing with the bind-api version at that level. Even
> > if our smoke tests pass, I'd be worried about what else we might have
> > broken.
> >
> > Option (1) gives me some of the same worries as for (2) - we'd be
> > importing a different javax.xml.bind.annotation compared to the
> > bundles that the CXF packages come from. That kind of thing can cause
> > weird ClassCastExceptions because things are using different
> classloaders.
> >
> > My gut feel for option (3) is that it's the wrong road to be going
> > down - it's fighting CXF rather than working with it!
> >
> >
> > _*MISCELLANEOUS DEBUGGING NOTES*_
> >
> > I find the script below useful to get a dump of all the features and
> > which bundles they bring in - I normally redirect the output to a file
> > and search through that:
> > ```
> > #!/bin/bash
> >
> > for i in `./bin/client "feature:list" | grep -v "Uninstalled" | awk
> > '{print $1}'`; do
> >     echo "Running feature:info ${i}"
> >     ./bin/client "feature:info ${i}"
> >     echo
> >     echo
> > done
> > ```
> >
> > On 02/12/2019 21:21, Geoff Macartney wrote:
> >> It's always a bit of a maze, isn't it!
> >>
> >> Thanks for looking into this Aled. I think it will be great to get
> >> things brought up to a consistent level with this latest Karaf.
> >>
> >> Cheers
> >> Geoff
> >>
> >>
> >>
> >> On Mon, 2 Dec 2019 at 13:28, Aled Sage <aled.sage@gmail.com
> >> <ma...@gmail.com>> wrote:
> >>
> >>     Hi all,
> >>
> >>     TL;DR: I'm looking at upgading CXF from 3.2.8 to 3.3.2.
> >>
> >>     ---
> >>
> >>     For dependency:
> >>          system//javax/mail/mail: [1.4.7, 1.4.4]
> >>
> >>     Exploring this one shows that v1.4.4 is coming from the old
> >>     cxf-specs
> >>     3.2.8. The Karaf 4.2.7 announcement [1] gives a table of versions
> >>     - it
> >>     shows CXF at 3.3.2. We should look up updating CXF from 3.2.8 to
> >>     3.3.2.
> >>
> >>     That will also require an upgrade of
> >>     mvn:io.cloudsoft.windows/winrm4j
> >>     (as v0.7.0 is built against CXF 3.2.8).
> >>
> >>     I'm looking into this, to see what else breaks when we switch to
> >>     CXF 3.3.2.
> >>
> >>     ---
> >>
> >>     I suggest we ignore:
> >>
>  system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle:
> >>
> >>     [1.2.2, 1.2]
> >>
> >>     Feature 'jetty' brings in v1.2.2, whereas feature 'pax-jetty'
> >>     brings in
> >>     v1.2, so it's out of our control.
> >>
> >>     Aled
> >>
> >>
> >>     On 02/12/2019 10:38, Aled Sage wrote:
> >>     > Hi all,
> >>     >
> >>     > I see there was great progress with the karaf version bump last
> >>     week
> >>     > and over the weekend, e.g. [1, 2].
> >>     >
> >>     > Looking at brooklyn master karaf dependency versions using `find
> >>     > ${BROOKLYN_HOME}/system/ -name "*.jar"` and running a little
> >>     program
> >>     > to find multiple versions, I see the following concerning
> >>     duplicates:
> >>     >
> >>     >
> >>
>  system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle:
> >>
> >>     > [1.2.2, 1.2]
> >>     > system//javax/mail/mail: [1.4.7, 1.4.4]
> >>     >
> >>     > The full list is:
> >>     >
> >>     > system//org/ow2/asm/asm: [5.2, 7.1]
> >>     > system//org/ow2/asm/asm-util: [5.2, 7.1]
> >>     > system//org/ow2/asm/asm-tree: [5.2, 7.1]
> >>     > system//org/ow2/asm/asm-analysis: [5.2, 7.1]
> >>     > system//org/ow2/asm/asm-commons: [5.2, 7.1]
> >>     > system//org/yaml/snakeyaml: [1.23, 1.17]
> >>     >
> >>
>  system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.jzlib:
> >>
> >>     > [1.1.3_2, 1.0.7_1]
> >>     >
> >>
>  system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okhttp:
> >>
> >>     > [3.4.1_1, 2.2.0_1]
> >>     >
> >>
>  system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okio:
> >>
> >>     > [1.9.0_1, 1.2.0_1]
> >>     >
> >>
>  system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle:
> >>
> >>     > [1.2.2, 1.2]
> >>     > system//javax/mail/mail: [1.4.7, 1.4.4]
> >>     > system//javax/ws/rs/javax.ws <http://javax.ws>.rs-api: [2.0.1,
> >>     2.1.1]
> >>     >
> >>     > Compare this with Brooklyn version 1.0.0-M1:
> >>     >
> >>     > system//org/ow2/asm/asm-all: [5.2, 5.0.2]
> >>     > system//org/yaml/snakeyaml: [1.17, 1.22]
> >>     >
> >>
>  system//org/apache/servicemix/specs/org.apache.servicemix.specs.activation-api-1.1:
> >>
> >>     > [2.5.0, 2.6.0]
> >>     >
> >>
>  system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.jzlib:
> >>
> >>     > [1.1.3_2, 1.0.7_1]
> >>     >
> >>
>  system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okhttp:
> >>
> >>     > [3.4.1_1, 2.2.0_1]
> >>     >
> >>
>  system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okio:
> >>
> >>     > [1.9.0_1, 1.2.0_1]
> >>     > system//org/apache/aries/org.apache.aries.util: [1.1.3, 1.1.0]
> >>     > system//com/google/code/gson/gson: [2.5, 2.3]
> >>     >
> >>     > I'll take a look at these and see if they really are a problem
> >>     or not.
> >>     >
> >>     > Aled
> >>     >
> >>     > [1] https://github.com/apache/brooklyn-server/pull/1068
> >>     >
> >>     > [2] https://github.com/apache/brooklyn-server/pull/1069
> >>     >
> >>     >
> >>     >
> >>     >
> >>     > On 02/12/2019 09:27, Aled Sage wrote:
> >>     >> Hi,
> >>     >>
> >>     >> Thanks Ludo, all: - great list, and +1 from me.
> >>     >>
> >>     >> I think most of those sound fairly small and manageable.
> >>     >>
> >>     >> The one that stands out as potentially hard is the "Karaf version
> >>     >> bump" (which would fix the "Two different versions of
> >>     jetty-server").
> >>     >> We've had problems in the past getting all versions
> >>     consistent, and
> >>     >> karaf to start up fast and cleanly (without it restarting a
> >>     bunch of
> >>     >> bundles). Changing the version is really easy - getting all
> >>     versions
> >>     >> of all bundles to be consistent can be a pain! But it's worth
> >>     doing.
> >>     >>
> >>     >> Aled
> >>     >>
> >>     >>
> >>     >> On 01/12/2019 14:47, Geoff Macartney wrote:
> >>     >>> We should definitely include
> >>     >>> https://issues.apache.org/jira/browse/BROOKLYN-597 "Remove
> >>     MD5 and
> >>     >>> SHA-1
> >>     >>> checksums" as part of 1.0.0.  I'd be happy to do this but I
> >>     see it's
> >>     >>> got
> >>     >>> you assigned to it Richard. Do you have work in progress on
> >>     this, or
> >>     >>> would
> >>     >>> you like me to look into it? I have a notion that I might
> >>     polish up the
> >>     >>> signing procedure a bit.
> >>     >>>
> >>     >>> Cheers
> >>     >>> Geoff
> >>     >>>
> >>     >>> On Sun, 1 Dec 2019 at 14:13, Geoff Macartney
> >>     >>> <geoff.macartney@gmail.com <ma...@gmail.com>>
> >>     >>> wrote:
> >>     >>>
> >>     >>>> Hi Ludo,
> >>     >>>>
> >>     >>>> I am indeed pleased to see this!  I had been thinking of
> >>     mailing the
> >>     >>>> community again on the matter after Christmas was out of the
> >>     way,
> >>     >>>> let's let
> >>     >>>> 2020 be the year of Brooklyn 1.0.0!
> >>     >>>>
> >>     >>>> That's a great list of things to address. One thing to add
> >>     would be
> >>     >>>> removing some deprecated code. Do you think they are all small
> >>     >>>> changes, or
> >>     >>>> do any require extensive work or have a wide impact?
> >>     >>>>
> >>     >>>> The reason I ask is that I think it would be good to restrict
> >>     >>>> ourselves to
> >>     >>>> relatively easy and limited impact changes between now and
> >>     1.0.0.
> >>     >>>> My fear
> >>     >>>> is that larger changes will take a longer time and push back a
> >>     >>>> release even
> >>     >>>> further. It seems to me things are quite stable now; I'd say
> >>     let's
> >>     >>>> polish
> >>     >>>> it up and release it rather than try to make significant
> >>     improvements.
> >>     >>>>
> >>     >>>> What does everyone think?
> >>     >>>>
> >>     >>>> Cheers
> >>     >>>> Geoff
> >>     >>>>
> >>     >>>>
> >>     >>>>
> >>     >>>>
> >>     >>>> On Thu, 28 Nov 2019 at 11:04, Ludovic Farine
> >>     <ludo@cloudsoft.io <ma...@cloudsoft.io>>
> >>     >>>> wrote:
> >>     >>>>
> >>     >>>>> Hi everyone,
> >>     >>>>>
> >>     >>>>> Hope you are all doing well!
> >>     >>>>>
> >>     >>>>> Christmas is fast approaching and well hopefully a gift we
> >>     would
> >>     >>>>> all like
> >>     >>>>> to have: Brooklyn 1.0.0 release :) Geoff would be pleased
> >>     to hear!
> >>     >>>>>
> >>     >>>>> Working towards this goal of first official release, these
> >>     are a
> >>     >>>>> few bug
> >>     >>>>> fixes and improvements that I believe are worth considering
> >>     >>>>> (non-exhaustive
> >>     >>>>> and not ordered wishlist!) :
> >>     >>>>>
> >>     >>>>> Bug fixes:
> >>     >>>>>
> >>     >>>>>     -
> >>     >>>>>
> >>     >>>>>     Broken icon links for ELK and DNS entities
> >>     >>>>>     -
> >>     >>>>>
> >>     >>>>>     REST API Swagger error
> >>     >>>>>     -
> >>     >>>>>
> >>     >>>>>     Two different versions of jetty-server
> >>     >>>>>     -
> >>     >>>>>
> >>     >>>>>     Karaf version bump
> >>     >>>>>
> >>     >>>>>
> >>     >>>>> Improvements:
> >>     >>>>>
> >>     >>>>>     -
> >>     >>>>>
> >>     >>>>>     Session Management: introduce expiry settings for
> >>     inactivity or
> >>     >>>>> repeated
> >>     >>>>>     background API calls
> >>     >>>>>     -
> >>     >>>>>
> >>     >>>>>     User Experience: blueprints ordered by date deployed,
> >>     cookies to
> >>     >>>>>     remember preferred sort criteria and palette preferences
> >>     >>>>>
> >>     >>>>>
> >>     >>>>> Clean-up:
> >>     >>>>>
> >>     >>>>>     -
> >>     >>>>>
> >>     >>>>>     Review existing open Pull Requests
> >>     >>>>>     -
> >>     >>>>>
> >>     >>>>>     Fix most of the Jenkins tests
> >>     >>>>>
> >>     >>>>>
> >>     >>>>> What are your thoughts on this scope? Any other suggestions
> >>     you
> >>     >>>>> would like
> >>     >>>>> to deliver in this next release?
> >>     >>>>>
> >>     >>>>> Looking forward to get the community engaging in the next
> >>     weeks and
> >>     >>>>> months.
> >>     >>>>>
> >>     >>>>> Remember you can participate with others on the official Slack
> >>     >>>>> channel
> >>     >>>>> *#brooklyn* on the official Apache group. Sign up here
> >>     >>>>> https://s.apache.org/slack-invite to join the discussion!
> >>     >>>>>
> >>     >>>>> Thanks
> >>     >>>>>
> >>     >>>>> Ludo
> >>     >>>>>
> >>     >>>>>
> >>     >>>>> --
> >>     >>>>>
> >>     >>>>> Ludovic Farine
> >>     >>>>>
> >>     >>>>> Senior Technical Project Manager
> >>     >>>>>
> >>     >>>>>
> >>     >>>>> Cloudsoft <https://cloudsoft.io/> | Bringing Business to
> >>     the Cloud
> >>     >>>>>
> >>     >>>>> E: ludo@cloudsoft.io <ma...@cloudsoft.io>
> >>     >>>>>
> >>     >>>>> T: +44 7584 748013
> >>     >>>>>
> >>     >>>>> L: https://www.linkedin.com/in/ludovicfarine/
> >>     >>>>>
> >>
>

Re: Brooklyn 1.0 is shaping up <-- karaf version bump

Posted by Aled Sage <al...@gmail.com>.
Hi all,

Good news - I have it working. I need to do some more testing, and need 
to look at releasing winrm4j 0.8.0.

I got some great pointers from the CXF mailing list (thanks Alexey 
Markevich!) [1].

The solution is for winrm4j to include:

       <plugin>
         <groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
         <configuration>
           <instructions>
               <Import-Package>
                 javax.xml.bind*;version=!,
                 *
               </Import-Package>
           </instructions>
         </configuration>
       </plugin>

This prevents the package-import for javax.xml.bind.annotation to not 
define a specific version range.

---

The missing understanding for me was what dependency=true means [2].

For example, in cxf-specs:

     <bundle start-level="10" 
dependency="true">mvn:jakarta.xml.bind/jakarta.xml.bind-api/${cxf.jaxb.version}</bundle>

It means that the bundle will only be installed if it is really needed - 
i.e. it provides packages that are not being exported by other bundles.

Because winrm4j now had:

     javax.xml.bind.annotation;version="[2.3,3)"

It meant that the javax.xml.bind.annotation from 
org.apache.felix.framework didn't match. It needed jakarta.xml.bind-api 
to meet the package import dependency.

By excluding the version range for javax.xml.bind.annotation, it was 
happy to just use org.apache.felix.framework.

Aled

[1] 
http://mail-archives.apache.org/mod_mbox/cxf-users/201912.mbox/%3C9a1d1ab6-8d00-234d-29b0-c86c31506c87%40gmail.com%3E

[2] 
http://karaf.922171.n3.nabble.com/features-xml-dependency-quot-true-quot-td3286359.html



On 04/12/2019 20:28, Aled Sage wrote:
>
> *T**_L;DR_*
>
> I was trying to upgrade to CXF 3.3.2 (from 3.2.8) because 
> https://karaf.apache.org/news.html announcement about Karaf 4.2.7 
> lists CXF version 3.3.2.
>
> But I've hit a big problem.
>
> winrm4j fails in Karaf with CXF 3.3.2: JAXB service construction fails 
> when parsing annotations.
>
> Should we abandon the CXF upgrade and stick with 3.2.8?
>
> I'll report it to the CXF mailing list, so perhaps reserve judgement 
> to see what they say.
>
> _*DETAILS OF ERROR*_
>
> The upgrade involved upgrading winrm4j to use CXF 3.3.2, which seemed 
> to go fine (all tests pass outside of Karaf).
>
> However, when I test use of WinRM inside Brooklyn Karaf, it fails with 
> the error below:
>
> ```
> 2019-12-03T11:44:16,468 wmhGA3U2-[ut059oi7tk,ltajipcuun] WARN  103 
> i.c.w.c.WinRmClient [ager-Ak6FHXbO-32] Error creating WinRm service 
> with mbean strategy (trying other strategies): 
> org.apache.cxf.service.factory.ServiceConstructionException
> org.apache.cxf.service.factory.ServiceConstructionException: null
>         at 
> org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:355) 
> ~[!/:3.3.2]
>         at 
> org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86) 
> ~[!/:3.3.2]
>         at 
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:426) 
> ~[!/:3.3.2]
>         at 
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:528) 
> ~[!/:3.3.2]
>         at 
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:263) 
> ~[!/:3.3.2]
>         at 
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199) 
> ~[?:?]
>         at 
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103) 
> ~[!/:3.3.2]
>         at 
> org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91) 
> ~[!/:3.3.2]
>         at 
> org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:159) 
> ~[!/:3.3.2]
>         at 
> org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142) 
> ~[?:?]
>         at 
> org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:95) 
> ~[!/:3.3.2]
>         at 
> io.cloudsoft.winrm4j.client.WinRmFactory.doCreateServiceWithBean(WinRmFactory.java:97) 
> ~[!/:?]
>         at 
> io.cloudsoft.winrm4j.client.WinRmFactory.createService(WinRmFactory.java:33) 
> [!/:?]
>         at 
> io.cloudsoft.winrm4j.client.WinRmFactory.newInstance(WinRmFactory.java:21) 
> [!/:?]
>         at 
> io.cloudsoft.winrm4j.client.WinRmClient.getService(WinRmClient.java:191) 
> [!/:?]
>         at 
> io.cloudsoft.winrm4j.client.WinRmClient.<init>(WinRmClient.java:172) 
> [!/:?]
>         at 
> io.cloudsoft.winrm4j.client.WinRmClientBuilder.build(WinRmClientBuilder.java:194) 
> [!/:?]
>         at 
> io.cloudsoft.winrm4j.winrm.WinRmTool.executeCommand(WinRmTool.java:298) 
> [!/:?]
>         at 
> io.cloudsoft.winrm4j.winrm.WinRmTool.executeCommand(WinRmTool.java:216) 
> [!/:?]
>         at 
> org.apache.brooklyn.util.core.internal.winrm.winrm4j.Winrm4jTool$1.apply(Winrm4jTool.java:119) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.util.core.internal.winrm.winrm4j.Winrm4jTool$1.apply(Winrm4jTool.java:117) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.util.core.internal.winrm.winrm4j.Winrm4jTool.exec(Winrm4jTool.java:185) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.util.core.internal.winrm.winrm4j.Winrm4jTool.executeCommand(Winrm4jTool.java:117) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.location.winrm.WinRmMachineLocation.executeCommand(WinRmMachineLocation.java:308) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.location.jclouds.JcloudsLocation$5.call(JcloudsLocation.java:2518) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.location.jclouds.JcloudsLocation$5.call(JcloudsLocation.java:2514) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.util.repeat.Repeater.runKeepingError(Repeater.java:399) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.location.jclouds.JcloudsLocation.waitForReachable(JcloudsLocation.java:2741) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.location.jclouds.JcloudsLocation.waitForWinRmAvailable(JcloudsLocation.java:2567) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.location.jclouds.DefaultConnectivityResolver.checkCredential(DefaultConnectivityResolver.java:404) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.location.jclouds.DefaultConnectivityResolver.resolve(DefaultConnectivityResolver.java:196) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.location.jclouds.JcloudsLocation.obtainOnce(JcloudsLocation.java:807) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.location.jclouds.JcloudsLocation.obtain(JcloudsLocation.java:614) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ObtainLocationTask.call(MachineLifecycleEffectorTasks.java:448) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ObtainLocationTask.call(MachineLifecycleEffectorTasks.java:437) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.util.core.task.Tasks.withBlockingDetails(Tasks.java:114) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ProvisionMachineTask.call(MachineLifecycleEffectorTasks.java:418) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ProvisionMachineTask.call(MachineLifecycleEffectorTasks.java:393) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.util.core.task.DynamicSequentialTask$DstJob.call(DynamicSequentialTask.java:364) 
> [!/:1.0.0-SNAPSHOT]
>         at 
> org.apache.brooklyn.util.core.task.BasicExecutionManager$SubmissionCallable.call(BasicExecutionManager.java:565) 
> [!/:1.0.0-SNAPSHOT]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [?:1.8.0_201]
>         at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
> [?:1.8.0_201]
>         at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
> [?:1.8.0_201]
>         at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]
> Caused by: 
> com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException: 2 
> counts of IllegalAnnotationExceptions
>         at 
> com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:91) 
> ~[?:1.8.0_201]
>         at 
> com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:445) 
> ~[?:1.8.0_201]
>         at 
> com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:277) 
> ~[?:1.8.0_201]
>         at 
> com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:124) 
> ~[?:1.8.0_201]
>         at 
> com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1123) 
> ~[?:1.8.0_201]
>         at 
> com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:147) 
> ~[?:1.8.0_201]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[?:1.8.0_201]
>         at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[?:1.8.0_201]
>         at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
> ~[?:1.8.0_201]
>         at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_201]
>         at 
> javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:222) 
> ~[?:1.8.0_201]
>         at javax.xml.bind.ContextFinder.find(ContextFinder.java:396) 
> ~[?:1.8.0_201]
>         at 
> javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:641) 
> ~[?:1.8.0_201]
>         at 
> org.apache.cxf.common.jaxb.JAXBContextCache.createContext(JAXBContextCache.java:357) 
> ~[!/:3.3.2]
>         at 
> org.apache.cxf.common.jaxb.JAXBContextCache.getCachedContextAndSchemas(JAXBContextCache.java:246) 
> ~[!/:3.3.2]
>         at 
> org.apache.cxf.jaxb.JAXBDataBinding.createJAXBContextAndSchemas(JAXBDataBinding.java:498) 
> ~[!/:3.3.2]
>         at 
> org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:353) 
> ~[!/:3.3.2]
>         ... 43 more
> ```
>
> Looking via a debugger to get the underlying 
> IllegalAnnotatoinExceptions, I see:
> ```
> ((com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException)e.getCause()).getErrors()
>  (java.util.Collections$UnmodifiableRandomAccessList<E>) [Two classes 
> have the same XML type name 
> "{http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd}objectFactory". Use 
> @XmlType.name and @XmlType.namespace to assign different names to them.
>     this problem is related to the following location:
>         at io.cloudsoft.winrm4j.client.transfer.ObjectFactory
>     this problem is related to the following location:
>         at io.cloudsoft.winrm4j.client.wsman.ObjectFactory, Two 
> classes have the same XML type name 
> "{http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd}objectFactory". Use 
> @XmlType.name and @XmlType.namespace to assign different names to them.
>     this problem is related to the following location:
>         at io.cloudsoft.winrm4j.client.wsman.ObjectFactory
>     this problem is related to the following location:
>         at io.cloudsoft.winrm4j.client.shell.ObjectFactory]
> ```
>
>
> _*INVESTIGATION OF ERROR*_
>
> This thread gives some pointers: 
> https://stackoverflow.com/questions/7361336/two-classes-have-the-same-xml-type-name-objectfactory
>
> It suggests looking at how many javax.xml.bind.annotation.XMLRegistry 
> classes you have on your classpath.
>
> Via a debugger, I compared what happens in Karaf with CXF 3.3.2 and 
> CXF 3.2.8:
>
> ```
> io.cloudsoft.winrm4j.client.wsman.ObjectFactory.class.getAnnotations()[0].annotationType()
> [CXV 3.2.8 output] (java.lang.Class<T>) interface 
> javax.xml.bind.annotation.XmlRegistry
> [CXV 3.3.2 output] (java.lang.Class<T>) interface 
> javax.xml.bind.annotation.XmlRegistry
>
> io.cloudsoft.winrm4j.client.wsman.ObjectFactory.class.getAnnotations()[0].annotationType().getClassLoader()
> [CXV 3.2.8 output] null
> [CXV 3.3.2 output] 
> (org.apache.felix.framework.BundleWiringImpl$BundleClassLoader) 
> jakarta.xml.bind-api [108]
> ```
>
> I interpret the null classloader as meaning it is from the system 
> classloader (e.g. `java.lang.Object.class.getClassLoader()` also 
> returns `null`).
>
> Looking in Karaf using `bin/client` (with CXF 3.2.8):
> ```
> package:exports | grep javax.xml.bind.annotation
> javax.xml.bind.annotation.adapters    │ 2.2.8    │ 0 │ 
> org.apache.felix.framework
> javax.xml.bind.annotation             │ 2.2.8    │ 0 │ 
> org.apache.felix.framework
>
> package:imports | grep winrm | grep javax.xml.bind.annotation
> Package                               │ Version │ Optional │ ID  │ 
> Bundle Name
> javax.xml.bind.annotation.adapters │        │          │ 103 │ 
> io.cloudsoft.windows.winrm4j-client
> javax.xml.bind.annotation │          │          │ 103 │ 
> io.cloudsoft.windows.winrm4j-client
> ```
>
> Compare that with CXF 3.3.2:
> ```
> package:exports | grep javax.xml.bind.annotation
> javax.xml.bind.annotation.adapters    │ 2.2.8    │ 0 │ 
> org.apache.felix.framework
> javax.xml.bind.annotation.adapters    │ 2.3.2    │ 108 │ 
> jakarta.xml.bind-api
> javax.xml.bind.annotation             │ 2.2.8    │ 0 │ 
> org.apache.felix.framework
> javax.xml.bind.annotation             │ 2.3.2    │ 108 │ 
> jakarta.xml.bind-api
>
> package:imports | grep winrm | grep javax.xml.bind.annotation
> Package                               │ Version │ Optional │ ID  │ 
> Bundle Name
> javax.xml.bind.annotation.adapters │ [2.3.0,3.0.0) │          │ 103 │ 
> io.cloudsoft.windows.winrm4j-client
> javax.xml.bind.annotation │ [2.3.0,3.0.0) │          │ 103 │ 
> io.cloudsoft.windows.winrm4j-client
> ```
>
> Looking at where `jakarta.xml.bind-api` comes from in CXF 3.3.2 (it's 
> not there when we use CXF 3.2.8):
> ```
> feature:info cxf-specs
>
> Running feature:info cxf-specs
> Feature cxf-specs 3.3.2
> ...
> Feature contains followed bundles:
>   ...
>   mvn:jakarta.xml.bind/jakarta.xml.bind-api/2.3.2 start-level=10
> ```
> (The cxf-specs feature is a dependency of the cxf-core feature.)
>
> Looking at the MANIFEST.mf (or the bundle:headers) of `winrm4j-client`:
> With CXF 3.3.2, it has:
> ```
> javax.xml.bind.annotation;version="[2.3,3)"
> ```
> With CXF 3.2.8, it has:
> ```
> javax.xml.bind.annotation
> ```
> (i.e. no version range is specified).
>
> I don't think there are code changes causing this - I think it is 
> inferred from the CXF versions (or perhaps because newer maven plugin 
> versions are used?)
>
> But even if it didn't specify a version range with CXF 3.3.2, it would 
> prefer the import from the newer version (i.e. from 2.3.2).
>
>
> _*NEXT STEPS*_
>
> We should report the issue on the CXF / Karaf mailing list - I'll do that.
>
> I lean towards not fixing it (unless the CXF community come back with 
> an easy answer).
>
> If we did try to fix it, possibilities include:
>
>  1. Change winrm4j bundle's package imports to require 2.2.x of
>     javax.xml.bind.annotation.
>     But would that be compatible with the rest of the CXF package imports?
>  2. Or some other mechanism to force the annotation parsing to somehow
>     use javax.xml.bind.annotation.XmlRegistry version 2.2.8 from
>     org.apache.felix.framework?!
>  3. Or try to force use of a particular `JAXBContext` - but winrm4j
>     isn't instantiating the JAXBContext.
>     (e.g. https://stackoverflow.com/a/7483425/1393883 tries to force a
>     particular `META-INF/services/javax.xml.bind.JAXBContext` at the
>     classloader level).
>
>
> Option (2) feels really hard and risky - the feature `cxf-specs` is 
> pulling in `jakarta.xml.bind-api`, and `cxf-core` pulls in the feature 
> `cxf-specs`. That feels very low level! There could be untold 
> consequences of messing with the bind-api version at that level. Even 
> if our smoke tests pass, I'd be worried about what else we might have 
> broken.
>
> Option (1) gives me some of the same worries as for (2) - we'd be 
> importing a different javax.xml.bind.annotation compared to the 
> bundles that the CXF packages come from. That kind of thing can cause 
> weird ClassCastExceptions because things are using different classloaders.
>
> My gut feel for option (3) is that it's the wrong road to be going 
> down - it's fighting CXF rather than working with it!
>
>
> _*MISCELLANEOUS DEBUGGING NOTES*_
>
> I find the script below useful to get a dump of all the features and 
> which bundles they bring in - I normally redirect the output to a file 
> and search through that:
> ```
> #!/bin/bash
>
> for i in `./bin/client "feature:list" | grep -v "Uninstalled" | awk 
> '{print $1}'`; do
>     echo "Running feature:info ${i}"
>     ./bin/client "feature:info ${i}"
>     echo
>     echo
> done
> ```
>
> On 02/12/2019 21:21, Geoff Macartney wrote:
>> It's always a bit of a maze, isn't it!
>>
>> Thanks for looking into this Aled. I think it will be great to get 
>> things brought up to a consistent level with this latest Karaf.
>>
>> Cheers
>> Geoff
>>
>>
>>
>> On Mon, 2 Dec 2019 at 13:28, Aled Sage <aled.sage@gmail.com 
>> <ma...@gmail.com>> wrote:
>>
>>     Hi all,
>>
>>     TL;DR: I'm looking at upgading CXF from 3.2.8 to 3.3.2.
>>
>>     ---
>>
>>     For dependency:
>>          system//javax/mail/mail: [1.4.7, 1.4.4]
>>
>>     Exploring this one shows that v1.4.4 is coming from the old
>>     cxf-specs
>>     3.2.8. The Karaf 4.2.7 announcement [1] gives a table of versions
>>     - it
>>     shows CXF at 3.3.2. We should look up updating CXF from 3.2.8 to
>>     3.3.2.
>>
>>     That will also require an upgrade of
>>     mvn:io.cloudsoft.windows/winrm4j
>>     (as v0.7.0 is built against CXF 3.2.8).
>>
>>     I'm looking into this, to see what else breaks when we switch to
>>     CXF 3.3.2.
>>
>>     ---
>>
>>     I suggest we ignore:
>>     system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle:
>>
>>     [1.2.2, 1.2]
>>
>>     Feature 'jetty' brings in v1.2.2, whereas feature 'pax-jetty'
>>     brings in
>>     v1.2, so it's out of our control.
>>
>>     Aled
>>
>>
>>     On 02/12/2019 10:38, Aled Sage wrote:
>>     > Hi all,
>>     >
>>     > I see there was great progress with the karaf version bump last
>>     week
>>     > and over the weekend, e.g. [1, 2].
>>     >
>>     > Looking at brooklyn master karaf dependency versions using `find
>>     > ${BROOKLYN_HOME}/system/ -name "*.jar"` and running a little
>>     program
>>     > to find multiple versions, I see the following concerning
>>     duplicates:
>>     >
>>     >
>>     system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle:
>>
>>     > [1.2.2, 1.2]
>>     > system//javax/mail/mail: [1.4.7, 1.4.4]
>>     >
>>     > The full list is:
>>     >
>>     > system//org/ow2/asm/asm: [5.2, 7.1]
>>     > system//org/ow2/asm/asm-util: [5.2, 7.1]
>>     > system//org/ow2/asm/asm-tree: [5.2, 7.1]
>>     > system//org/ow2/asm/asm-analysis: [5.2, 7.1]
>>     > system//org/ow2/asm/asm-commons: [5.2, 7.1]
>>     > system//org/yaml/snakeyaml: [1.23, 1.17]
>>     >
>>     system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.jzlib:
>>
>>     > [1.1.3_2, 1.0.7_1]
>>     >
>>     system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okhttp:
>>
>>     > [3.4.1_1, 2.2.0_1]
>>     >
>>     system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okio:
>>
>>     > [1.9.0_1, 1.2.0_1]
>>     >
>>     system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle:
>>
>>     > [1.2.2, 1.2]
>>     > system//javax/mail/mail: [1.4.7, 1.4.4]
>>     > system//javax/ws/rs/javax.ws <http://javax.ws>.rs-api: [2.0.1,
>>     2.1.1]
>>     >
>>     > Compare this with Brooklyn version 1.0.0-M1:
>>     >
>>     > system//org/ow2/asm/asm-all: [5.2, 5.0.2]
>>     > system//org/yaml/snakeyaml: [1.17, 1.22]
>>     >
>>     system//org/apache/servicemix/specs/org.apache.servicemix.specs.activation-api-1.1:
>>
>>     > [2.5.0, 2.6.0]
>>     >
>>     system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.jzlib:
>>
>>     > [1.1.3_2, 1.0.7_1]
>>     >
>>     system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okhttp:
>>
>>     > [3.4.1_1, 2.2.0_1]
>>     >
>>     system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okio:
>>
>>     > [1.9.0_1, 1.2.0_1]
>>     > system//org/apache/aries/org.apache.aries.util: [1.1.3, 1.1.0]
>>     > system//com/google/code/gson/gson: [2.5, 2.3]
>>     >
>>     > I'll take a look at these and see if they really are a problem
>>     or not.
>>     >
>>     > Aled
>>     >
>>     > [1] https://github.com/apache/brooklyn-server/pull/1068
>>     >
>>     > [2] https://github.com/apache/brooklyn-server/pull/1069
>>     >
>>     >
>>     >
>>     >
>>     > On 02/12/2019 09:27, Aled Sage wrote:
>>     >> Hi,
>>     >>
>>     >> Thanks Ludo, all: - great list, and +1 from me.
>>     >>
>>     >> I think most of those sound fairly small and manageable.
>>     >>
>>     >> The one that stands out as potentially hard is the "Karaf version
>>     >> bump" (which would fix the "Two different versions of
>>     jetty-server").
>>     >> We've had problems in the past getting all versions
>>     consistent, and
>>     >> karaf to start up fast and cleanly (without it restarting a
>>     bunch of
>>     >> bundles). Changing the version is really easy - getting all
>>     versions
>>     >> of all bundles to be consistent can be a pain! But it's worth
>>     doing.
>>     >>
>>     >> Aled
>>     >>
>>     >>
>>     >> On 01/12/2019 14:47, Geoff Macartney wrote:
>>     >>> We should definitely include
>>     >>> https://issues.apache.org/jira/browse/BROOKLYN-597 "Remove
>>     MD5 and
>>     >>> SHA-1
>>     >>> checksums" as part of 1.0.0.  I'd be happy to do this but I
>>     see it's
>>     >>> got
>>     >>> you assigned to it Richard. Do you have work in progress on
>>     this, or
>>     >>> would
>>     >>> you like me to look into it? I have a notion that I might
>>     polish up the
>>     >>> signing procedure a bit.
>>     >>>
>>     >>> Cheers
>>     >>> Geoff
>>     >>>
>>     >>> On Sun, 1 Dec 2019 at 14:13, Geoff Macartney
>>     >>> <geoff.macartney@gmail.com <ma...@gmail.com>>
>>     >>> wrote:
>>     >>>
>>     >>>> Hi Ludo,
>>     >>>>
>>     >>>> I am indeed pleased to see this!  I had been thinking of
>>     mailing the
>>     >>>> community again on the matter after Christmas was out of the
>>     way,
>>     >>>> let's let
>>     >>>> 2020 be the year of Brooklyn 1.0.0!
>>     >>>>
>>     >>>> That's a great list of things to address. One thing to add
>>     would be
>>     >>>> removing some deprecated code. Do you think they are all small
>>     >>>> changes, or
>>     >>>> do any require extensive work or have a wide impact?
>>     >>>>
>>     >>>> The reason I ask is that I think it would be good to restrict
>>     >>>> ourselves to
>>     >>>> relatively easy and limited impact changes between now and
>>     1.0.0.
>>     >>>> My fear
>>     >>>> is that larger changes will take a longer time and push back a
>>     >>>> release even
>>     >>>> further. It seems to me things are quite stable now; I'd say
>>     let's
>>     >>>> polish
>>     >>>> it up and release it rather than try to make significant
>>     improvements.
>>     >>>>
>>     >>>> What does everyone think?
>>     >>>>
>>     >>>> Cheers
>>     >>>> Geoff
>>     >>>>
>>     >>>>
>>     >>>>
>>     >>>>
>>     >>>> On Thu, 28 Nov 2019 at 11:04, Ludovic Farine
>>     <ludo@cloudsoft.io <ma...@cloudsoft.io>>
>>     >>>> wrote:
>>     >>>>
>>     >>>>> Hi everyone,
>>     >>>>>
>>     >>>>> Hope you are all doing well!
>>     >>>>>
>>     >>>>> Christmas is fast approaching and well hopefully a gift we
>>     would
>>     >>>>> all like
>>     >>>>> to have: Brooklyn 1.0.0 release :) Geoff would be pleased
>>     to hear!
>>     >>>>>
>>     >>>>> Working towards this goal of first official release, these
>>     are a
>>     >>>>> few bug
>>     >>>>> fixes and improvements that I believe are worth considering
>>     >>>>> (non-exhaustive
>>     >>>>> and not ordered wishlist!) :
>>     >>>>>
>>     >>>>> Bug fixes:
>>     >>>>>
>>     >>>>>     -
>>     >>>>>
>>     >>>>>     Broken icon links for ELK and DNS entities
>>     >>>>>     -
>>     >>>>>
>>     >>>>>     REST API Swagger error
>>     >>>>>     -
>>     >>>>>
>>     >>>>>     Two different versions of jetty-server
>>     >>>>>     -
>>     >>>>>
>>     >>>>>     Karaf version bump
>>     >>>>>
>>     >>>>>
>>     >>>>> Improvements:
>>     >>>>>
>>     >>>>>     -
>>     >>>>>
>>     >>>>>     Session Management: introduce expiry settings for
>>     inactivity or
>>     >>>>> repeated
>>     >>>>>     background API calls
>>     >>>>>     -
>>     >>>>>
>>     >>>>>     User Experience: blueprints ordered by date deployed,
>>     cookies to
>>     >>>>>     remember preferred sort criteria and palette preferences
>>     >>>>>
>>     >>>>>
>>     >>>>> Clean-up:
>>     >>>>>
>>     >>>>>     -
>>     >>>>>
>>     >>>>>     Review existing open Pull Requests
>>     >>>>>     -
>>     >>>>>
>>     >>>>>     Fix most of the Jenkins tests
>>     >>>>>
>>     >>>>>
>>     >>>>> What are your thoughts on this scope? Any other suggestions
>>     you
>>     >>>>> would like
>>     >>>>> to deliver in this next release?
>>     >>>>>
>>     >>>>> Looking forward to get the community engaging in the next
>>     weeks and
>>     >>>>> months.
>>     >>>>>
>>     >>>>> Remember you can participate with others on the official Slack
>>     >>>>> channel
>>     >>>>> *#brooklyn* on the official Apache group. Sign up here
>>     >>>>> https://s.apache.org/slack-invite to join the discussion!
>>     >>>>>
>>     >>>>> Thanks
>>     >>>>>
>>     >>>>> Ludo
>>     >>>>>
>>     >>>>>
>>     >>>>> --
>>     >>>>>
>>     >>>>> Ludovic Farine
>>     >>>>>
>>     >>>>> Senior Technical Project Manager
>>     >>>>>
>>     >>>>>
>>     >>>>> Cloudsoft <https://cloudsoft.io/> | Bringing Business to
>>     the Cloud
>>     >>>>>
>>     >>>>> E: ludo@cloudsoft.io <ma...@cloudsoft.io>
>>     >>>>>
>>     >>>>> T: +44 7584 748013
>>     >>>>>
>>     >>>>> L: https://www.linkedin.com/in/ludovicfarine/
>>     >>>>>
>>

Re: Brooklyn 1.0 is shaping up <-- karaf version bump

Posted by Aled Sage <al...@gmail.com>.
*T**_L;DR_*

I was trying to upgrade to CXF 3.3.2 (from 3.2.8) because 
https://karaf.apache.org/news.html announcement about Karaf 4.2.7 lists 
CXF version 3.3.2.

But I've hit a big problem.

winrm4j fails in Karaf with CXF 3.3.2: JAXB service construction fails 
when parsing annotations.

Should we abandon the CXF upgrade and stick with 3.2.8?

I'll report it to the CXF mailing list, so perhaps reserve judgement to 
see what they say.

_*DETAILS OF ERROR*_

The upgrade involved upgrading winrm4j to use CXF 3.3.2, which seemed to 
go fine (all tests pass outside of Karaf).

However, when I test use of WinRM inside Brooklyn Karaf, it fails with 
the error below:

```
2019-12-03T11:44:16,468 wmhGA3U2-[ut059oi7tk,ltajipcuun] WARN 103 
i.c.w.c.WinRmClient [ager-Ak6FHXbO-32] Error creating WinRm service with 
mbean strategy (trying other strategies): 
org.apache.cxf.service.factory.ServiceConstructionException
org.apache.cxf.service.factory.ServiceConstructionException: null
         at 
org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:355) 
~[!/:3.3.2]
         at 
org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86) 
~[!/:3.3.2]
         at 
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:426) 
~[!/:3.3.2]
         at 
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:528) 
~[!/:3.3.2]
         at 
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:263) 
~[!/:3.3.2]
         at 
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199) 
~[?:?]
         at 
org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103) 
~[!/:3.3.2]
         at 
org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91) 
~[!/:3.3.2]
         at 
org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:159) 
~[!/:3.3.2]
         at 
org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142) 
~[?:?]
         at 
org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:95) 
~[!/:3.3.2]
         at 
io.cloudsoft.winrm4j.client.WinRmFactory.doCreateServiceWithBean(WinRmFactory.java:97) 
~[!/:?]
         at 
io.cloudsoft.winrm4j.client.WinRmFactory.createService(WinRmFactory.java:33) 
[!/:?]
         at 
io.cloudsoft.winrm4j.client.WinRmFactory.newInstance(WinRmFactory.java:21) 
[!/:?]
         at 
io.cloudsoft.winrm4j.client.WinRmClient.getService(WinRmClient.java:191) 
[!/:?]
         at 
io.cloudsoft.winrm4j.client.WinRmClient.<init>(WinRmClient.java:172) [!/:?]
         at 
io.cloudsoft.winrm4j.client.WinRmClientBuilder.build(WinRmClientBuilder.java:194) 
[!/:?]
         at 
io.cloudsoft.winrm4j.winrm.WinRmTool.executeCommand(WinRmTool.java:298) 
[!/:?]
         at 
io.cloudsoft.winrm4j.winrm.WinRmTool.executeCommand(WinRmTool.java:216) 
[!/:?]
         at 
org.apache.brooklyn.util.core.internal.winrm.winrm4j.Winrm4jTool$1.apply(Winrm4jTool.java:119) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.util.core.internal.winrm.winrm4j.Winrm4jTool$1.apply(Winrm4jTool.java:117) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.util.core.internal.winrm.winrm4j.Winrm4jTool.exec(Winrm4jTool.java:185) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.util.core.internal.winrm.winrm4j.Winrm4jTool.executeCommand(Winrm4jTool.java:117) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.location.winrm.WinRmMachineLocation.executeCommand(WinRmMachineLocation.java:308) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.location.jclouds.JcloudsLocation$5.call(JcloudsLocation.java:2518) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.location.jclouds.JcloudsLocation$5.call(JcloudsLocation.java:2514) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.util.repeat.Repeater.runKeepingError(Repeater.java:399) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.location.jclouds.JcloudsLocation.waitForReachable(JcloudsLocation.java:2741) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.location.jclouds.JcloudsLocation.waitForWinRmAvailable(JcloudsLocation.java:2567) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.location.jclouds.DefaultConnectivityResolver.checkCredential(DefaultConnectivityResolver.java:404) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.location.jclouds.DefaultConnectivityResolver.resolve(DefaultConnectivityResolver.java:196) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.location.jclouds.JcloudsLocation.obtainOnce(JcloudsLocation.java:807) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.location.jclouds.JcloudsLocation.obtain(JcloudsLocation.java:614) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ObtainLocationTask.call(MachineLifecycleEffectorTasks.java:448) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ObtainLocationTask.call(MachineLifecycleEffectorTasks.java:437) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.util.core.task.Tasks.withBlockingDetails(Tasks.java:114) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ProvisionMachineTask.call(MachineLifecycleEffectorTasks.java:418) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ProvisionMachineTask.call(MachineLifecycleEffectorTasks.java:393) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.util.core.task.DynamicSequentialTask$DstJob.call(DynamicSequentialTask.java:364) 
[!/:1.0.0-SNAPSHOT]
         at 
org.apache.brooklyn.util.core.task.BasicExecutionManager$SubmissionCallable.call(BasicExecutionManager.java:565) 
[!/:1.0.0-SNAPSHOT]
         at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
[?:1.8.0_201]
         at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
[?:1.8.0_201]
         at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
[?:1.8.0_201]
         at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]
Caused by: 
com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException: 2 
counts of IllegalAnnotationExceptions
         at 
com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:91) 
~[?:1.8.0_201]
         at 
com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:445) 
~[?:1.8.0_201]
         at 
com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:277) 
~[?:1.8.0_201]
         at 
com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:124) 
~[?:1.8.0_201]
         at 
com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1123) 
~[?:1.8.0_201]
         at 
com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:147) 
~[?:1.8.0_201]
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
~[?:1.8.0_201]
         at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
~[?:1.8.0_201]
         at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
~[?:1.8.0_201]
         at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_201]
         at 
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:222) 
~[?:1.8.0_201]
         at javax.xml.bind.ContextFinder.find(ContextFinder.java:396) 
~[?:1.8.0_201]
         at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:641) 
~[?:1.8.0_201]
         at 
org.apache.cxf.common.jaxb.JAXBContextCache.createContext(JAXBContextCache.java:357) 
~[!/:3.3.2]
         at 
org.apache.cxf.common.jaxb.JAXBContextCache.getCachedContextAndSchemas(JAXBContextCache.java:246) 
~[!/:3.3.2]
         at 
org.apache.cxf.jaxb.JAXBDataBinding.createJAXBContextAndSchemas(JAXBDataBinding.java:498) 
~[!/:3.3.2]
         at 
org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:353) 
~[!/:3.3.2]
         ... 43 more
```

Looking via a debugger to get the underlying 
IllegalAnnotatoinExceptions, I see:
```
((com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException)e.getCause()).getErrors()
  (java.util.Collections$UnmodifiableRandomAccessList<E>) [Two classes 
have the same XML type name 
"{http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd}objectFactory". Use 
@XmlType.name and @XmlType.namespace to assign different names to them.
     this problem is related to the following location:
         at io.cloudsoft.winrm4j.client.transfer.ObjectFactory
     this problem is related to the following location:
         at io.cloudsoft.winrm4j.client.wsman.ObjectFactory, Two classes 
have the same XML type name 
"{http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd}objectFactory". Use 
@XmlType.name and @XmlType.namespace to assign different names to them.
     this problem is related to the following location:
         at io.cloudsoft.winrm4j.client.wsman.ObjectFactory
     this problem is related to the following location:
         at io.cloudsoft.winrm4j.client.shell.ObjectFactory]
```


_*INVESTIGATION OF ERROR*_

This thread gives some pointers: 
https://stackoverflow.com/questions/7361336/two-classes-have-the-same-xml-type-name-objectfactory

It suggests looking at how many javax.xml.bind.annotation.XMLRegistry 
classes you have on your classpath.

Via a debugger, I compared what happens in Karaf with CXF 3.3.2 and CXF 
3.2.8:

```
io.cloudsoft.winrm4j.client.wsman.ObjectFactory.class.getAnnotations()[0].annotationType()
[CXV 3.2.8 output] (java.lang.Class<T>) interface 
javax.xml.bind.annotation.XmlRegistry
[CXV 3.3.2 output] (java.lang.Class<T>) interface 
javax.xml.bind.annotation.XmlRegistry

io.cloudsoft.winrm4j.client.wsman.ObjectFactory.class.getAnnotations()[0].annotationType().getClassLoader()
[CXV 3.2.8 output] null
[CXV 3.3.2 output] 
(org.apache.felix.framework.BundleWiringImpl$BundleClassLoader) 
jakarta.xml.bind-api [108]
```

I interpret the null classloader as meaning it is from the system 
classloader (e.g. `java.lang.Object.class.getClassLoader()` also returns 
`null`).

Looking in Karaf using `bin/client` (with CXF 3.2.8):
```
package:exports | grep javax.xml.bind.annotation
javax.xml.bind.annotation.adapters    │ 2.2.8    │ 0   │ 
org.apache.felix.framework
javax.xml.bind.annotation             │ 2.2.8    │ 0   │ 
org.apache.felix.framework

package:imports | grep winrm | grep javax.xml.bind.annotation
Package                               │ Version    │ Optional │ ID  │ 
Bundle Name
javax.xml.bind.annotation.adapters │        │          │ 103 │ 
io.cloudsoft.windows.winrm4j-client
javax.xml.bind.annotation │          │          │ 103 │ 
io.cloudsoft.windows.winrm4j-client
```

Compare that with CXF 3.3.2:
```
package:exports | grep javax.xml.bind.annotation
javax.xml.bind.annotation.adapters    │ 2.2.8    │ 0   │ 
org.apache.felix.framework
javax.xml.bind.annotation.adapters    │ 2.3.2    │ 108 │ 
jakarta.xml.bind-api
javax.xml.bind.annotation             │ 2.2.8    │ 0   │ 
org.apache.felix.framework
javax.xml.bind.annotation             │ 2.3.2    │ 108 │ 
jakarta.xml.bind-api

package:imports | grep winrm | grep javax.xml.bind.annotation
Package                               │ Version        │ Optional │ ID  
│ Bundle Name
javax.xml.bind.annotation.adapters │ [2.3.0,3.0.0) │          │ 103 │ 
io.cloudsoft.windows.winrm4j-client
javax.xml.bind.annotation │ [2.3.0,3.0.0) │          │ 103 │ 
io.cloudsoft.windows.winrm4j-client
```

Looking at where `jakarta.xml.bind-api` comes from in CXF 3.3.2 (it's 
not there when we use CXF 3.2.8):
```
feature:info cxf-specs

Running feature:info cxf-specs
Feature cxf-specs 3.3.2
...
Feature contains followed bundles:
   ...
   mvn:jakarta.xml.bind/jakarta.xml.bind-api/2.3.2 start-level=10
```
(The cxf-specs feature is a dependency of the cxf-core feature.)

Looking at the MANIFEST.mf (or the bundle:headers) of `winrm4j-client`:
With CXF 3.3.2, it has:
```
javax.xml.bind.annotation;version="[2.3,3)"
```
With CXF 3.2.8, it has:
```
javax.xml.bind.annotation
```
(i.e. no version range is specified).

I don't think there are code changes causing this - I think it is 
inferred from the CXF versions (or perhaps because newer maven plugin 
versions are used?)

But even if it didn't specify a version range with CXF 3.3.2, it would 
prefer the import from the newer version (i.e. from 2.3.2).


_*NEXT STEPS*_

We should report the issue on the CXF / Karaf mailing list - I'll do that.

I lean towards not fixing it (unless the CXF community come back with an 
easy answer).

If we did try to fix it, possibilities include:

 1. Change winrm4j bundle's package imports to require 2.2.x of
    javax.xml.bind.annotation.
    But would that be compatible with the rest of the CXF package imports?
 2. Or some other mechanism to force the annotation parsing to somehow
    use javax.xml.bind.annotation.XmlRegistry version 2.2.8 from
    org.apache.felix.framework?!
 3. Or try to force use of a particular `JAXBContext` - but winrm4j
    isn't instantiating the JAXBContext.
    (e.g. https://stackoverflow.com/a/7483425/1393883 tries to force a
    particular `META-INF/services/javax.xml.bind.JAXBContext` at the
    classloader level).


Option (2) feels really hard and risky - the feature `cxf-specs` is 
pulling in `jakarta.xml.bind-api`, and `cxf-core` pulls in the feature 
`cxf-specs`. That feels very low level! There could be untold 
consequences of messing with the bind-api version at that level. Even if 
our smoke tests pass, I'd be worried about what else we might have broken.

Option (1) gives me some of the same worries as for (2) - we'd be 
importing a different javax.xml.bind.annotation compared to the bundles 
that the CXF packages come from. That kind of thing can cause weird 
ClassCastExceptions because things are using different classloaders.

My gut feel for option (3) is that it's the wrong road to be going down 
- it's fighting CXF rather than working with it!


_*MISCELLANEOUS DEBUGGING NOTES*_

I find the script below useful to get a dump of all the features and 
which bundles they bring in - I normally redirect the output to a file 
and search through that:
```
#!/bin/bash

for i in `./bin/client "feature:list" | grep -v "Uninstalled" | awk 
'{print $1}'`; do
     echo "Running feature:info ${i}"
     ./bin/client "feature:info ${i}"
     echo
     echo
done
```

On 02/12/2019 21:21, Geoff Macartney wrote:
> It's always a bit of a maze, isn't it!
>
> Thanks for looking into this Aled. I think it will be great to get 
> things brought up to a consistent level with this latest Karaf.
>
> Cheers
> Geoff
>
>
>
> On Mon, 2 Dec 2019 at 13:28, Aled Sage <aled.sage@gmail.com 
> <ma...@gmail.com>> wrote:
>
>     Hi all,
>
>     TL;DR: I'm looking at upgading CXF from 3.2.8 to 3.3.2.
>
>     ---
>
>     For dependency:
>          system//javax/mail/mail: [1.4.7, 1.4.4]
>
>     Exploring this one shows that v1.4.4 is coming from the old cxf-specs
>     3.2.8. The Karaf 4.2.7 announcement [1] gives a table of versions
>     - it
>     shows CXF at 3.3.2. We should look up updating CXF from 3.2.8 to
>     3.3.2.
>
>     That will also require an upgrade of mvn:io.cloudsoft.windows/winrm4j
>     (as v0.7.0 is built against CXF 3.2.8).
>
>     I'm looking into this, to see what else breaks when we switch to
>     CXF 3.3.2.
>
>     ---
>
>     I suggest we ignore:
>     system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle:
>
>     [1.2.2, 1.2]
>
>     Feature 'jetty' brings in v1.2.2, whereas feature 'pax-jetty'
>     brings in
>     v1.2, so it's out of our control.
>
>     Aled
>
>
>     On 02/12/2019 10:38, Aled Sage wrote:
>     > Hi all,
>     >
>     > I see there was great progress with the karaf version bump last
>     week
>     > and over the weekend, e.g. [1, 2].
>     >
>     > Looking at brooklyn master karaf dependency versions using `find
>     > ${BROOKLYN_HOME}/system/ -name "*.jar"` and running a little
>     program
>     > to find multiple versions, I see the following concerning
>     duplicates:
>     >
>     >
>     system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle:
>
>     > [1.2.2, 1.2]
>     > system//javax/mail/mail: [1.4.7, 1.4.4]
>     >
>     > The full list is:
>     >
>     > system//org/ow2/asm/asm: [5.2, 7.1]
>     > system//org/ow2/asm/asm-util: [5.2, 7.1]
>     > system//org/ow2/asm/asm-tree: [5.2, 7.1]
>     > system//org/ow2/asm/asm-analysis: [5.2, 7.1]
>     > system//org/ow2/asm/asm-commons: [5.2, 7.1]
>     > system//org/yaml/snakeyaml: [1.23, 1.17]
>     >
>     system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.jzlib:
>
>     > [1.1.3_2, 1.0.7_1]
>     >
>     system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okhttp:
>
>     > [3.4.1_1, 2.2.0_1]
>     >
>     system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okio:
>
>     > [1.9.0_1, 1.2.0_1]
>     >
>     system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle:
>
>     > [1.2.2, 1.2]
>     > system//javax/mail/mail: [1.4.7, 1.4.4]
>     > system//javax/ws/rs/javax.ws <http://javax.ws>.rs-api: [2.0.1,
>     2.1.1]
>     >
>     > Compare this with Brooklyn version 1.0.0-M1:
>     >
>     > system//org/ow2/asm/asm-all: [5.2, 5.0.2]
>     > system//org/yaml/snakeyaml: [1.17, 1.22]
>     >
>     system//org/apache/servicemix/specs/org.apache.servicemix.specs.activation-api-1.1:
>
>     > [2.5.0, 2.6.0]
>     >
>     system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.jzlib:
>
>     > [1.1.3_2, 1.0.7_1]
>     >
>     system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okhttp:
>
>     > [3.4.1_1, 2.2.0_1]
>     >
>     system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okio:
>
>     > [1.9.0_1, 1.2.0_1]
>     > system//org/apache/aries/org.apache.aries.util: [1.1.3, 1.1.0]
>     > system//com/google/code/gson/gson: [2.5, 2.3]
>     >
>     > I'll take a look at these and see if they really are a problem
>     or not.
>     >
>     > Aled
>     >
>     > [1] https://github.com/apache/brooklyn-server/pull/1068
>     >
>     > [2] https://github.com/apache/brooklyn-server/pull/1069
>     >
>     >
>     >
>     >
>     > On 02/12/2019 09:27, Aled Sage wrote:
>     >> Hi,
>     >>
>     >> Thanks Ludo, all: - great list, and +1 from me.
>     >>
>     >> I think most of those sound fairly small and manageable.
>     >>
>     >> The one that stands out as potentially hard is the "Karaf version
>     >> bump" (which would fix the "Two different versions of
>     jetty-server").
>     >> We've had problems in the past getting all versions consistent,
>     and
>     >> karaf to start up fast and cleanly (without it restarting a
>     bunch of
>     >> bundles). Changing the version is really easy - getting all
>     versions
>     >> of all bundles to be consistent can be a pain! But it's worth
>     doing.
>     >>
>     >> Aled
>     >>
>     >>
>     >> On 01/12/2019 14:47, Geoff Macartney wrote:
>     >>> We should definitely include
>     >>> https://issues.apache.org/jira/browse/BROOKLYN-597 "Remove MD5
>     and
>     >>> SHA-1
>     >>> checksums" as part of 1.0.0.  I'd be happy to do this but I
>     see it's
>     >>> got
>     >>> you assigned to it Richard. Do you have work in progress on
>     this, or
>     >>> would
>     >>> you like me to look into it? I have a notion that I might
>     polish up the
>     >>> signing procedure a bit.
>     >>>
>     >>> Cheers
>     >>> Geoff
>     >>>
>     >>> On Sun, 1 Dec 2019 at 14:13, Geoff Macartney
>     >>> <geoff.macartney@gmail.com <ma...@gmail.com>>
>     >>> wrote:
>     >>>
>     >>>> Hi Ludo,
>     >>>>
>     >>>> I am indeed pleased to see this!  I had been thinking of
>     mailing the
>     >>>> community again on the matter after Christmas was out of the
>     way,
>     >>>> let's let
>     >>>> 2020 be the year of Brooklyn 1.0.0!
>     >>>>
>     >>>> That's a great list of things to address. One thing to add
>     would be
>     >>>> removing some deprecated code. Do you think they are all small
>     >>>> changes, or
>     >>>> do any require extensive work or have a wide impact?
>     >>>>
>     >>>> The reason I ask is that I think it would be good to restrict
>     >>>> ourselves to
>     >>>> relatively easy and limited impact changes between now and
>     1.0.0.
>     >>>> My fear
>     >>>> is that larger changes will take a longer time and push back a
>     >>>> release even
>     >>>> further. It seems to me things are quite stable now; I'd say
>     let's
>     >>>> polish
>     >>>> it up and release it rather than try to make significant
>     improvements.
>     >>>>
>     >>>> What does everyone think?
>     >>>>
>     >>>> Cheers
>     >>>> Geoff
>     >>>>
>     >>>>
>     >>>>
>     >>>>
>     >>>> On Thu, 28 Nov 2019 at 11:04, Ludovic Farine
>     <ludo@cloudsoft.io <ma...@cloudsoft.io>>
>     >>>> wrote:
>     >>>>
>     >>>>> Hi everyone,
>     >>>>>
>     >>>>> Hope you are all doing well!
>     >>>>>
>     >>>>> Christmas is fast approaching and well hopefully a gift we
>     would
>     >>>>> all like
>     >>>>> to have: Brooklyn 1.0.0 release :) Geoff would be pleased to
>     hear!
>     >>>>>
>     >>>>> Working towards this goal of first official release, these
>     are a
>     >>>>> few bug
>     >>>>> fixes and improvements that I believe are worth considering
>     >>>>> (non-exhaustive
>     >>>>> and not ordered wishlist!) :
>     >>>>>
>     >>>>> Bug fixes:
>     >>>>>
>     >>>>>     -
>     >>>>>
>     >>>>>     Broken icon links for ELK and DNS entities
>     >>>>>     -
>     >>>>>
>     >>>>>     REST API Swagger error
>     >>>>>     -
>     >>>>>
>     >>>>>     Two different versions of jetty-server
>     >>>>>     -
>     >>>>>
>     >>>>>     Karaf version bump
>     >>>>>
>     >>>>>
>     >>>>> Improvements:
>     >>>>>
>     >>>>>     -
>     >>>>>
>     >>>>>     Session Management: introduce expiry settings for
>     inactivity or
>     >>>>> repeated
>     >>>>>     background API calls
>     >>>>>     -
>     >>>>>
>     >>>>>     User Experience: blueprints ordered by date deployed,
>     cookies to
>     >>>>>     remember preferred sort criteria and palette preferences
>     >>>>>
>     >>>>>
>     >>>>> Clean-up:
>     >>>>>
>     >>>>>     -
>     >>>>>
>     >>>>>     Review existing open Pull Requests
>     >>>>>     -
>     >>>>>
>     >>>>>     Fix most of the Jenkins tests
>     >>>>>
>     >>>>>
>     >>>>> What are your thoughts on this scope? Any other suggestions you
>     >>>>> would like
>     >>>>> to deliver in this next release?
>     >>>>>
>     >>>>> Looking forward to get the community engaging in the next
>     weeks and
>     >>>>> months.
>     >>>>>
>     >>>>> Remember you can participate with others on the official Slack
>     >>>>> channel
>     >>>>> *#brooklyn* on the official Apache group. Sign up here
>     >>>>> https://s.apache.org/slack-invite to join the discussion!
>     >>>>>
>     >>>>> Thanks
>     >>>>>
>     >>>>> Ludo
>     >>>>>
>     >>>>>
>     >>>>> --
>     >>>>>
>     >>>>> Ludovic Farine
>     >>>>>
>     >>>>> Senior Technical Project Manager
>     >>>>>
>     >>>>>
>     >>>>> Cloudsoft <https://cloudsoft.io/> | Bringing Business to the
>     Cloud
>     >>>>>
>     >>>>> E: ludo@cloudsoft.io <ma...@cloudsoft.io>
>     >>>>>
>     >>>>> T: +44 7584 748013
>     >>>>>
>     >>>>> L: https://www.linkedin.com/in/ludovicfarine/
>     >>>>>
>

Re: Brooklyn 1.0 is shaping up <-- karaf version bump

Posted by Geoff Macartney <ge...@gmail.com>.
It's always a bit of a maze, isn't it!

Thanks for looking into this Aled. I think it will be great to get things
brought up to a consistent level with this latest Karaf.

Cheers
Geoff



On Mon, 2 Dec 2019 at 13:28, Aled Sage <al...@gmail.com> wrote:

> Hi all,
>
> TL;DR: I'm looking at upgading CXF from 3.2.8 to 3.3.2.
>
> ---
>
> For dependency:
>      system//javax/mail/mail: [1.4.7, 1.4.4]
>
> Exploring this one shows that v1.4.4 is coming from the old cxf-specs
> 3.2.8. The Karaf 4.2.7 announcement [1] gives a table of versions - it
> shows CXF at 3.3.2. We should look up updating CXF from 3.2.8 to 3.3.2.
>
> That will also require an upgrade of mvn:io.cloudsoft.windows/winrm4j
> (as v0.7.0 is built against CXF 3.2.8).
>
> I'm looking into this, to see what else breaks when we switch to CXF 3.3.2.
>
> ---
>
> I suggest we ignore:
> system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle:
> [1.2.2, 1.2]
>
> Feature 'jetty' brings in v1.2.2, whereas feature 'pax-jetty' brings in
> v1.2, so it's out of our control.
>
> Aled
>
>
> On 02/12/2019 10:38, Aled Sage wrote:
> > Hi all,
> >
> > I see there was great progress with the karaf version bump last week
> > and over the weekend, e.g. [1, 2].
> >
> > Looking at brooklyn master karaf dependency versions using `find
> > ${BROOKLYN_HOME}/system/ -name "*.jar"` and running a little program
> > to find multiple versions, I see the following concerning duplicates:
> >
> > system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle:
> > [1.2.2, 1.2]
> > system//javax/mail/mail: [1.4.7, 1.4.4]
> >
> > The full list is:
> >
> > system//org/ow2/asm/asm: [5.2, 7.1]
> > system//org/ow2/asm/asm-util: [5.2, 7.1]
> > system//org/ow2/asm/asm-tree: [5.2, 7.1]
> > system//org/ow2/asm/asm-analysis: [5.2, 7.1]
> > system//org/ow2/asm/asm-commons: [5.2, 7.1]
> > system//org/yaml/snakeyaml: [1.23, 1.17]
> >
> system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.jzlib:
> > [1.1.3_2, 1.0.7_1]
> >
> system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okhttp:
> > [3.4.1_1, 2.2.0_1]
> >
> system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okio:
> > [1.9.0_1, 1.2.0_1]
> > system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle:
> > [1.2.2, 1.2]
> > system//javax/mail/mail: [1.4.7, 1.4.4]
> > system//javax/ws/rs/javax.ws.rs-api: [2.0.1, 2.1.1]
> >
> > Compare this with Brooklyn version 1.0.0-M1:
> >
> > system//org/ow2/asm/asm-all: [5.2, 5.0.2]
> > system//org/yaml/snakeyaml: [1.17, 1.22]
> >
> system//org/apache/servicemix/specs/org.apache.servicemix.specs.activation-api-1.1:
>
> > [2.5.0, 2.6.0]
> >
> system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.jzlib:
> > [1.1.3_2, 1.0.7_1]
> >
> system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okhttp:
> > [3.4.1_1, 2.2.0_1]
> >
> system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okio:
> > [1.9.0_1, 1.2.0_1]
> > system//org/apache/aries/org.apache.aries.util: [1.1.3, 1.1.0]
> > system//com/google/code/gson/gson: [2.5, 2.3]
> >
> > I'll take a look at these and see if they really are a problem or not.
> >
> > Aled
> >
> > [1] https://github.com/apache/brooklyn-server/pull/1068
> >
> > [2] https://github.com/apache/brooklyn-server/pull/1069
> >
> >
> >
> >
> > On 02/12/2019 09:27, Aled Sage wrote:
> >> Hi,
> >>
> >> Thanks Ludo, all: - great list, and +1 from me.
> >>
> >> I think most of those sound fairly small and manageable.
> >>
> >> The one that stands out as potentially hard is the "Karaf version
> >> bump" (which would fix the "Two different versions of jetty-server").
> >> We've had problems in the past getting all versions consistent, and
> >> karaf to start up fast and cleanly (without it restarting a bunch of
> >> bundles). Changing the version is really easy - getting all versions
> >> of all bundles to be consistent can be a pain! But it's worth doing.
> >>
> >> Aled
> >>
> >>
> >> On 01/12/2019 14:47, Geoff Macartney wrote:
> >>> We should definitely include
> >>> https://issues.apache.org/jira/browse/BROOKLYN-597 "Remove MD5 and
> >>> SHA-1
> >>> checksums" as part of 1.0.0.  I'd be happy to do this but I see it's
> >>> got
> >>> you assigned to it Richard. Do you have work in progress on this, or
> >>> would
> >>> you like me to look into it? I have a notion that I might polish up the
> >>> signing procedure a bit.
> >>>
> >>> Cheers
> >>> Geoff
> >>>
> >>> On Sun, 1 Dec 2019 at 14:13, Geoff Macartney
> >>> <ge...@gmail.com>
> >>> wrote:
> >>>
> >>>> Hi Ludo,
> >>>>
> >>>> I am indeed pleased to see this!  I had been thinking of mailing the
> >>>> community again on the matter after Christmas was out of the way,
> >>>> let's let
> >>>> 2020 be the year of Brooklyn 1.0.0!
> >>>>
> >>>> That's a great list of things to address. One thing to add would be
> >>>> removing some deprecated code. Do you think they are all small
> >>>> changes, or
> >>>> do any require extensive work or have a wide impact?
> >>>>
> >>>> The reason I ask is that I think it would be good to restrict
> >>>> ourselves to
> >>>> relatively easy and limited impact changes between now and 1.0.0.
> >>>> My fear
> >>>> is that larger changes will take a longer time and push back a
> >>>> release even
> >>>> further. It seems to me things are quite stable now; I'd say let's
> >>>> polish
> >>>> it up and release it rather than try to make significant improvements.
> >>>>
> >>>> What does everyone think?
> >>>>
> >>>> Cheers
> >>>> Geoff
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Thu, 28 Nov 2019 at 11:04, Ludovic Farine <lu...@cloudsoft.io>
> >>>> wrote:
> >>>>
> >>>>> Hi everyone,
> >>>>>
> >>>>> Hope you are all doing well!
> >>>>>
> >>>>> Christmas is fast approaching and well hopefully a gift we would
> >>>>> all like
> >>>>> to have: Brooklyn 1.0.0 release :) Geoff would be pleased to hear!
> >>>>>
> >>>>> Working towards this goal of first official release, these are a
> >>>>> few bug
> >>>>> fixes and improvements that I believe are worth considering
> >>>>> (non-exhaustive
> >>>>> and not ordered wishlist!) :
> >>>>>
> >>>>> Bug fixes:
> >>>>>
> >>>>>     -
> >>>>>
> >>>>>     Broken icon links for ELK and DNS entities
> >>>>>     -
> >>>>>
> >>>>>     REST API Swagger error
> >>>>>     -
> >>>>>
> >>>>>     Two different versions of jetty-server
> >>>>>     -
> >>>>>
> >>>>>     Karaf version bump
> >>>>>
> >>>>>
> >>>>> Improvements:
> >>>>>
> >>>>>     -
> >>>>>
> >>>>>     Session Management: introduce expiry settings for inactivity or
> >>>>> repeated
> >>>>>     background API calls
> >>>>>     -
> >>>>>
> >>>>>     User Experience: blueprints ordered by date deployed, cookies to
> >>>>>     remember preferred sort criteria and palette preferences
> >>>>>
> >>>>>
> >>>>> Clean-up:
> >>>>>
> >>>>>     -
> >>>>>
> >>>>>     Review existing open Pull Requests
> >>>>>     -
> >>>>>
> >>>>>     Fix most of the Jenkins tests
> >>>>>
> >>>>>
> >>>>> What are your thoughts on this scope? Any other suggestions you
> >>>>> would like
> >>>>> to deliver in this next release?
> >>>>>
> >>>>> Looking forward to get the community engaging in the next weeks and
> >>>>> months.
> >>>>>
> >>>>> Remember you can participate with others on the official Slack
> >>>>> channel
> >>>>> *#brooklyn* on the official Apache group. Sign up here
> >>>>> https://s.apache.org/slack-invite to join the discussion!
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> Ludo
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Ludovic Farine
> >>>>>
> >>>>> Senior Technical Project Manager
> >>>>>
> >>>>>
> >>>>> Cloudsoft <https://cloudsoft.io/> | Bringing Business to the Cloud
> >>>>>
> >>>>> E: ludo@cloudsoft.io
> >>>>>
> >>>>> T: +44 7584 748013
> >>>>>
> >>>>> L: https://www.linkedin.com/in/ludovicfarine/
> >>>>>
>

Re: Brooklyn 1.0 is shaping up <-- karaf version bump

Posted by Aled Sage <al...@gmail.com>.
Hi all,

TL;DR: I'm looking at upgading CXF from 3.2.8 to 3.3.2.

---

For dependency:
     system//javax/mail/mail: [1.4.7, 1.4.4]

Exploring this one shows that v1.4.4 is coming from the old cxf-specs 
3.2.8. The Karaf 4.2.7 announcement [1] gives a table of versions - it 
shows CXF at 3.3.2. We should look up updating CXF from 3.2.8 to 3.3.2.

That will also require an upgrade of mvn:io.cloudsoft.windows/winrm4j 
(as v0.7.0 is built against CXF 3.2.8).

I'm looking into this, to see what else breaks when we switch to CXF 3.3.2.

---

I suggest we ignore:
system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle: 
[1.2.2, 1.2]

Feature 'jetty' brings in v1.2.2, whereas feature 'pax-jetty' brings in 
v1.2, so it's out of our control.

Aled


On 02/12/2019 10:38, Aled Sage wrote:
> Hi all,
>
> I see there was great progress with the karaf version bump last week 
> and over the weekend, e.g. [1, 2].
>
> Looking at brooklyn master karaf dependency versions using `find 
> ${BROOKLYN_HOME}/system/ -name "*.jar"` and running a little program 
> to find multiple versions, I see the following concerning duplicates:
>
> system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle: 
> [1.2.2, 1.2]
> system//javax/mail/mail: [1.4.7, 1.4.4]
>
> The full list is:
>
> system//org/ow2/asm/asm: [5.2, 7.1]
> system//org/ow2/asm/asm-util: [5.2, 7.1]
> system//org/ow2/asm/asm-tree: [5.2, 7.1]
> system//org/ow2/asm/asm-analysis: [5.2, 7.1]
> system//org/ow2/asm/asm-commons: [5.2, 7.1]
> system//org/yaml/snakeyaml: [1.23, 1.17]
> system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.jzlib: 
> [1.1.3_2, 1.0.7_1]
> system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okhttp: 
> [3.4.1_1, 2.2.0_1]
> system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okio: 
> [1.9.0_1, 1.2.0_1]
> system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle: 
> [1.2.2, 1.2]
> system//javax/mail/mail: [1.4.7, 1.4.4]
> system//javax/ws/rs/javax.ws.rs-api: [2.0.1, 2.1.1]
>
> Compare this with Brooklyn version 1.0.0-M1:
>
> system//org/ow2/asm/asm-all: [5.2, 5.0.2]
> system//org/yaml/snakeyaml: [1.17, 1.22]
> system//org/apache/servicemix/specs/org.apache.servicemix.specs.activation-api-1.1: 
> [2.5.0, 2.6.0]
> system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.jzlib: 
> [1.1.3_2, 1.0.7_1]
> system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okhttp: 
> [3.4.1_1, 2.2.0_1]
> system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okio: 
> [1.9.0_1, 1.2.0_1]
> system//org/apache/aries/org.apache.aries.util: [1.1.3, 1.1.0]
> system//com/google/code/gson/gson: [2.5, 2.3]
>
> I'll take a look at these and see if they really are a problem or not.
>
> Aled
>
> [1] https://github.com/apache/brooklyn-server/pull/1068
>
> [2] https://github.com/apache/brooklyn-server/pull/1069
>
>
>
>
> On 02/12/2019 09:27, Aled Sage wrote:
>> Hi,
>>
>> Thanks Ludo, all: - great list, and +1 from me.
>>
>> I think most of those sound fairly small and manageable.
>>
>> The one that stands out as potentially hard is the "Karaf version 
>> bump" (which would fix the "Two different versions of jetty-server"). 
>> We've had problems in the past getting all versions consistent, and 
>> karaf to start up fast and cleanly (without it restarting a bunch of 
>> bundles). Changing the version is really easy - getting all versions 
>> of all bundles to be consistent can be a pain! But it's worth doing.
>>
>> Aled
>>
>>
>> On 01/12/2019 14:47, Geoff Macartney wrote:
>>> We should definitely include
>>> https://issues.apache.org/jira/browse/BROOKLYN-597 "Remove MD5 and 
>>> SHA-1
>>> checksums" as part of 1.0.0.  I'd be happy to do this but I see it's 
>>> got
>>> you assigned to it Richard. Do you have work in progress on this, or 
>>> would
>>> you like me to look into it? I have a notion that I might polish up the
>>> signing procedure a bit.
>>>
>>> Cheers
>>> Geoff
>>>
>>> On Sun, 1 Dec 2019 at 14:13, Geoff Macartney 
>>> <ge...@gmail.com>
>>> wrote:
>>>
>>>> Hi Ludo,
>>>>
>>>> I am indeed pleased to see this!  I had been thinking of mailing the
>>>> community again on the matter after Christmas was out of the way, 
>>>> let's let
>>>> 2020 be the year of Brooklyn 1.0.0!
>>>>
>>>> That's a great list of things to address. One thing to add would be
>>>> removing some deprecated code. Do you think they are all small 
>>>> changes, or
>>>> do any require extensive work or have a wide impact?
>>>>
>>>> The reason I ask is that I think it would be good to restrict 
>>>> ourselves to
>>>> relatively easy and limited impact changes between now and 1.0.0. 
>>>> My fear
>>>> is that larger changes will take a longer time and push back a 
>>>> release even
>>>> further. It seems to me things are quite stable now; I'd say let's 
>>>> polish
>>>> it up and release it rather than try to make significant improvements.
>>>>
>>>> What does everyone think?
>>>>
>>>> Cheers
>>>> Geoff
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, 28 Nov 2019 at 11:04, Ludovic Farine <lu...@cloudsoft.io> 
>>>> wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> Hope you are all doing well!
>>>>>
>>>>> Christmas is fast approaching and well hopefully a gift we would 
>>>>> all like
>>>>> to have: Brooklyn 1.0.0 release :) Geoff would be pleased to hear!
>>>>>
>>>>> Working towards this goal of first official release, these are a 
>>>>> few bug
>>>>> fixes and improvements that I believe are worth considering
>>>>> (non-exhaustive
>>>>> and not ordered wishlist!) :
>>>>>
>>>>> Bug fixes:
>>>>>
>>>>>     -
>>>>>
>>>>>     Broken icon links for ELK and DNS entities
>>>>>     -
>>>>>
>>>>>     REST API Swagger error
>>>>>     -
>>>>>
>>>>>     Two different versions of jetty-server
>>>>>     -
>>>>>
>>>>>     Karaf version bump
>>>>>
>>>>>
>>>>> Improvements:
>>>>>
>>>>>     -
>>>>>
>>>>>     Session Management: introduce expiry settings for inactivity or
>>>>> repeated
>>>>>     background API calls
>>>>>     -
>>>>>
>>>>>     User Experience: blueprints ordered by date deployed, cookies to
>>>>>     remember preferred sort criteria and palette preferences
>>>>>
>>>>>
>>>>> Clean-up:
>>>>>
>>>>>     -
>>>>>
>>>>>     Review existing open Pull Requests
>>>>>     -
>>>>>
>>>>>     Fix most of the Jenkins tests
>>>>>
>>>>>
>>>>> What are your thoughts on this scope? Any other suggestions you 
>>>>> would like
>>>>> to deliver in this next release?
>>>>>
>>>>> Looking forward to get the community engaging in the next weeks and
>>>>> months.
>>>>>
>>>>> Remember you can participate with others on the official Slack 
>>>>> channel
>>>>> *#brooklyn* on the official Apache group. Sign up here
>>>>> https://s.apache.org/slack-invite to join the discussion!
>>>>>
>>>>> Thanks
>>>>>
>>>>> Ludo
>>>>>
>>>>>
>>>>> -- 
>>>>>
>>>>> Ludovic Farine
>>>>>
>>>>> Senior Technical Project Manager
>>>>>
>>>>>
>>>>> Cloudsoft <https://cloudsoft.io/> | Bringing Business to the Cloud
>>>>>
>>>>> E: ludo@cloudsoft.io
>>>>>
>>>>> T: +44 7584 748013
>>>>>
>>>>> L: https://www.linkedin.com/in/ludovicfarine/
>>>>>