gnodet-bot commented on code in PR #29349:
URL: https://github.com/apache/camel/pull/29349#discussion_r4494761128
##########
dsl/camel-jbang/camel-jbang-plugin-tui/src/main/java/org/apache/camel/dsl/jbang/core/commands/tui/ErrorsTab.java:
##########
@@ -550,6 +550,7 @@ private void renderDetail(Frame frame, Rect area, ErrorInfo
ei) {
ei.exchangeId, ei.routeId, ei.nodeId, null, ei.location,
ei.elapsed, ei.threadName, !ei.handled);
addRepeatLine(lines, ei);
+ ChaosMarks.addDetailLine(lines, ctx, ctx.findSelectedIntegration(),
ei.exchangeId, ei.properties);
Review Comment:
ðĄ **Minor inconsistency:** `renderDetail` resolves the integration via
`ctx.findSelectedIntegration()` instead of threading the `IntegrationInfo info`
parameter already available in `renderContent`.
`ActivityTab.detailLines` was updated in this PR to accept `(ActivityEntry
ae, IntegrationInfo info)` and passes `info` directly to
`ChaosMarks.addDetailLine`. `ErrorsTab.renderDetail` doesn't receive `info`
(it's a private method with only `ErrorInfo ei`), so it falls back to a ctx
lookup.
This is consistent with the current signature of `renderDetail` â just worth
noting the asymmetry if you ever refactor to thread `info` through
`renderDetail` as well.
##########
dsl/camel-jbang/camel-jbang-plugin-tui/src/main/java/org/apache/camel/dsl/jbang/core/commands/tui/ChaosMarks.java:
##########
@@ -0,0 +1,113 @@
+/*
+ * 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.camel.dsl.jbang.core.commands.tui;
+
+import java.util.HashMap;
+import java.util.LinkedHashMap;
+import java.util.List;
+import java.util.Map;
+
+import dev.tamboui.style.Style;
+import dev.tamboui.text.Line;
+import dev.tamboui.text.Span;
+import dev.tamboui.widgets.table.Cell;
+
+/**
+ * The exchanges a chaos rule faulted, so the Activity and Errors tabs mark
them ({@code ðēr1}): a failure made on
+ * purpose is then not debugged as a real one. An error has the exchange
property {@code CamelChaosRule} that
+ * camel-chaos sets (CAMEL-26678). An activity entry has no properties, so the
exchange ids of the recent faults of the
+ * chaos report are kept as the status comes in, every second, the last ones
per integration.
+ */
+final class ChaosMarks {
+
+ /** The exchange property camel-chaos sets on an exchange a rule faulted,
with the id of the rule. */
+ static final String PROPERTY = "CamelChaosRule";
+
+ // the faulted exchanges kept per integration: enough for the last minutes
of activity
+ static final int MAX = 2000;
+
+ private final Map<String, Map<String, String>> byPid = new HashMap<>();
Review Comment:
ðĄ **Theoretical (non-practical) note:** `byPid` is a plain `HashMap` with no
size bound. The inner `LinkedHashMap` per PID is correctly bounded at
`MAX=2000`, but the outer map grows with each distinct PID. In a typical JBang
session the number of integrations is small and PIDs are stable, so this is not
a real issue â just documenting for completeness.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
