[
https://issues.apache.org/jira/browse/CAMEL-18473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zineb Bendhiba updated CAMEL-18473:
-----------------------------------
Description:
When trying camel knative component with InMemory channels, we can't see the
bug because this one doesn't validate the event.
Outside of this use case when the event is validated on knative, it seems that
the time has wrong DateFormat.
For instance, if using the component with a broker, we can't produce an event
with camel-knative, and this is the log in knative environment :
{code:java}
{"level":"warn","ts":"2022-09-06T14:35:10.587Z","logger":"mt_broker_ingress","caller":"ingress/ingress_handler.go:137","msg":"failed
to extract event from request","error":"invalid value for time:
\"22022-08-31T12:00:33.253+02:00\""} {code}
This is the valid DateFormat, according to [CloudEvents
spec|[https://github.com/cloudevents/spec]]
{code:java}
"time" : "2018-04-05T17:31:00Z", {code}
This corresponds in the Java DateTimeFormatter class to
[ISO_INSTANT|#ISO_INSTANT].]
However, in camel-knative producer uses
[ISO_OFFSET_DATE_TIME|#ISO_OFFSET_DATE_TIME]],]
was:
When trying camel knative component with InMemory channels, we can't see the
bug because this one doesn't validate the event.
Outside of this use case when the event is validated on knative, it seems that
the time has wrong DateFormat.
For instance, if using the component with a broker, we can't produce an event
with camel-knative, and this is the log in knative environment :
{code:java}
{"level":"warn","ts":"2022-09-06T14:35:10.587Z","logger":"mt_broker_ingress","caller":"ingress/ingress_handler.go:137","msg":"failed
to extract event from request","error":"invalid value for time:
\"22022-08-31T12:00:33.253+02:00\""} {code}
This is the valid DateFormat, according to [CloudEvents
spec|[https://github.com/cloudevents/spec]:]
{code:java}
"time" : "2018-04-05T17:31:00Z", {code}
This corresponds in the Java DateTimeFormatter class to
[ISO_INSTANT|[https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html#ISO_INSTANT].]
However, in camel-knative producer uses
[ISO_OFFSET_DATE_TIME|[https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html#ISO_OFFSET_DATE_TIME]|https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html#ISO_OFFSET_DATE_TIME],]
> Knative component : CloudEvents have wrong time format
> ------------------------------------------------------
>
> Key: CAMEL-18473
> URL: https://issues.apache.org/jira/browse/CAMEL-18473
> Project: Camel
> Issue Type: Bug
> Components: camel-knative
> Affects Versions: 3.18.1
> Reporter: Zineb Bendhiba
> Assignee: Zineb Bendhiba
> Priority: Major
> Fix For: 3.18.3
>
>
>
> When trying camel knative component with InMemory channels, we can't see the
> bug because this one doesn't validate the event.
> Outside of this use case when the event is validated on knative, it seems
> that the time has wrong DateFormat.
> For instance, if using the component with a broker, we can't produce an event
> with camel-knative, and this is the log in knative environment :
>
> {code:java}
> {"level":"warn","ts":"2022-09-06T14:35:10.587Z","logger":"mt_broker_ingress","caller":"ingress/ingress_handler.go:137","msg":"failed
> to extract event from request","error":"invalid value for time:
> \"22022-08-31T12:00:33.253+02:00\""} {code}
> This is the valid DateFormat, according to [CloudEvents
> spec|[https://github.com/cloudevents/spec]]
>
> {code:java}
> "time" : "2018-04-05T17:31:00Z", {code}
> This corresponds in the Java DateTimeFormatter class to
> [ISO_INSTANT|#ISO_INSTANT].]
> However, in camel-knative producer uses
> [ISO_OFFSET_DATE_TIME|#ISO_OFFSET_DATE_TIME]],]
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
