[
https://issues.apache.org/jira/browse/CAMEL-8236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275241#comment-14275241
]
Claus Ibsen commented on CAMEL-8236:
------------------------------------
This code has been working fine for about 7 years.
This is not for all classloading but only for annotation package scanning,
which in Camel 1.x was how it discovered type converters. This has changed a
long time ago, and is no longer needed.
Only when using camel-bindy it does some package scanning annotations, only
because we havent refactored and migrated camel-bindy to avoid this. There is a
jira about that.
There is no need to add a system property and whatnot. You can remove this code
and have Camel work in websphere, its only when you use camel-bindy it would
may fail. But newer versions of WebSphere may work without this. So if anyone
got access to a set of IBM WebSphere App Servers they are welcome to test the
situation today.
Also WebSpherePackageScanClassResolver is no harm as it just adds an extra
fallback that has no harm for non websphere environments
> WebSphere class loader detection is too sensitive
> -------------------------------------------------
>
> Key: CAMEL-8236
> URL: https://issues.apache.org/jira/browse/CAMEL-8236
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.14.1
> Reporter: Rafael Winterhalter
> Assignee: Willem Jiang
> Priority: Minor
> Fix For: 2.13.4, 2.14.2, 2.15.0
>
>
> The DefaultCamelContext attempts to detect an IBM WebSphere application
> server by a simple test: loader.getClass().getName().startsWith("com.ibm")
> This test can introduce very subtle bugs when working with other IBM
> productes and I suggest to replace it by a list of known class names of
> WebSphere class loaders. At least, one should add an additional dot in order
> to avoid matching packages that only start with "com.ibm" such as any
> "com.ibmfoobar".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
