*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.s...@gmail.com
<mailto:aled.s...@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.macart...@gmail.com <mailto:geoff.macart...@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
<l...@cloudsoft.io <mailto:l...@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: l...@cloudsoft.io <mailto:l...@cloudsoft.io>
>>>>>
>>>>> T: +44 7584 748013
>>>>>
>>>>> L: https://www.linkedin.com/in/ludovicfarine/
>>>>>
