Croway opened a new issue, #126:
URL: https://github.com/apache/camel-upgrade-recipes/issues/126
Follow-up to #125.
## Problem
The Java recipes are gated by `UsesType("org.apache.camel..*")`
(`RecipesUtil.newVisitor`) and the YAML recipes by
`RecipesUtil.camelYamlDslPrecondition()`. The XML recipes had no equivalent, so
they visit **every** XML document in a project, Camel or not.
This is not theoretical. In #125 `XmlDsl46Recipe` was found rewriting Spring
bean definitions: it matches `bean/property`, which is exactly the shape of
Spring XML, so a file like
```xml
<beans xmlns="http://www.springframework.org/schema/beans";>
<bean id="example" class="com.example.Example">
<property name="topic" value="someValue"/>
</bean>
</beans>
```
came out as `<bean><properties><property/></properties></bean>` — silently
invalid Spring configuration. Reproduced by running the Camel Spring Boot
migration over a multi-module project containing a Spring bean file.
#125 added `RecipesUtil.camelXmlDslPrecondition()` and applied it to
`RenameHeaderInXmlDsl` and `XmlDsl46Recipe`. **Ten recipe classes remain
ungated.**
## Remaining recipes
Higher exposure — element names that also occur in unrelated XML, matched at
any depth:
| Recipe | Matches |
|---|---|
| `camel418_3/RenameHeaderPrefixInXmlDsl` | `setHeader` / `header` /
`removeHeader` tag names, any document, any depth |
| `camel418_1/XmlDsl418_1SagaRecipe` | `//saga` |
Lower exposure — an accidental match is unlikely today because the matcher
is Camel-specific, anchored, or carries extra attribute/child guards. They are
unguarded by accident rather than by design, which is the real point:
| Recipe | Matches | Incidental guard |
|---|---|---|
| `camel41/XmlDslRecipe` | `*/bean` | also requires a `<script>` child plus
`type` and `beanType` attributes; Spring uses `class` |
| `camel40/xml/XmlDslRecipe` | `/routes/route`, `/routes/route/description`
| anchored at a `routes` root |
| `camel40/xml/CircuitBreakerXmlDslRecipe` | resilience4j configuration path
| Camel-specific |
| `camel410/XmlDsl410Recipe` | `//intercept/when`,
`//interceptSendToEndpoint/when` | Camel-specific |
| `camel47/XmlDsl47Recipe` | `//loadBalance/*` | Camel-specific |
| `customRecipes/ReplacePropertyInComponentXml` | `//route/from`,
`//route/to` | checks the `uri` starts with the component scheme |
| `customRecipes/internal/ChangeXmlComponentUriRecipe` | `//route/from`,
`//route/to` | matches the `uri` against a scheme pattern |
| `customRecipes/ReplacePropertyInDataFormatXml` | `//marshal/<component>` |
component name in the path |
The lesson from #125 is that this margin is fragile. `RenameHeaderInXmlDsl`
was safe for the same reason — it only touched a `name` attribute on a header
element — right up until it was widened to rewrite `${header.x}` in element
text and attribute values, at which point it started rewriting Spring property
placeholders. Any future widening of the recipes above has the same failure
mode.
## Suggested fix
Wrap each remaining visitor in
`Preconditions.check(RecipesUtil.camelXmlDslPrecondition(), ...)`, as done in
#125.
Detection there is: the Spring beans namespace rules a document out, a
`camel.apache.org` namespace rules it in, otherwise fall back to the root
element name (`routes`, `route`, `camelContext`, `rest`, `bean`, `beans`, …).
The namespace fallback matters because Camel XML DSL files are frequently
written with no namespace, and several existing tests in this repo use bare
`<route>`, `<bean>` and `<camelContext>` roots.
Each recipe should get a negative test with a non-Camel document, in the
spirit of `doesNotMigrateNonCamelXml` and
`xmlPropertiesNotMigratedInSpringBeans` added in #125.
Worth doing in one pass rather than per recipe, so the gate is uniform and
any test fixture that relies on a non-Camel root gets flushed out together.
---
_Claude Code on behalf of Federico Mariani_
--
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]
