You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by ahgittin <gi...@git.apache.org> on 2017/06/16 16:27:14 UTC

[GitHub] brooklyn-server pull request #737: [WIP] Clean up inference around parsing `...

GitHub user ahgittin opened a pull request:

    https://github.com/apache/brooklyn-server/pull/737

    [WIP] Clean up inference around parsing `name:version` strings

    We've had some rough heuristics how to find name and version but not a strict definition.
    
    This adds strict definitions in `RegisteredTypeNaming` (first commit).
    
    It then changes core to prefer these methods.  It doesn't change behaviour (except in a few fringe cases noted), but it does add log warnings where we were relying on hokey old strategies (previously assumed something was a version if it started with a number, that's it).
    
    Then clean up a bunch of deprecated stuff where the above was used.
    
    The methods in `RegisteredTypeNaming` let us hedge a little bit whether we want to be strict with OSGi versions or not.  That's a subject for another PR (but an important one as discussed at #672).

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/ahgittin/brooklyn-server version-id

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/brooklyn-server/pull/737.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #737
    
----
commit 36ffdeeca0ac5290727b3bf5d2a7267664e9638a
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2017-06-16T08:49:44Z

    remove REST reference to removed method

commit 3860c3498d63a9a9d880480363c7947599d40a7c
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2017-06-16T10:53:33Z

    new utilities for registered type (catalog item id) naming syntax

commit 607fc853aa395915e15d527405b7a7a8a6e97b48
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2017-06-16T12:24:28Z

    move many things to use RegisteredTypeNaming rather than hokey `looksLikeVersionedId`

commit eb08f8ec0d65b59bb2c4201a98632aa070ddac97
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2017-06-16T12:38:45Z

    notes on related methods for looking up catalog items flexibly

commit c9d03c93e35eb5417ca6168207f4b0ddc3de9e7c
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2017-06-16T12:46:20Z

    remove deprecated CAMP ServiceTypeResolver
    
    changed a while ago to EntitySpecResolver; removes references to catalog items and hokey lookup

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server pull request #737: Clean up inference around parsing `name:v...

Posted by ahgittin <gi...@git.apache.org>.
Github user ahgittin commented on a diff in the pull request:

    https://github.com/apache/brooklyn-server/pull/737#discussion_r124508624
  
    --- Diff: core/src/main/java/org/apache/brooklyn/core/catalog/internal/BasicBrooklynCatalog.java ---
    @@ -855,24 +893,50 @@ private boolean attemptType(String key, CatalogItemType candidateCiType) {
                 }
                 // first look in collected items, if a key is given
                 String type = (String) item.get("type");
    -            String version = null;
    -            if (CatalogUtils.looksLikeVersionedId(type)) {
    -                version = CatalogUtils.getVersionFromVersionedId(type);
    -                type = CatalogUtils.getSymbolicNameFromVersionedId(type);
    -            }
    +            
                 if (type!=null && key!=null) {
                     for (CatalogItemDtoAbstract<?,?> candidate: itemsDefinedSoFar) {
                         if (candidateCiType == candidate.getCatalogItemType() &&
                                 (type.equals(candidate.getSymbolicName()) || type.equals(candidate.getId()))) {
    -                        if (version==null || version.equals(candidate.getVersion())) {
    -                            // matched - exit
    -                            catalogItemType = candidateCiType;
    -                            planYaml = candidateYaml;
    -                            resolved = true;
    -                            return true;
    +                        // matched - exit
    +                        catalogItemType = candidateCiType;
    +                        planYaml = candidateYaml;
    +                        resolved = true;
    +                        return true;
    +                    }
    +                }
    +            }
    +            {
    +                // legacy routine; should be the same as above code added in 0.12 because:
    +                // if type is symbolic_name, the type will match below, and version will be null so any version allowed to match 
    --- End diff --
    
    yes, should be `above`


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server issue #737: Clean up inference around parsing `name:version`...

Posted by geomacy <gi...@git.apache.org>.
Github user geomacy commented on the issue:

    https://github.com/apache/brooklyn-server/pull/737
  
    Would also be interested in @neykov's comments on this!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server issue #737: Clean up inference around parsing `name:version`...

Posted by neykov <gi...@git.apache.org>.
Github user neykov commented on the issue:

    https://github.com/apache/brooklyn-server/pull/737
  
    @geomacy left my comments in https://github.com/apache/brooklyn-server/pull/740 which includes this PR.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server pull request #737: Clean up inference around parsing `name:v...

Posted by geomacy <gi...@git.apache.org>.
Github user geomacy commented on a diff in the pull request:

    https://github.com/apache/brooklyn-server/pull/737#discussion_r124510037
  
    --- Diff: core/src/main/java/org/apache/brooklyn/core/catalog/internal/BasicBrooklynCatalog.java ---
    @@ -855,24 +893,50 @@ private boolean attemptType(String key, CatalogItemType candidateCiType) {
                 }
                 // first look in collected items, if a key is given
                 String type = (String) item.get("type");
    -            String version = null;
    -            if (CatalogUtils.looksLikeVersionedId(type)) {
    -                version = CatalogUtils.getVersionFromVersionedId(type);
    -                type = CatalogUtils.getSymbolicNameFromVersionedId(type);
    -            }
    +            
                 if (type!=null && key!=null) {
                     for (CatalogItemDtoAbstract<?,?> candidate: itemsDefinedSoFar) {
                         if (candidateCiType == candidate.getCatalogItemType() &&
                                 (type.equals(candidate.getSymbolicName()) || type.equals(candidate.getId()))) {
    -                        if (version==null || version.equals(candidate.getVersion())) {
    -                            // matched - exit
    -                            catalogItemType = candidateCiType;
    -                            planYaml = candidateYaml;
    -                            resolved = true;
    -                            return true;
    +                        // matched - exit
    +                        catalogItemType = candidateCiType;
    +                        planYaml = candidateYaml;
    +                        resolved = true;
    +                        return true;
    +                    }
    +                }
    +            }
    +            {
    +                // legacy routine; should be the same as above code added in 0.12 because:
    +                // if type is symbolic_name, the type will match below, and version will be null so any version allowed to match 
    --- End diff --
    
    grand, but how about the question above where type is of form symbolic_name:version? When you say "the id will match", where does that happen?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server issue #737: Clean up inference around parsing `name:version`...

Posted by ahgittin <gi...@git.apache.org>.
Github user ahgittin commented on the issue:

    https://github.com/apache/brooklyn-server/pull/737
  
    @geomacy @neykov ready for review.  does not do the version changes discussed on ML but prepares us for them (and helped me understand them).  this is mainly to fix issues where people have used funny `v1` version strings.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server issue #737: [WIP] Clean up inference around parsing `name:ve...

Posted by ahgittin <gi...@git.apache.org>.
Github user ahgittin commented on the issue:

    https://github.com/apache/brooklyn-server/pull/737
  
    (There is a failing test, I'm working on that, otherwise this is good to review.)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server pull request #737: Clean up inference around parsing `name:v...

Posted by asfgit <gi...@git.apache.org>.
Github user asfgit closed the pull request at:

    https://github.com/apache/brooklyn-server/pull/737


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server issue #737: Clean up inference around parsing `name:version`...

Posted by ahgittin <gi...@git.apache.org>.
Github user ahgittin commented on the issue:

    https://github.com/apache/brooklyn-server/pull/737
  
    re tests - see #740 which merges this and test pass


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server issue #737: Clean up inference around parsing `name:version`...

Posted by ahgittin <gi...@git.apache.org>.
Github user ahgittin commented on the issue:

    https://github.com/apache/brooklyn-server/pull/737
  
    great comments here @geomacy , addressed all except where commented above; moving on to #740


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server pull request #737: Clean up inference around parsing `name:v...

Posted by geomacy <gi...@git.apache.org>.
Github user geomacy commented on a diff in the pull request:

    https://github.com/apache/brooklyn-server/pull/737#discussion_r124014747
  
    --- Diff: core/src/main/java/org/apache/brooklyn/core/typereg/RegisteredTypeNaming.java ---
    @@ -0,0 +1,111 @@
    +/*
    + * Licensed to the Apache Software Foundation (ASF) under one
    + * or more contributor license agreements.  See the NOTICE file
    + * distributed with this work for additional information
    + * regarding copyright ownership.  The ASF licenses this file
    + * to you under the Apache License, Version 2.0 (the
    + * "License"); you may not use this file except in compliance
    + * with the License.  You may obtain a copy of the License at
    + *
    + *     http://www.apache.org/licenses/LICENSE-2.0
    + *
    + * Unless required by applicable law or agreed to in writing,
    + * software distributed under the License is distributed on an
    + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
    + * KIND, either express or implied.  See the License for the
    + * specific language governing permissions and limitations
    + * under the License.
    + */
    +package org.apache.brooklyn.core.typereg;
    +
    +/**
    + * Methods for testing validity of names and decomposing them. 
    + * Mostly based on OSGi, specifically sections 1.3.2 and 3.2.5 of 
    + * osgi.core-4.3.0 spec (https://www.osgi.org/release-4-version-4-3-download/). */
    +public class RegisteredTypeNaming {
    +
    +    private static final String USABLE_REGEX = "[^:\\s/\\\\]+";
    +
    +    private final static String DOT = "\\.";
    +    
    +    public final static String OSGI_TOKEN_CHARS = "A-Za-z0-9_-";
    +    public final static String OSGI_TOKEN_REGEX = "[" + OSGI_TOKEN_CHARS + "]+";
    +    public final static String OSGI_SYMBOLIC_NAME_REGEX = OSGI_TOKEN_REGEX + "(" + DOT + OSGI_TOKEN_REGEX + ")*";
    +    public final static String NUMBER = "[0-9]+";
    +    public final static String QUALIFIER = OSGI_TOKEN_REGEX;
    +    public final static String VERSION_REGEX = 
    +        NUMBER + 
    +            "(" + "\\." + NUMBER +  
    --- End diff --
    
    You've already defined `DOT`, might as well use it here.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server pull request #737: Clean up inference around parsing `name:v...

Posted by geomacy <gi...@git.apache.org>.
Github user geomacy commented on a diff in the pull request:

    https://github.com/apache/brooklyn-server/pull/737#discussion_r124058288
  
    --- Diff: core/src/main/java/org/apache/brooklyn/core/catalog/internal/BasicBrooklynCatalog.java ---
    @@ -855,24 +893,50 @@ private boolean attemptType(String key, CatalogItemType candidateCiType) {
                 }
                 // first look in collected items, if a key is given
                 String type = (String) item.get("type");
    -            String version = null;
    -            if (CatalogUtils.looksLikeVersionedId(type)) {
    -                version = CatalogUtils.getVersionFromVersionedId(type);
    -                type = CatalogUtils.getSymbolicNameFromVersionedId(type);
    -            }
    +            
                 if (type!=null && key!=null) {
                     for (CatalogItemDtoAbstract<?,?> candidate: itemsDefinedSoFar) {
                         if (candidateCiType == candidate.getCatalogItemType() &&
                                 (type.equals(candidate.getSymbolicName()) || type.equals(candidate.getId()))) {
    -                        if (version==null || version.equals(candidate.getVersion())) {
    -                            // matched - exit
    -                            catalogItemType = candidateCiType;
    -                            planYaml = candidateYaml;
    -                            resolved = true;
    -                            return true;
    +                        // matched - exit
    +                        catalogItemType = candidateCiType;
    +                        planYaml = candidateYaml;
    +                        resolved = true;
    +                        return true;
    +                    }
    +                }
    +            }
    +            {
    +                // legacy routine; should be the same as above code added in 0.12 because:
    +                // if type is symbolic_name, the type will match below, and version will be null so any version allowed to match 
    --- End diff --
    
    I'm afraid I don't follow this - is it the case that a type which is just a `symbolic_name` will be taken care of by line 900 above (so you actually mean "the type will match above" on this line i.e. at line 900); but how is the next case handled, where type is of form `symbolic_name:version`?   When you say `the id will match`, where does that happen?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server pull request #737: Clean up inference around parsing `name:v...

Posted by geomacy <gi...@git.apache.org>.
Github user geomacy commented on a diff in the pull request:

    https://github.com/apache/brooklyn-server/pull/737#discussion_r124033012
  
    --- Diff: core/src/main/java/org/apache/brooklyn/core/catalog/internal/BasicBrooklynCatalog.java ---
    @@ -855,24 +893,50 @@ private boolean attemptType(String key, CatalogItemType candidateCiType) {
                 }
                 // first look in collected items, if a key is given
                 String type = (String) item.get("type");
    -            String version = null;
    -            if (CatalogUtils.looksLikeVersionedId(type)) {
    -                version = CatalogUtils.getVersionFromVersionedId(type);
    -                type = CatalogUtils.getSymbolicNameFromVersionedId(type);
    -            }
    +            
                 if (type!=null && key!=null) {
                     for (CatalogItemDtoAbstract<?,?> candidate: itemsDefinedSoFar) {
                         if (candidateCiType == candidate.getCatalogItemType() &&
                                 (type.equals(candidate.getSymbolicName()) || type.equals(candidate.getId()))) {
    -                        if (version==null || version.equals(candidate.getVersion())) {
    -                            // matched - exit
    -                            catalogItemType = candidateCiType;
    -                            planYaml = candidateYaml;
    -                            resolved = true;
    -                            return true;
    +                        // matched - exit
    +                        catalogItemType = candidateCiType;
    +                        planYaml = candidateYaml;
    +                        resolved = true;
    +                        return true;
    +                    }
    +                }
    +            }
    +            {
    +                // legacy routine; should be the same as above code added in 0.12 because:
    +                // if type is symbolic_name, the type will match below, and version will be null so any version allowed to match 
    +                // if type is symbolic_name:version, the id will match, and the version will also have to match 
    +                // SHOULD NEVER NEED THIS - remove during or after 0.13
    +                String typeWithId = type;
    +                String version = null;
    +                if (CatalogUtils.looksLikeVersionedId(type)) {
    +                    version = CatalogUtils.getVersionFromVersionedId(type);
    +                    type = CatalogUtils.getSymbolicNameFromVersionedId(type);
    +                }
    +                if (type!=null && key!=null) {
    +                    for (CatalogItemDtoAbstract<?,?> candidate: itemsDefinedSoFar) {
    +                        if (candidateCiType == candidate.getCatalogItemType() &&
    +                                (type.equals(candidate.getSymbolicName()) || type.equals(candidate.getId()))) {
    +                            if (version==null || version.equals(candidate.getVersion())) {
    +                                log.warn("Lookup of '"+type+"' version '"+version+"' only worked using legacy routines; please advise Brooklyn community so they understand why");
    --- End diff --
    
    Maybe we should even make this an `error` to highlight it more?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server pull request #737: Clean up inference around parsing `name:v...

Posted by geomacy <gi...@git.apache.org>.
Github user geomacy commented on a diff in the pull request:

    https://github.com/apache/brooklyn-server/pull/737#discussion_r124018550
  
    --- Diff: camp/camp-brooklyn/src/main/java/org/apache/brooklyn/camp/brooklyn/spi/creation/BrooklynComponentTemplateResolver.java ---
    @@ -82,7 +79,6 @@
      * This generates instances of a template resolver that use a {@link ServiceTypeResolver}
    --- End diff --
    
    Best to update description now `ServiceTypeResolver` is deleted.  Should probably also remove [this](https://github.com/apache/brooklyn-server/blob/master/camp/camp-brooklyn/src/test/resources/META-INF/services/org.apache.brooklyn.camp.brooklyn.spi.creation.service.ServiceTypeResolver) now too.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server pull request #737: Clean up inference around parsing `name:v...

Posted by geomacy <gi...@git.apache.org>.
Github user geomacy commented on a diff in the pull request:

    https://github.com/apache/brooklyn-server/pull/737#discussion_r124025405
  
    --- Diff: core/src/main/java/org/apache/brooklyn/core/catalog/internal/BasicBrooklynCatalog.java ---
    @@ -601,14 +602,34 @@ private void collectCatalogItems(String sourceYaml, Map<?,?> itemMetadata, List<
             // if symname not set, infer from: id, then name, then item id, then item name
             if (Strings.isBlank(symbolicName)) {
    --- End diff --
    
    The changes in this block and the one below on versions are really pushing the line number count of this method, would be nice to split them out into another method; could it even be a method of `RegisteredTypeNaming`?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server issue #737: Clean up inference around parsing `name:version`...

Posted by ahgittin <gi...@git.apache.org>.
Github user ahgittin commented on the issue:

    https://github.com/apache/brooklyn-server/pull/737
  
    (the test failure is a test env config issue in hudson remoting)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server issue #737: Clean up inference around parsing `name:version`...

Posted by geomacy <gi...@git.apache.org>.
Github user geomacy commented on the issue:

    https://github.com/apache/brooklyn-server/pull/737
  
    👍  I was going to look at that next :-)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server pull request #737: Clean up inference around parsing `name:v...

Posted by ahgittin <gi...@git.apache.org>.
Github user ahgittin commented on a diff in the pull request:

    https://github.com/apache/brooklyn-server/pull/737#discussion_r124508303
  
    --- Diff: core/src/main/java/org/apache/brooklyn/core/catalog/internal/BasicBrooklynCatalog.java ---
    @@ -601,14 +602,34 @@ private void collectCatalogItems(String sourceYaml, Map<?,?> itemMetadata, List<
             // if symname not set, infer from: id, then name, then item id, then item name
             if (Strings.isBlank(symbolicName)) {
    --- End diff --
    
    want to completely gut this class as soon as #363 YOML is available, and remove much of this once 0.12.0 is out -- refactoring i think would make that harder as well as of course not being worth the effort if we're gutting it


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server issue #737: Clean up inference around parsing `name:version`...

Posted by geomacy <gi...@git.apache.org>.
Github user geomacy commented on the issue:

    https://github.com/apache/brooklyn-server/pull/737
  
    @ahgittin haven't ignored this but haven't been able to find the bandwidth to look at it - will be off tomorrow, but will look at this and related PRs on Monday!  


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server pull request #737: Clean up inference around parsing `name:v...

Posted by geomacy <gi...@git.apache.org>.
Github user geomacy commented on a diff in the pull request:

    https://github.com/apache/brooklyn-server/pull/737#discussion_r124013780
  
    --- Diff: core/src/main/java/org/apache/brooklyn/core/typereg/RegisteredTypeNaming.java ---
    @@ -0,0 +1,111 @@
    +/*
    + * Licensed to the Apache Software Foundation (ASF) under one
    + * or more contributor license agreements.  See the NOTICE file
    + * distributed with this work for additional information
    + * regarding copyright ownership.  The ASF licenses this file
    + * to you under the Apache License, Version 2.0 (the
    + * "License"); you may not use this file except in compliance
    + * with the License.  You may obtain a copy of the License at
    + *
    + *     http://www.apache.org/licenses/LICENSE-2.0
    + *
    + * Unless required by applicable law or agreed to in writing,
    + * software distributed under the License is distributed on an
    + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
    + * KIND, either express or implied.  See the License for the
    + * specific language governing permissions and limitations
    + * under the License.
    + */
    +package org.apache.brooklyn.core.typereg;
    +
    +/**
    + * Methods for testing validity of names and decomposing them. 
    + * Mostly based on OSGi, specifically sections 1.3.2 and 3.2.5 of 
    + * osgi.core-4.3.0 spec (https://www.osgi.org/release-4-version-4-3-download/). */
    +public class RegisteredTypeNaming {
    +
    +    private static final String USABLE_REGEX = "[^:\\s/\\\\]+";
    +
    +    private final static String DOT = "\\.";
    +    
    +    public final static String OSGI_TOKEN_CHARS = "A-Za-z0-9_-";
    +    public final static String OSGI_TOKEN_REGEX = "[" + OSGI_TOKEN_CHARS + "]+";
    +    public final static String OSGI_SYMBOLIC_NAME_REGEX = OSGI_TOKEN_REGEX + "(" + DOT + OSGI_TOKEN_REGEX + ")*";
    +    public final static String NUMBER = "[0-9]+";
    +    public final static String QUALIFIER = OSGI_TOKEN_REGEX;
    +    public final static String VERSION_REGEX = 
    +        NUMBER + 
    +            "(" + "\\." + NUMBER +  
    +                "(" + "\\." + NUMBER +  
    +                    "(" + "\\." + QUALIFIER +  
    +                    ")?" +
    +                ")?" +
    +            ")?";
    +
    +    private static boolean isUsable(String candidate) {
    +        return candidate!=null && candidate.matches(USABLE_REGEX);
    +    }
    +    
    +    /** 
    +     * For type names we currently work with any non-empty string that does not contain 
    +     * a ':' or whitespace or forward slash or backslash.
    +     * However we discourage things that are not OSGi symbolic names; see {@link #isValidTypeName(String)}. 
    --- End diff --
    
    `isGoodTypeName` not `isValidTypeName` 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---