[jira] [Commented] (BROOKLYN-625) Blueprint Composer cannot select a location
[ https://issues.apache.org/jira/browse/BROOKLYN-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17035433#comment-17035433 ] Paul Campbell commented on BROOKLYN-625: I see the expected behaviour too. Firefox 72.0.2 on Debian 10 > Blueprint Composer cannot select a location > --- > > Key: BROOKLYN-625 > URL: https://issues.apache.org/jira/browse/BROOKLYN-625 > Project: Brooklyn > Issue Type: Bug >Affects Versions: 1.0.0 > Environment: Windows 10 Professional 64-bit > Firefox 72.0.2 (64-bit) > Apache Brooklyn 1.0.0-rc2 >Reporter: Richard Downer >Priority: Major > Fix For: 1.0.0 > > > > > # Ensure at least one location is configured in the Location Manager. > # Open the Blueprint Composer. > # Click on the "New Application" entity on the canvas. > # In the sidebar, expand the Location section and click "Attach a location". > > Expected behaviour: a list of locations to choose from. > Actual behaviour: an empty list and message "Nothing available" > Workaround: the location name can be typed in manually, then the "ad hoc" > tile clicked and attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (BROOKLYN-605) Rebind historic persisted state: referencing wrap:mvn bundles
Paul Campbell created BROOKLYN-605: -- Summary: Rebind historic persisted state: referencing wrap:mvn bundles Key: BROOKLYN-605 URL: https://issues.apache.org/jira/browse/BROOKLYN-605 Project: Brooklyn Issue Type: Dependency Affects Versions: 0.12.0 Reporter: Paul Campbell Aled's [email|https://markmail.org/message/rgxv6sask2sbrcff] from the dev mailing line : Hi all, TL;DR: I've hit a problem with rebinding to historic persisted state, when wrap:mvn has been used for OSGi bundles - the symbolic name changed, so classloading didn't work on rebind. Which of the solutions should we go for? _*PROBLEM*_ The persisted state refers to a class in aws-java-sdk 1.11.245, but in my newer brooklyn I've upgraded this bundle to 1.11.411 (the old bundle is not there). Because this jar was added using wrap-mvn, the two versions of the bundle have different symbolic names! Brooklyn therefore doesn't know to look in the newer aws-java-sdk bundle. The bundle was added via a feature.xml containing: wrap:mvn:com.amazonaws/aws-java-sdk-bundle/${aws.java.sdk.version} When built locally, this produced a bundle with the very strange symbolic name: wrap_file__Users_aledsage_amp_cloudsoft-amp-karaf-5.2.0_system_com_amazonaws_aws-java-sdk-bundle_1.11.245_aws-java-sdk-bundle-1.11.245.jar _*EXISTING FUNCTIONALITY*_ Brooklyn currently supports a couple of related features: 1. The persisted state will by default not include bundle versions. We are therefore willing to use newer versions of a given bundle. 2. When adding your own bundle, you can include metadata in it's MANIFST.mf to say what bundle/version it replaces. See brooklyn-docs guide/ops/upgrades/_blueprints.md However, I don't want to use (2) because that would involve fiddling with the wrap:mvn to add more metadata. _*POSSIBLE SOLUTIONS*_ There are no doubt many ways to solve this problem. I describe a few of them below. I think I favour the class-renames approach because of its simplicity. *_Add support to class-renames_* Our deserializingClassRenames.properties allows rebind to handle class renames, or a specific class moving from one bundle to another. This is useful for historic persisted state. We could add support for bundle wildcards, to say that all classes in one bundle can be loaded from another bundle. For example: wrap_blah_aws-java-sdk-bundle-1.11.245.jar\:* : wrap_blah_aws-java-sdk-bundle-1.11.411.jar\:* *_Support a bundle-upgrade configuration file_* We could add support for a config file that gives explicit named bundle replacements. This would augment the existing functionality (2 above), but instead of the replacement bundle being defined in the new bundle's metadata, it could also be defined in this configuration file. For example, $BROOKLYN_HOME/etc/org.apache.brooklyn.bundleupgrade.cfg could contain something like: wrap_blah_aws-java-sdk-bundle-1.11.411.jar: Brooklyn-Catalog-Upgrade-For-Bundles: "wrap_blah_aws-java-sdk-bundle-1.11.245.jar: *" (would need to figure out the cfg versus yaml format here, obviously!) *_Recognise 'wrap' bundles, and allow newer versions_* When loading the class, we could recognise the "wrap_" prefix. We could figure out from the symbolic name what it was built from, and be willing to use bundles that are newer versions. However, playing with wrap:mvn, the bundle naming is not as obvious as one would expect. The symbolic name below is a very different structure from that above: wrap_mvn_com.example.brooklyn.test.resources.osgi_brooklyn-test-osgi-com-example-plainoldjar_1.0.0 This example was created in karaf client by running: bundle:install wrap:mvn:com.example.brooklyn.test.resources.osgi/brooklyn-test-osgi-com-example-plainoldjar/1.0.0 See brooklyn-server's org.apache.brooklyn.util.core.ClassLoaderUtils.tryLoadFromBundle. *_Require users to set the symbolic name, when using wrap:mvn_* We could require users to *not* use the simple "wrap:mvn", and instead force them to ensure a more predictable symbolic name + version is used. However, that sounds harder for users. It also doesn't solve the problem for anyone with such historic persisted state. _*LONG TERM / DOCS *_We should warn people about this in our docs, including a description of how to work around it. We should discourage the use of complex types in config keys and sensors, where we (or the user) don't explicitly control the versioning and schema of those types. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (BROOKLYN-604) Upgrade Jetty and CXF to match current karaf release
Paul Campbell created BROOKLYN-604: -- Summary: Upgrade Jetty and CXF to match current karaf release Key: BROOKLYN-604 URL: https://issues.apache.org/jira/browse/BROOKLYN-604 Project: Brooklyn Issue Type: Dependency Reporter: Paul Campbell Karaf 4.2.1 uses jetty 9.4.x and cxf 3.2.x, while Brooklyn has a dependency on jetty 9.3.24 and cxf 3.1.10. Both need to be upgraded to avoid divergent dependencies. I have already attempted, unsuccessfully, to perform this upgrade, but ran into an issue where the javax.xml.ws package wasn't available to the brooklyn-rest-resources bundle, despite various attempts to add it. Including installing mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jaxws-api-2.2/2.9.0. The error was NoClassDefFoundError for javax.xml.ws.WebServiceFeature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (BROOKLYN-598) ssh based activities fail if remote shell is fish
Paul Campbell created BROOKLYN-598: -- Summary: ssh based activities fail if remote shell is fish Key: BROOKLYN-598 URL: https://issues.apache.org/jira/browse/BROOKLYN-598 Project: Brooklyn Issue Type: Bug Reporter: Paul Campbell Remote commands are never executed and brooklyn hangs awaiting shell threads to complete. {noformat} Task[ssh: launching VanillaSoftwareProcessImpl{id=wrxf0wi528}]@geG8s3B9 Submitted by MaybeSupplier[value=Task[launch (main)]@gnbP4pi1] In progress, thread waiting (timed) on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4203203f At: net.schmizz.concurrent.Promise.tryRetrieve(Promise.java:171) net.schmizz.concurrent.Promise.retrieve(Promise.java:138) net.schmizz.concurrent.Event.await(Event.java:105) net.schmizz.sshj.connection.channel.AbstractChannel.join(AbstractChannel.java:267) org.apache.brooklyn.util.core.internal.ssh.sshj.SshjTool$ShellAction.create(SshjTool.java:1003) org.apache.brooklyn.util.core.internal.ssh.sshj.SshjTool$ShellAction.create(SshjTool.java:920) org.apache.brooklyn.util.core.internal.ssh.sshj.SshjTool.acquire(SshjTool.java:621) org.apache.brooklyn.util.core.internal.ssh.sshj.SshjTool.acquire(SshjTool.java:607) org.apache.brooklyn.util.core.internal.ssh.sshj.SshjTool$1.run(SshjTool.java:321) org.apache.brooklyn.util.core.internal.ssh.sshj.SshjTool.execScript(SshjTool.java:323) org.apache.brooklyn.util.core.task.system.internal.ExecWithLoggingHelpers$1.exec(ExecWithLoggingHelpers.java:78) org.apache.brooklyn.util.core.task.system.internal.ExecWithLoggingHelpers$3.apply(ExecWithLoggingHelpers.java:157) org.apache.brooklyn.util.core.task.system.internal.ExecWithLoggingHelpers$3.apply(ExecWithLoggingHelpers.java:154) org.apache.brooklyn.util.pool.BasicPool.exec(BasicPool.java:146) org.apache.brooklyn.location.ssh.SshMachineLocation.execSsh(SshMachineLocation.java:564) org.apache.brooklyn.location.ssh.SshMachineLocation$13.execWithTool(SshMachineLocation.java:744) org.apache.brooklyn.util.core.task.system.internal.ExecWithLoggingHelpers.execWithLogging(ExecWithLoggingHelpers.java:154) org.apache.brooklyn.util.core.task.system.internal.ExecWithLoggingHelpers.execScript(ExecWithLoggingHelpers.java:76) org.apache.brooklyn.location.ssh.SshMachineLocation.execScript(SshMachineLocation.java:727) org.apache.brooklyn.entity.software.base.AbstractSoftwareProcessSshDriver.execute(AbstractSoftwareProcessSshDriver.java:292) org.apache.brooklyn.entity.software.base.lifecycle.ScriptHelper.executeInternal(ScriptHelper.java:374) org.apache.brooklyn.entity.software.base.lifecycle.ScriptHelper$8.call(ScriptHelper.java:295) org.apache.brooklyn.entity.software.base.lifecycle.ScriptHelper$8.call(ScriptHelper.java:292) org.apache.brooklyn.util.core.task.DynamicSequentialTask$DstJob.call(DynamicSequentialTask.java:364) org.apache.brooklyn.util.core.task.BasicExecutionManager$SubmissionCallable.call(BasicExecutionManager.java:565){noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)