[
https://issues.apache.org/jira/browse/KARAF-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306140#comment-14306140
]
Nicholas Rundle commented on KARAF-3498:
----------------------------------------
I'm sorry if I made this confusing by bringing in Pax-Exam, I was trying to set
the context for when I found the issue. Pax-Exam contributed to the problem by
the way it named the JAR during container provisioning. However, if I simply
run the karaf container and then drop in a JAR with the name I gave in the
description into the deploy folder, then a NumberFormatException is thrown when
trying to parse the version.
As a workaround I explicitly added a bundle version to the wrap URL but the
wrap deployer is supposed to work without this and should not cause an
exception when trying to populate the Bundle-SymbolicName and Bundle-Version
from the jar file path.
> Wrap deployer extracts invalid version from JAR name
> ----------------------------------------------------
>
> Key: KARAF-3498
> URL: https://issues.apache.org/jira/browse/KARAF-3498
> Project: Karaf
> Issue Type: Bug
> Affects Versions: 3.0.1
> Reporter: Nicholas Rundle
>
> DeployerUtils.java extractNameVersionType() uses a regex pattern to attempt
> and extract a Bundle-SymbolicName and Bundle-Version from the URL of the JAR
> when using the Wrap deployer. This regex pattern may extract a version which
> causes a NumberFormatException in org.osgi.framework.Version.parseInt()
> When using PAX Exam dependent JARs provisioned with mavenBundle are deployed
> with a UUID and version as the file name. For example, our maven project
> depends on org.json version 20140107. This maven bundle was deployed with
> the following JAR name:
> 37b66f72-d42c-40ff-86ea-972550695850_20140107.jar
> The regex pattern in deployer utils inadvertently pulls the version as
> "972550695850.0.0.20140107". The major version is too large to parse and
> causes an exception.
> Since this util method has a fallback to using "0.0.0" in the case of no
> regex match, I propose that if a version is extracted the major, minor, and
> micro versions be validated and perhaps set to "0" if they cannot be parsed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
