Add support for glob pattern combined with methods/fields

[kiwiwings]

Hello Uwe,

(as you know ... :) in Apache POI we are still using XmlBeans with a lots of factory (inner) classes in the generated interfaces. I'd like to add something like the following expression to fail on calls which don't use our (more-or-less) safe XmlOptions:

org.openxmlformats.schemas.**.Factory#parse(java.io.InputStream)

Would that make sense or is there a different approach possible?
i.e. by checking parent calls in the factory method, but those are all with the same signature and null default values.

Andi.

[uschindler]

Hi,
we are using globs to allow exclusion of classes. I agree it would be fine to allow this for methods and fields, too!

But this is hard to implement in the current infrastructure for several reasons:

• You cannot detect invalid signatures, because the signatures may not exist (no class to check on). This is also true for classes, but there it is much more unlikely that you do an error here, that won't be detected. Having a typo in a method signature is much more likely!
• The second problem is resolving of methods: Currently it also expands to alias methods (e.g. overrides using different return type / parameter type because of generics). This only works if you have a class (has to do with covariant methods). This is hard to explain here :-) Basically the reason for the limitation is that the actual method is resolved at signature parsing time, so you need a class instance.

Would it not be possible to exclude via super class (like the AccessibleObject instead of Method/Field)? I know this won't work for static methods. I can take a look at source code!

[uschindler]

My suggestion about POI would be:

In Lucene we also auto-generate source code using jflex, javacc, or antlr. This process also creates broken methods using input streams (or public classes we don't want to have public). We have a post source code creation task that uses regular expressions to clean up the source code. Why not do the same for the generated xmlbeans code? Something like a replaceregex with a glob pattern on all files? By that the methods would not even be created and this may also reduce JAR file size.

Example from Lucene's expressions module where we "fix" the ANTLR generated files: https://github.com/apache/lucene-solr/blob/9bf85cde1bcd539db03ea2fd5a96524ba8f2f0f0/lucene/expressions/build.xml#L77-L130

(In fact I was thinking about that already when I was fixing the security problems with external entities last year).

[kiwiwings]

I've also thought about manipulating the schemas, but on a second thought forbidden-apis seemed to be less effort to reach my goal :)
I'll give it a try, to remove the generated methods ... although this might break user code, which works on the xmlbeans directly,
I think it's reasonable for the sake of security ...

[uschindler]

I'll give it a try, to remove the generated methods ... although this might break user code, which works on the xmlbeans directly,

How about "fixing" the methods to take "safe" default args (no entity expansion,...)?