[jira] [Commented] (SCM-1022) jgit push failure is not failing the build
[
https://issues.apache.org/jira/browse/SCM-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833892#comment-17833892
]
Mattias Andersson commented on SCM-1022:
[~michael-o] we created the PR above. Any feedback would be appreciated.
> jgit push failure is not failing the build
> --
>
> Key: SCM-1022
> URL: https://issues.apache.org/jira/browse/SCM-1022
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-jgit
>Affects Versions: 2.0.1
>Reporter: Mattias Andersson
>Priority: Major
>
> If the push command fails, the maven build does not fail. This means binaries
> are deployed, but the remote repo is not updated. The issue seems related to
> SCM-854.
> We use Gerrit and have the merge strategy set to "fast forward only". If
> someone pushes a commit during the release job, only an INFO message is
> logged, but the maven build is successful.
> The same use case with the maven-scm-provider-gitexe (the default) fails the
> build as expected (git push returns a non-zero exit code)
> {code:java}
> 10:28:03 [INFO] commit done: [maven-release-plugin] prepare release 2.15.0
> 10:28:03 [INFO] push changes to remote... refs/heads/master:refs/heads/master
> 10:28:03 [INFO] fetch url: ssh://xxx@xxx
> 10:28:03 [INFO] push url: ssh://xxx@xxx
> 10:28:03 [INFO] getOrCreateProvider(EdDSA) created instance of
> net.i2p.crypto.eddsa.EdDSASecurityProvider
> 10:28:03 [INFO] No detected/configured IoServiceFactoryFactory using
> Nio2ServiceFactoryFactory
> 10:28:04 [INFO] REJECTED_NONFASTFORWARD -
> RemoteRefUpdate[remoteName=refs/heads/master, REJECTED_NONFASTFORWARD,
> 1eee06203068576ddcaae4eefe0ea15a52fb49ba...3102c82c6b62d4e86c75194569c2574ac722b6dd,
> srcRef=refs/heads/master, message=null]
> 10:28:04 [INFO] 12/17 prepare:scm-tag
> 10:28:04 [INFO] Tagging release with the label 2.15.0...
> 10:28:04 [INFO] push tag [2.15.0] to remote...
> 10:28:04 [INFO] fetch url: ssh://xxx@xxx
> 10:28:04 [INFO] push url: ssh://xxx@xxx
> 10:28:05 [INFO] OK - RemoteRefUpdate[remoteName=refs/tags/2.15.0, OK,
> ...968d97de8331ce19d43c719e870890def5ee65d9,
> fastForward, srcRef=refs/tags/2.15.0, message=null]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SCM-1022) jgit push failure is not failing the build
[
https://issues.apache.org/jira/browse/SCM-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833532#comment-17833532
]
Mattias Andersson commented on SCM-1022:
The problem seems to be that the return value from JGitUtils.push is ignored in:
{noformat}
org.apache.maven.scm.provider.git.jgit.command.checkin.JGitCheckInCommand#executeCheckInCommand{noformat}
We could try to provide a PR if that would be interesting?
> jgit push failure is not failing the build
> --
>
> Key: SCM-1022
> URL: https://issues.apache.org/jira/browse/SCM-1022
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-jgit
>Affects Versions: 2.0.1
>Reporter: Mattias Andersson
>Priority: Major
>
> If the push command fails, the maven build does not fail. This means binaries
> are deployed, but the remote repo is not updated. The issue seems related to
> SCM-854.
> We use Gerrit and have the merge strategy set to "fast forward only". If
> someone pushes a commit during the release job, only an INFO message is
> logged, but the maven build is successful.
> The same use case with the maven-scm-provider-gitexe (the default) fails the
> build as expected (git push returns a non-zero exit code)
> {code:java}
> 10:28:03 [INFO] commit done: [maven-release-plugin] prepare release 2.15.0
> 10:28:03 [INFO] push changes to remote... refs/heads/master:refs/heads/master
> 10:28:03 [INFO] fetch url: ssh://xxx@xxx
> 10:28:03 [INFO] push url: ssh://xxx@xxx
> 10:28:03 [INFO] getOrCreateProvider(EdDSA) created instance of
> net.i2p.crypto.eddsa.EdDSASecurityProvider
> 10:28:03 [INFO] No detected/configured IoServiceFactoryFactory using
> Nio2ServiceFactoryFactory
> 10:28:04 [INFO] REJECTED_NONFASTFORWARD -
> RemoteRefUpdate[remoteName=refs/heads/master, REJECTED_NONFASTFORWARD,
> 1eee06203068576ddcaae4eefe0ea15a52fb49ba...3102c82c6b62d4e86c75194569c2574ac722b6dd,
> srcRef=refs/heads/master, message=null]
> 10:28:04 [INFO] 12/17 prepare:scm-tag
> 10:28:04 [INFO] Tagging release with the label 2.15.0...
> 10:28:04 [INFO] push tag [2.15.0] to remote...
> 10:28:04 [INFO] fetch url: ssh://xxx@xxx
> 10:28:04 [INFO] push url: ssh://xxx@xxx
> 10:28:05 [INFO] OK - RemoteRefUpdate[remoteName=refs/tags/2.15.0, OK,
> ...968d97de8331ce19d43c719e870890def5ee65d9,
> fastForward, srcRef=refs/tags/2.15.0, message=null]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SCM-1022) jgit push failure is not failing the build
Mattias Andersson created SCM-1022:
--
Summary: jgit push failure is not failing the build
Key: SCM-1022
URL: https://issues.apache.org/jira/browse/SCM-1022
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-jgit
Affects Versions: 2.0.1
Reporter: Mattias Andersson
If the push command fails, the maven build does not fail. This means binaries
are deployed, but the remote repo is not updated. The issue seems related to
SCM-854.
We use Gerrit and have the merge strategy set to "fast forward only". If
someone pushes a commit during the release job, only an INFO message is logged,
but the maven build is successful.
The same use case with the maven-scm-provider-gitexe (the default) fails the
build as expected (git push returns a non-zero exit code)
{code:java}
10:28:03 [INFO] commit done: [maven-release-plugin] prepare release 2.15.0
10:28:03 [INFO] push changes to remote... refs/heads/master:refs/heads/master
10:28:03 [INFO] fetch url: ssh://xxx@xxx
10:28:03 [INFO] push url: ssh://xxx@xxx
10:28:03 [INFO] getOrCreateProvider(EdDSA) created instance of
net.i2p.crypto.eddsa.EdDSASecurityProvider
10:28:03 [INFO] No detected/configured IoServiceFactoryFactory using
Nio2ServiceFactoryFactory
10:28:04 [INFO] REJECTED_NONFASTFORWARD -
RemoteRefUpdate[remoteName=refs/heads/master, REJECTED_NONFASTFORWARD,
1eee06203068576ddcaae4eefe0ea15a52fb49ba...3102c82c6b62d4e86c75194569c2574ac722b6dd,
srcRef=refs/heads/master, message=null]
10:28:04 [INFO] 12/17 prepare:scm-tag
10:28:04 [INFO] Tagging release with the label 2.15.0...
10:28:04 [INFO] push tag [2.15.0] to remote...
10:28:04 [INFO] fetch url: ssh://xxx@xxx
10:28:04 [INFO] push url: ssh://xxx@xxx
10:28:05 [INFO] OK - RemoteRefUpdate[remoteName=refs/tags/2.15.0, OK,
...968d97de8331ce19d43c719e870890def5ee65d9,
fastForward, srcRef=refs/tags/2.15.0, message=null]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AVRO-2897) Unable to create nullable fields in Avro JavaScript implementation
[
https://issues.apache.org/jira/browse/AVRO-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mattias Andersson updated AVRO-2897:
Description:
I apologize in advance if this is a misunderstanding of funcitonality on my
part and I have only tested it on the latest published npm package
([https://www.npmjs.com/package/avro-js]) but if not this should be a rather
serious bug.
According to multiple sources
([https://avro.apache.org/docs/1.8.1/spec.htm|https://avro.apache.org/docs/1.8.1/spec.html]),
nullable values should be specified as a unon with the type null, e.g. for
string "['null', 'string']"
However, given the following code (that from what I understand should be valid)
{code:java}
var type = avro.parse({
name: 'Pet',
type: 'record',
fields: [
{ name: 'name', type: ['null', 'string'] }
]
});
var pet = { name: "Fido" };
var buf = type.toBuffer(pet);
var obj = type.fromBuffer(buf);
console.log(obj);
{code}
I get the followin error on "type.toBuffer(pet)"
{code:java}
Error: invalid ["null","string"]: "Fido"
{code}
Curiously, if I instead set pet name as "null" instead of "Fido" everything
runs fine and returns a correct output given the input. Though this is not very
useful as the field still can not be changed to anything else beside null.
{code:java}
...
var pet = { name: null };
...
console.log(obj);{code}
{code:java}
Pet { name: null }
{code}
Expected behavior is that both string and null should be valid parameters
without throwing an exception.
was:
I apologize in advance if this is a misunderstanding of funcitonality on my
part and I have only tested it on the latest published npm package
([https://www.npmjs.com/package/avro-js]) but if not this should be a rather
serious bug.
According to multiple sources
([https://avro.apache.org/docs/1.8.1/spec.htm|https://avro.apache.org/docs/1.8.1/spec.html]),
nullable values should be specified as a unon with the type null, e.g. for
string "['null', 'string']"
However, given the following code (that from what I understand should be valid)
{code:java}
var type = avro.parse({
name: 'Pet',
type: 'record',
fields: [
{ name: 'name', type: ['null', 'string'] }
]
});
var pet = { name: "Fido" };
var buf = type.toBuffer(pet);
var obj = type.fromBuffer(buf);
console.log(obj);
{code}
I get the followin error on "type.toBuffer(pet)"
{code:java}
Error: invalid ["null","string"]: "Fido"
{code}
Curiously, if I instead set pet name as "null" instead of "Fido" everything
runs fine and returns a correct output given the input. Though this is not very
useful as the field still can not be changed to anything else beside null.
{code:java}
...
var pet = { name: null };
...
console.log(obj);{code}
{code:java}
Pet { name: null }
{code}
> Unable to create nullable fields in Avro JavaScript implementation
> --
>
> Key: AVRO-2897
> URL: https://issues.apache.org/jira/browse/AVRO-2897
> Project: Apache Avro
> Issue Type: Bug
> Components: javascript
>Affects Versions: 1.10.0
>Reporter: Mattias Andersson
>Priority: Major
>
>
> I apologize in advance if this is a misunderstanding of funcitonality on my
> part and I have only tested it on the latest published npm package
> ([https://www.npmjs.com/package/avro-js]) but if not this should be a rather
> serious bug.
> According to multiple sources
> ([https://avro.apache.org/docs/1.8.1/spec.htm|https://avro.apache.org/docs/1.8.1/spec.html]),
> nullable values should be specified as a unon with the type null, e.g. for
> string "['null', 'string']"
> However, given the following code (that from what I understand should be
> valid)
> {code:java}
> var type = avro.parse({
> name: 'Pet',
> type: 'record',
> fields: [
> { name: 'name', type: ['null', 'string'] }
> ]
> });
> var pet = { name: "Fido" };
> var buf = type.toBuffer(pet);
> var obj = type.fromBuffer(buf);
> console.log(obj);
> {code}
> I get the followin error on "type.toBuffer(pet)"
> {code:java}
> Error: invalid ["null","string"]: "Fido"
> {code}
>
> Curiously, if I instead set pet name as "null" instead of "Fido" everything
> runs fine and returns a correct output given the input. Though this is not
> very useful as the field still can not be changed to anything else beside
> null.
> {code:java}
> ...
> var pet = { name: null };
> ...
> console.log(obj);{code}
> {code:java}
> Pet { name: null }
> {code}
>
> Expected behavior is that both string and null should be valid parameters
> without throwing an exception.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (AVRO-2897) Unable to create nullable fields in Avro JavaScript implementation
[
https://issues.apache.org/jira/browse/AVRO-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mattias Andersson updated AVRO-2897:
Description:
I apologize in advance if this is a misunderstanding of funcitonality on my
part and I have only tested it on the latest published npm package
([https://www.npmjs.com/package/avro-js]) but if not this should be a rather
serious bug.
According to multiple sources
([https://avro.apache.org/docs/1.8.1/spec.htm|https://avro.apache.org/docs/1.8.1/spec.html]),
nullable values should be specified as a unon with the type null, e.g. for
string "['null', 'string']"
However, given the following code (that from what I understand should be valid)
{code:java}
var type = avro.parse({
name: 'Pet',
type: 'record',
fields: [
{ name: 'name', type: ['null', 'string'] }
]
});
var pet = { name: "Fido" };
var buf = type.toBuffer(pet);
var obj = type.fromBuffer(buf);
console.log(obj);
{code}
I get the followin error
{code:java}
Error: invalid ["null","string"]: "Fido"
{code}
Curiously, if I instead set pet name as "null" instead of "Fido" everything
runs fine and returns a correct output given the input. Though this is not very
useful as the field still can not be changed to anything else beside null.
{code:java}
...
var pet = { name: null };
...
console.log(obj);{code}
{code:java}
Pet { name: null }
{code}
was:
I apologize in advance if this is a misunderstanding of funcitonality on my
part and I have only tested it on the latest published npm package
([https://www.npmjs.com/package/avro-js]) but if not this should be a rather
serious bug.
According to multiple sources
([https://avro.apache.org/docs/1.8.1/spec.htm|https://avro.apache.org/docs/1.8.1/spec.html]),
nullable values should be specified as a unon with the type null, e.g. for
string "['null', 'string']"
However, given the following code (that from what I understand should be valid)
{code:java}
var type = avro.parse({
name: 'Pet',
type: 'record',
fields: [
{ name: 'name', type: ['null', 'string'] }
]
});
var pet = { name: "Fido" };
var buf = type.toBuffer(pet);
var obj = type.fromBuffer(buf);
console.log(obj);
{code}
I get the followin error
{code:java}
Error: invalid ["null","string"]: "Fido"
{code}
Curiously, if I instead set pet name as "null" instead of "Fido" everything
runs fine and returns a correct output given the input. Though this is not very
useful as the field still can not be changed to anything else beside null.
{code:java}
Pet { name: null }
{code}
> Unable to create nullable fields in Avro JavaScript implementation
> --
>
> Key: AVRO-2897
> URL: https://issues.apache.org/jira/browse/AVRO-2897
> Project: Apache Avro
> Issue Type: Bug
> Components: javascript
>Affects Versions: 1.10.0
>Reporter: Mattias Andersson
>Priority: Major
>
>
> I apologize in advance if this is a misunderstanding of funcitonality on my
> part and I have only tested it on the latest published npm package
> ([https://www.npmjs.com/package/avro-js]) but if not this should be a rather
> serious bug.
> According to multiple sources
> ([https://avro.apache.org/docs/1.8.1/spec.htm|https://avro.apache.org/docs/1.8.1/spec.html]),
> nullable values should be specified as a unon with the type null, e.g. for
> string "['null', 'string']"
> However, given the following code (that from what I understand should be
> valid)
> {code:java}
> var type = avro.parse({
> name: 'Pet',
> type: 'record',
> fields: [
> { name: 'name', type: ['null', 'string'] }
> ]
> });
> var pet = { name: "Fido" };
> var buf = type.toBuffer(pet);
> var obj = type.fromBuffer(buf);
> console.log(obj);
> {code}
> I get the followin error
> {code:java}
> Error: invalid ["null","string"]: "Fido"
> {code}
>
> Curiously, if I instead set pet name as "null" instead of "Fido" everything
> runs fine and returns a correct output given the input. Though this is not
> very useful as the field still can not be changed to anything else beside
> null.
> {code:java}
> ...
> var pet = { name: null };
> ...
> console.log(obj);{code}
> {code:java}
> Pet { name: null }
> {code}
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (AVRO-2897) Unable to create nullable fields in Avro JavaScript implementation
[
https://issues.apache.org/jira/browse/AVRO-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mattias Andersson updated AVRO-2897:
Description:
I apologize in advance if this is a misunderstanding of funcitonality on my
part and I have only tested it on the latest published npm package
([https://www.npmjs.com/package/avro-js]) but if not this should be a rather
serious bug.
According to multiple sources
([https://avro.apache.org/docs/1.8.1/spec.htm|https://avro.apache.org/docs/1.8.1/spec.html]),
nullable values should be specified as a unon with the type null, e.g. for
string "['null', 'string']"
However, given the following code (that from what I understand should be valid)
{code:java}
var type = avro.parse({
name: 'Pet',
type: 'record',
fields: [
{ name: 'name', type: ['null', 'string'] }
]
});
var pet = { name: "Fido" };
var buf = type.toBuffer(pet);
var obj = type.fromBuffer(buf);
console.log(obj);
{code}
I get the followin error on "type.toBuffer(pet)"
{code:java}
Error: invalid ["null","string"]: "Fido"
{code}
Curiously, if I instead set pet name as "null" instead of "Fido" everything
runs fine and returns a correct output given the input. Though this is not very
useful as the field still can not be changed to anything else beside null.
{code:java}
...
var pet = { name: null };
...
console.log(obj);{code}
{code:java}
Pet { name: null }
{code}
was:
I apologize in advance if this is a misunderstanding of funcitonality on my
part and I have only tested it on the latest published npm package
([https://www.npmjs.com/package/avro-js]) but if not this should be a rather
serious bug.
According to multiple sources
([https://avro.apache.org/docs/1.8.1/spec.htm|https://avro.apache.org/docs/1.8.1/spec.html]),
nullable values should be specified as a unon with the type null, e.g. for
string "['null', 'string']"
However, given the following code (that from what I understand should be valid)
{code:java}
var type = avro.parse({
name: 'Pet',
type: 'record',
fields: [
{ name: 'name', type: ['null', 'string'] }
]
});
var pet = { name: "Fido" };
var buf = type.toBuffer(pet);
var obj = type.fromBuffer(buf);
console.log(obj);
{code}
I get the followin error
{code:java}
Error: invalid ["null","string"]: "Fido"
{code}
Curiously, if I instead set pet name as "null" instead of "Fido" everything
runs fine and returns a correct output given the input. Though this is not very
useful as the field still can not be changed to anything else beside null.
{code:java}
...
var pet = { name: null };
...
console.log(obj);{code}
{code:java}
Pet { name: null }
{code}
> Unable to create nullable fields in Avro JavaScript implementation
> --
>
> Key: AVRO-2897
> URL: https://issues.apache.org/jira/browse/AVRO-2897
> Project: Apache Avro
> Issue Type: Bug
> Components: javascript
>Affects Versions: 1.10.0
>Reporter: Mattias Andersson
>Priority: Major
>
>
> I apologize in advance if this is a misunderstanding of funcitonality on my
> part and I have only tested it on the latest published npm package
> ([https://www.npmjs.com/package/avro-js]) but if not this should be a rather
> serious bug.
> According to multiple sources
> ([https://avro.apache.org/docs/1.8.1/spec.htm|https://avro.apache.org/docs/1.8.1/spec.html]),
> nullable values should be specified as a unon with the type null, e.g. for
> string "['null', 'string']"
> However, given the following code (that from what I understand should be
> valid)
> {code:java}
> var type = avro.parse({
> name: 'Pet',
> type: 'record',
> fields: [
> { name: 'name', type: ['null', 'string'] }
> ]
> });
> var pet = { name: "Fido" };
> var buf = type.toBuffer(pet);
> var obj = type.fromBuffer(buf);
> console.log(obj);
> {code}
> I get the followin error on "type.toBuffer(pet)"
> {code:java}
> Error: invalid ["null","string"]: "Fido"
> {code}
>
> Curiously, if I instead set pet name as "null" instead of "Fido" everything
> runs fine and returns a correct output given the input. Though this is not
> very useful as the field still can not be changed to anything else beside
> null.
> {code:java}
> ...
> var pet = { name: null };
> ...
> console.log(obj);{code}
> {code:java}
> Pet { name: null }
> {code}
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (AVRO-2897) Unable to create nullable fields in Avro JavaScript implementation
Mattias Andersson created AVRO-2897:
---
Summary: Unable to create nullable fields in Avro JavaScript
implementation
Key: AVRO-2897
URL: https://issues.apache.org/jira/browse/AVRO-2897
Project: Apache Avro
Issue Type: Bug
Components: javascript
Affects Versions: 1.10.0
Reporter: Mattias Andersson
I apologize in advance if this is a misunderstanding of funcitonality on my
part and I have only tested it on the latest published npm package
([https://www.npmjs.com/package/avro-js]) but if not this should be a rather
serious bug.
According to multiple sources
([https://avro.apache.org/docs/1.8.1/spec.htm|https://avro.apache.org/docs/1.8.1/spec.html]),
nullable values should be specified as a unon with the type null, e.g. for
string "['null', 'string']"
However, given the following code (that from what I understand should be valid)
{code:java}
var type = avro.parse({
name: 'Pet',
type: 'record',
fields: [
{ name: 'name', type: ['null', 'string'] }
]
});
var pet = { name: "Fido" };
var buf = type.toBuffer(pet);
var obj = type.fromBuffer(buf);
console.log(obj);
{code}
I get the followin error
{code:java}
Error: invalid ["null","string"]: "Fido"
{code}
Curiously, if I instead set pet name as "null" instead of "Fido" everything
runs fine and returns a correct output given the input. Though this is not very
useful as the field still can not be changed to anything else beside null.
{code:java}
Pet { name: null }
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CAMEL-14656) Unmarshal using ref is not working when upgrading to camel 3.1
[
https://issues.apache.org/jira/browse/CAMEL-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mattias Andersson closed CAMEL-14656.
-
Resolution: Invalid
No bug. Using the right syntax worked perfectly.
> Unmarshal using ref is not working when upgrading to camel 3.1
> --
>
> Key: CAMEL-14656
> URL: https://issues.apache.org/jira/browse/CAMEL-14656
> Project: Camel
> Issue Type: Bug
> Components: camel-xstream
>Affects Versions: 3.1.0
> Environment: Camel 3.1.0
>Reporter: Mattias Andersson
>Priority: Critical
>
> Hi,
> In Camel we use route that looks like this:
>
> {code:java}
>
> <-- This does not work anymore
>
>
>
>
> {code}
>
>
> We registered the "xstream-default" in the camel context.
>
> {code:java}
> XStreamDataFormat xD = new XStreamDataFormat();
> xD.setPermissions("*");
> xD.setEncoding("UTF8");
> dataFormats.put("xstream-default", xD);
> {code}
> {code:java}
> camelContext.setDataFormats(dataFormats);
> {code}
> and loads the xml using:
>
> {code:java}
> try (InputStream is = EventRouteTree.toInputStream(doc)) {
> RoutesDefinition routes = (RoutesDefinition)
> camelContext.getXMLRoutesDefinitionLoader()
> .loadRoutesDefinition(camelContext, is);
>routes.getRoutes().forEach(r -> {
> camelContext.addRouteDefinition(r);
>});
> }
> {code}
>
>
> This worked fine i Camel 2.x but doesn't work in Camel 3.1 anymore. Tried to
> look at the upgrade 2.x to 3.0 guide but I found nothing specific regarding
> unmarshal.
> According to the xsd it look like there is no "ref" anymore for the unmarshal
> defintion .
> [https://camel.apache.org/schema/spring/camel-spring-3.1.0.xsd]
>
> I get the error when camel tries to start the route.
>
> {code:java}
> Caused by: java.lang.IllegalArgumentException: ref or type must be specified
> at org.apache.camel.util.ObjectHelper.notNull(ObjectHelper.java:152) at
> org.apache.camel.reifier.dataformat.DataFormatReifier.getDataFormat(DataFormatReifier.java:164)
> {code}
> Which looks strange because the ref is defined in xml tag unmarshal.
> So i guess since the xsd doesn't allow for a ref then the parser ignores the
> ref and it is empty when the code below is executed. Is this bug or are we
> suppose to define this in another way in the XML?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14656) Unmarshal using ref is not working when upgrading to camel 3.1
[
https://issues.apache.org/jira/browse/CAMEL-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051294#comment-17051294
]
Mattias Andersson commented on CAMEL-14656:
---
Thanks for your help. Worked perfectly. I'll close this issue.
> Unmarshal using ref is not working when upgrading to camel 3.1
> --
>
> Key: CAMEL-14656
> URL: https://issues.apache.org/jira/browse/CAMEL-14656
> Project: Camel
> Issue Type: Bug
> Components: camel-xstream
>Affects Versions: 3.1.0
> Environment: Camel 3.1.0
>Reporter: Mattias Andersson
>Priority: Critical
>
> Hi,
> In Camel we use route that looks like this:
>
> {code:java}
>
> <-- This does not work anymore
>
>
>
>
> {code}
>
>
> We registered the "xstream-default" in the camel context.
>
> {code:java}
> XStreamDataFormat xD = new XStreamDataFormat();
> xD.setPermissions("*");
> xD.setEncoding("UTF8");
> dataFormats.put("xstream-default", xD);
> {code}
> {code:java}
> camelContext.setDataFormats(dataFormats);
> {code}
> and loads the xml using:
>
> {code:java}
> try (InputStream is = EventRouteTree.toInputStream(doc)) {
> RoutesDefinition routes = (RoutesDefinition)
> camelContext.getXMLRoutesDefinitionLoader()
> .loadRoutesDefinition(camelContext, is);
>routes.getRoutes().forEach(r -> {
> camelContext.addRouteDefinition(r);
>});
> }
> {code}
>
>
> This worked fine i Camel 2.x but doesn't work in Camel 3.1 anymore. Tried to
> look at the upgrade 2.x to 3.0 guide but I found nothing specific regarding
> unmarshal.
> According to the xsd it look like there is no "ref" anymore for the unmarshal
> defintion .
> [https://camel.apache.org/schema/spring/camel-spring-3.1.0.xsd]
>
> I get the error when camel tries to start the route.
>
> {code:java}
> Caused by: java.lang.IllegalArgumentException: ref or type must be specified
> at org.apache.camel.util.ObjectHelper.notNull(ObjectHelper.java:152) at
> org.apache.camel.reifier.dataformat.DataFormatReifier.getDataFormat(DataFormatReifier.java:164)
> {code}
> Which looks strange because the ref is defined in xml tag unmarshal.
> So i guess since the xsd doesn't allow for a ref then the parser ignores the
> ref and it is empty when the code below is executed. Is this bug or are we
> suppose to define this in another way in the XML?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14656) Unmarshal using ref is not working when upgrading to camel 3.1
Mattias Andersson created CAMEL-14656:
-
Summary: Unmarshal using ref is not working when upgrading to
camel 3.1
Key: CAMEL-14656
URL: https://issues.apache.org/jira/browse/CAMEL-14656
Project: Camel
Issue Type: Bug
Components: camel-xstream
Affects Versions: 3.1.0
Environment: Camel 3.1.0
Reporter: Mattias Andersson
Hi,
In Camel we use route that looks like this:
{code:java}
<-- This does not work anymore
{code}
We registered the "xstream-default" in the camel context.
{code:java}
XStreamDataFormat xD = new XStreamDataFormat();
xD.setPermissions("*");
xD.setEncoding("UTF8");
dataFormats.put("xstream-default", xD);
{code}
{code:java}
camelContext.setDataFormats(dataFormats);
{code}
and loads the xml using:
{code:java}
try (InputStream is = EventRouteTree.toInputStream(doc)) {
RoutesDefinition routes = (RoutesDefinition)
camelContext.getXMLRoutesDefinitionLoader()
.loadRoutesDefinition(camelContext, is);
routes.getRoutes().forEach(r -> {
camelContext.addRouteDefinition(r);
});
}
{code}
This worked fine i Camel 2.x but doesn't work in Camel 3.1 anymore. Tried to
look at the upgrade 2.x to 3.0 guide but I found nothing specific regarding
unmarshal.
According to the xsd it look like there is no "ref" anymore for the unmarshal
defintion .
[https://camel.apache.org/schema/spring/camel-spring-3.1.0.xsd]
I get the error when camel tries to start the route.
{code:java}
Caused by: java.lang.IllegalArgumentException: ref or type must be specified at
org.apache.camel.util.ObjectHelper.notNull(ObjectHelper.java:152) at
org.apache.camel.reifier.dataformat.DataFormatReifier.getDataFormat(DataFormatReifier.java:164)
{code}
Which looks strange because the ref is defined in xml tag unmarshal.
So i guess since the xsd doesn't allow for a ref then the parser ignores the
ref and it is empty when the code below is executed. Is this bug or are we
suppose to define this in another way in the XML?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CXF-8200) Use name() instead of toString() for enums when generating WADL
Mattias Andersson created CXF-8200:
--
Summary: Use name() instead of toString() for enums when
generating WADL
Key: CXF-8200
URL: https://issues.apache.org/jira/browse/CXF-8200
Project: CXF
Issue Type: Bug
Components: JAX-RS, JAXB Databinding
Affects Versions: 3.1.13
Environment: CXF 3.1.13
Tomcat apache 8.5.34
Reporter: Mattias Andersson
When generating WADL the enum option value contains the toString() of the enum
(the human readable value for the option) but it should use the name() method
instead. Ex:
{code:java}
public enum Status {
INVOICED("Invoiced"),
NOT_INVOICED("Not invoiced");
String desc;
Status(String desc) {
this.desc = desc;
}
public String toString() {
return desc;
}
}
{code}
@GET
@Path("customers/\{customerNo}/creditnotes")
public Response findCreditNotesForCustomerNo(
@QueryParam("session") @XmlElement(required = true) String session,
@PathParam("customerNo") int customerNo,
@QueryParam("status") Status status);
The WADL contains:
**
**
**
I would expect it to be using the name() method. Like this:
**
**
**
Otherwise if someone looks at the WADL he would think that one should sent the
human readable string which is not correct.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SCM-871) Unable to release Maven artifacts which are not in the root of the Git repository
[
https://issues.apache.org/jira/browse/SCM-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385043#comment-16385043
]
Mattias Andersson commented on SCM-871:
---
I have a Git repo where the java part of the project is located in a sub-folder.
> Unable to release Maven artifacts which are not in the root of the Git
> repository
> -
>
> Key: SCM-871
> URL: https://issues.apache.org/jira/browse/SCM-871
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-jgit
>Affects Versions: 1.9.5
> Environment: Linux, Java version 1.8.0_144
>Reporter: Mattias Andersson
>Priority: Major
> Attachments: pom.xml
>
>
> I have a Maven project that is not in the root of the Git repository. When I
> run a release:prepare the pom.xml is changed but never checked in.
> {code:java}
> 07:52:47 [INFO] Checking in modified POMs...
> 07:52:47 [INFO] push changes to remote... refs/heads/master:refs/heads/master
> 07:52:47 [INFO] fetch url: ssh://myurl
> 07:52:47 [INFO] push url: ssh://myurl
> {code}
> In another project where the pom.xml is in the root of the repo i get
> following line printed after the “Checking in modified POMs…” line.
> {code:java}
> 09:28:24 [INFO] commit done: [maven-release-plugin] prepare release
> my-prod-1.0.0
> {code}
> For a maven project in the following directory:
> {{/home/me/git/my-repo/src/pom.xml}}
> The problem seems to be that in
> {{org.apache.maven.scm.provider.git.jgit.command.JGitUtils.addAllFiles(Git,
> ScmFileSet)}}. The baseUri of the fileSet is /home/me/git/my-repo/src so the
> relativized path become pom.xml. But
> {{org.eclipse.jgit.api.AddCommand.addFilepattern(String)}} expects a
> repository relative path, i.e. src/pom.xml.
>
> This patch [https://github.com/apache/maven-scm/compare/master...attiand:fix]
> relativize the path against the Git repo rather than the fileset, works for
> me.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SCM-871) Unable to release Maven artefacts that is not in the root of the Git repository
Mattias Andersson created SCM-871:
-
Summary: Unable to release Maven artefacts that is not in the root
of the Git repository
Key: SCM-871
URL: https://issues.apache.org/jira/browse/SCM-871
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-jgit
Affects Versions: 1.9.5
Environment: Linux, Java version 1.8.0_144
Reporter: Mattias Andersson
Attachments: pom.xml
I have a Maven project that is not in the root of the Git repository. When I
run a release:prepare the pom.xml is changed but never checked in.
{code:java}
07:52:47 [INFO] Checking in modified POMs...
07:52:47 [INFO] push changes to remote... refs/heads/master:refs/heads/master
07:52:47 [INFO] fetch url: ssh://myurl
07:52:47 [INFO] push url: ssh://myurl
{code}
In another project where the pom.xml is in the root of the repo i get following
line printed after the “Checking in modified POMs…” line.
{code:java}
09:28:24 [INFO] commit done: [maven-release-plugin] prepare release
my-prod-1.0.0
{code}
For a maven project in the following directory:
{{/home/me/git/my-repo/src/pom.xml}}
The problem seems to be that in
{{org.apache.maven.scm.provider.git.jgit.command.JGitUtils.addAllFiles(Git,
ScmFileSet)}}. The baseUri of the fileSet is /home/me/git/my-repo/src so the
relativized path become pom.xml. But
{{org.eclipse.jgit.api.AddCommand.addFilepattern(String)}} expects a repository
relative path, i.e. src/pom.xml.
This patch [https://github.com/apache/maven-scm/compare/master...attiand:fix]
relativize the path against the Git repo rather than the fileset, works for me.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-10887) pack200.exe is not work with camel 2.18.2
[ https://issues.apache.org/jira/browse/CAMEL-10887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15880840#comment-15880840 ] Mattias Andersson edited comment on CAMEL-10887 at 2/23/17 4:59 PM: I was just curios to why you but those classes in there, but now I know. So I guess its a big no no to use caffeine in your own camel component. Well anyway this is not a problem for us. Thanks for your fast response. was (Author: mattias1972): I was just curios to why you but those classes in there, but now I know. So I guess its a big no no to use caffeine in your own camel component then I guess. Well anyway this is not a problem for us. Thanks for your fast response. > pack200.exe is not work with camel 2.18.2 > - > > Key: CAMEL-10887 > URL: https://issues.apache.org/jira/browse/CAMEL-10887 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.18.2 >Reporter: Mattias Andersson >Priority: Minor > > we are packing camel-core-2.18.2 together using pack200.exe and get the > following error: > pack200.exe" -r camel-core-2.18.2.jar > Exception in thread "main" java.io.IOException: null ref > at com.sun.java.util.jar.pack.NativeUnpack.start(Native Method) > at com.sun.java.util.jar.pack.NativeUnpack.run(NativeUnpack.java:198) > at com.sun.java.util.jar.pack.NativeUnpack.run(NativeUnpack.java:247) > at > com.sun.java.util.jar.pack.UnpackerImpl.unpack(UnpackerImpl.java:138) > at com.sun.java.util.jar.pack.Driver.main(Driver.java:354) > The offending class in the jar-file seems to be: > org/apache/camel/com/github/benmanes/caffeine/cache/stats/StatsCounter > Should this class really be part of the jar-file (and other classes from > caffeine). We excluded the class when we pack and then it works!! > There is no problem using camel-core-2.17.x and pack200.exe -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CAMEL-10887) pack200.exe is not work with camel 2.18.2
[ https://issues.apache.org/jira/browse/CAMEL-10887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15880840#comment-15880840 ] Mattias Andersson commented on CAMEL-10887: --- I was just curios to why you but those classes in there, but now I know. So I guess its a big no no to use caffeine in your own camel component then I guess. Well anyway this is not a problem for us. Thanks for your fast response. > pack200.exe is not work with camel 2.18.2 > - > > Key: CAMEL-10887 > URL: https://issues.apache.org/jira/browse/CAMEL-10887 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.18.2 >Reporter: Mattias Andersson >Priority: Minor > > we are packing camel-core-2.18.2 together using pack200.exe and get the > following error: > pack200.exe" -r camel-core-2.18.2.jar > Exception in thread "main" java.io.IOException: null ref > at com.sun.java.util.jar.pack.NativeUnpack.start(Native Method) > at com.sun.java.util.jar.pack.NativeUnpack.run(NativeUnpack.java:198) > at com.sun.java.util.jar.pack.NativeUnpack.run(NativeUnpack.java:247) > at > com.sun.java.util.jar.pack.UnpackerImpl.unpack(UnpackerImpl.java:138) > at com.sun.java.util.jar.pack.Driver.main(Driver.java:354) > The offending class in the jar-file seems to be: > org/apache/camel/com/github/benmanes/caffeine/cache/stats/StatsCounter > Should this class really be part of the jar-file (and other classes from > caffeine). We excluded the class when we pack and then it works!! > There is no problem using camel-core-2.17.x and pack200.exe -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CAMEL-10887) pack200.exe is not work with camel 2.18.2
[ https://issues.apache.org/jira/browse/CAMEL-10887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15880582#comment-15880582 ] Mattias Andersson commented on CAMEL-10887: --- Just to explain further what I mean. camel-core-2.18.2.jar has several dependencies (sl4j, jaxb-core,jax-impl) but it's only classes from caffeine that is part of the camel-core-2.18.2 jar-file? Is it by design that these classes are included and not a dependency? > pack200.exe is not work with camel 2.18.2 > - > > Key: CAMEL-10887 > URL: https://issues.apache.org/jira/browse/CAMEL-10887 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.18.2 >Reporter: Mattias Andersson >Priority: Minor > > we are packing camel-core-2.18.2 together using pack200.exe and get the > following error: > pack200.exe" -r camel-core-2.18.2.jar > Exception in thread "main" java.io.IOException: null ref > at com.sun.java.util.jar.pack.NativeUnpack.start(Native Method) > at com.sun.java.util.jar.pack.NativeUnpack.run(NativeUnpack.java:198) > at com.sun.java.util.jar.pack.NativeUnpack.run(NativeUnpack.java:247) > at > com.sun.java.util.jar.pack.UnpackerImpl.unpack(UnpackerImpl.java:138) > at com.sun.java.util.jar.pack.Driver.main(Driver.java:354) > The offending class in the jar-file seems to be: > org/apache/camel/com/github/benmanes/caffeine/cache/stats/StatsCounter > Should this class really be part of the jar-file (and other classes from > caffeine). We excluded the class when we pack and then it works!! > There is no problem using camel-core-2.17.x and pack200.exe -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CAMEL-10887) pack200.exe is not work with camel 2.18.2
[ https://issues.apache.org/jira/browse/CAMEL-10887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15880519#comment-15880519 ] Mattias Andersson commented on CAMEL-10887: --- So you are not considering it an error that you cannot use pack200.exe on camel-core-2.18.2.jar? Br, /Mattias > pack200.exe is not work with camel 2.18.2 > - > > Key: CAMEL-10887 > URL: https://issues.apache.org/jira/browse/CAMEL-10887 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.18.2 >Reporter: Mattias Andersson >Priority: Minor > > we are packing camel-core-2.18.2 together using pack200.exe and get the > following error: > pack200.exe" -r camel-core-2.18.2.jar > Exception in thread "main" java.io.IOException: null ref > at com.sun.java.util.jar.pack.NativeUnpack.start(Native Method) > at com.sun.java.util.jar.pack.NativeUnpack.run(NativeUnpack.java:198) > at com.sun.java.util.jar.pack.NativeUnpack.run(NativeUnpack.java:247) > at > com.sun.java.util.jar.pack.UnpackerImpl.unpack(UnpackerImpl.java:138) > at com.sun.java.util.jar.pack.Driver.main(Driver.java:354) > The offending class in the jar-file seems to be: > org/apache/camel/com/github/benmanes/caffeine/cache/stats/StatsCounter > Should this class really be part of the jar-file (and other classes from > caffeine). We excluded the class when we pack and then it works!! > There is no problem using camel-core-2.17.x and pack200.exe -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CAMEL-10887) pack200.exe is not work with camel 2.18.2
Mattias Andersson created CAMEL-10887: - Summary: pack200.exe is not work with camel 2.18.2 Key: CAMEL-10887 URL: https://issues.apache.org/jira/browse/CAMEL-10887 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.18.2 Reporter: Mattias Andersson Priority: Minor we are packing camel-core-2.18.2 together using pack200.exe and get the following error: pack200.exe" -r camel-core-2.18.2.jar Exception in thread "main" java.io.IOException: null ref at com.sun.java.util.jar.pack.NativeUnpack.start(Native Method) at com.sun.java.util.jar.pack.NativeUnpack.run(NativeUnpack.java:198) at com.sun.java.util.jar.pack.NativeUnpack.run(NativeUnpack.java:247) at com.sun.java.util.jar.pack.UnpackerImpl.unpack(UnpackerImpl.java:138) at com.sun.java.util.jar.pack.Driver.main(Driver.java:354) The offending class in the jar-file seems to be: org/apache/camel/com/github/benmanes/caffeine/cache/stats/StatsCounter Should this class really be part of the jar-file (and other classes from caffeine). We excluded the class when we pack and then it works!! There is no problem using camel-core-2.17.x and pack200.exe -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] Commented: (CONTINUUM-827) notification emails missing svn information
[ http://jira.codehaus.org/browse/CONTINUUM-827?page=comments#action_73092 ] Mattias Andersson commented on CONTINUUM-827: - I see the same behaviour with CVS as SCM provider. Only a list of files changed and no developer or commit message (this worked fine in 1.0.2). See the exampel below. It's the same in the build result view (See attached picture). Online report : http://sorken-wm2:8080/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/11/buildId/999 Build statistics: State: Ok Previous State: Building Started at: fr, 2006-08-18 01:19:51 +0200 Finished at: fr, 2006-08-18 02:14:54 +0200 Total time: 55m 2s Build Trigger: Schedule Exit code: 0 Building machine hostname: sorken-wm2 Operating system : Windows 2003(Service Pack 1) Java version : 1.4.2_10(Sun Microsystems Inc.) Changes scripts/Database/factorydata/CAT_CUSTOMER_GROUP.dat scripts/Database/factorydata/SYS_SUBSYSTEM_ROLE_ACCESS.dat scripts/Database/factorydata/SYS_USER_GROUPS.dat ... notification emails missing svn information --- Key: CONTINUUM-827 URL: http://jira.codehaus.org/browse/CONTINUUM-827 Project: Continuum Issue Type: Bug Components: SCM Affects Versions: 1.0.3 Reporter: Brian Fox Fix For: 1.1 I'm using 1.0.3 and svn 1.3.2. 99% of the time, the notifications do not list the developer or the commit message. I just get a list of changed files. I have seen it in the past occasionally but almost always the info isn't there. This includes times when there was only 1 commit since the last build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-560) Extend blame mechanism to send email to the developer that caused the build to fail
Extend blame mechanism to send email to the developer that caused the build to fail --- Key: CONTINUUM-560 URL: http://jira.codehaus.org/browse/CONTINUUM-560 Project: Continuum Type: New Feature Components: Core system Versions: 1.0.2 Reporter: Mattias Andersson Priority: Minor Extend blame mechanism to send email to the developer that caused the build to fail -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
