[ 
https://issues.apache.org/jira/browse/CAMEL-15315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Adam updated CAMEL-15315:
-------------------------------
    Description: 
When starting a spring-based Camel application, The following error is observed:

 

{{ }}

{{2020-07-19 21:33:08.236 ERROR 128775 — [ main] 
o.a.c.c.pulsar.utils.AutoConfiguration : java.lang.IllegalArgumentException: 
Invalid namespace format. namespace: default}}

 

Believe the error is being caused by a bug in the AutoConfiguration class, 
specifically the ensureNameSpace method: 

 

{{private void ensureNameSpace(String tenant, String namespace) throws 
PulsarAdminException { List<String> namespaces = 
this.pulsarAdmin.namespaces().getNamespaces(tenant); if 
(!namespaces.contains(namespace))}}

{{{ this.pulsarAdmin.namespaces().createNamespace(namespace, this.clusters); }}}

{{}}} 

 

The problem would appear to be that 
pulsarAdmin.namespaces().getNamespaces(tenant) returns a list of fully 
qualified namespaces (e.g., "default/public") whereas, the if check is 
comparing just the namespace alone (e.g. "public") against the fully qualified 
list. Naturally, this fails, and it then tries to create the namespace (which 
already exists), feeding it in the wrong format, causing the error to be thrown.

  was:
When starting a spring-based Camel application, The following error is observed:

 

{{ }}

{{{{2020-07-19 21:33:08.236 ERROR 128775 — [ main] 
o.a.c.c.pulsar.utils.AutoConfiguration : java.lang.IllegalArgumentException: 
Invalid namespace format. namespace: default}}}}

 

Believe the error is being caused by a bug in the AutoConfiguration class, 
specifically the ensureNameSpace method: 

 

{{ private void ensureNameSpace(String tenant, String namespace) throws 
PulsarAdminException \{ List<String> namespaces = 
this.pulsarAdmin.namespaces().getNamespaces(tenant); if 
(!namespaces.contains(namespace)) { 
this.pulsarAdmin.namespaces().createNamespace(namespace, this.clusters); } } }}

 

The problem would appear to be that 
pulsarAdmin.namespaces().getNamespaces(tenant) returns a list of fully 
qualified namespaces (e.g., "default/public") whereas, the if check is 
comparing just the namespace alone (e.g. "public") against the fully qualified 
list. Naturally, this fails, and it then tries to create the namespace (which 
already exists), feeding it in the wrong format, causing the error to be thrown.


> Camel-Pulsar: Error when verifying/creating namespace
> -----------------------------------------------------
>
>                 Key: CAMEL-15315
>                 URL: https://issues.apache.org/jira/browse/CAMEL-15315
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-pulsar
>    Affects Versions: 3.4.0
>         Environment: CentOS 8
> Running Pulsar in a docker container
> Spring Boot 2.3.1.RELEASE
> Camel version 3.4.0
>            Reporter: James Adam
>            Priority: Major
>
> When starting a spring-based Camel application, The following error is 
> observed:
>  
> {{ }}
> {{2020-07-19 21:33:08.236 ERROR 128775 — [ main] 
> o.a.c.c.pulsar.utils.AutoConfiguration : java.lang.IllegalArgumentException: 
> Invalid namespace format. namespace: default}}
>  
> Believe the error is being caused by a bug in the AutoConfiguration class, 
> specifically the ensureNameSpace method: 
>  
> {{private void ensureNameSpace(String tenant, String namespace) throws 
> PulsarAdminException { List<String> namespaces = 
> this.pulsarAdmin.namespaces().getNamespaces(tenant); if 
> (!namespaces.contains(namespace))}}
> {{{ this.pulsarAdmin.namespaces().createNamespace(namespace, this.clusters); 
> }}}
> {{}}} 
>  
> The problem would appear to be that 
> pulsarAdmin.namespaces().getNamespaces(tenant) returns a list of fully 
> qualified namespaces (e.g., "default/public") whereas, the if check is 
> comparing just the namespace alone (e.g. "public") against the fully 
> qualified list. Naturally, this fails, and it then tries to create the 
> namespace (which already exists), feeding it in the wrong format, causing the 
> error to be thrown.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to