[wildfly-dev] Patching WSDL4J (or perhaps forking?)

[Brian Stansberry]

You can also fork/join. :)

If a critical bug is blocking major downstream projects at some point 
there's no choice other than forking. But if they ever fix the problem 
you can always abandon the fork.

I'm curious: when we've forked, what's the proper approach to release 
naming? A different "G" in the maven GAV, or just a different "V"? I 
know for the productization rebuilds for EAP it's a different "V" but 
that's kind of a different thing than what you're talking about here.

On 9/5/13 11:00 AM, Alessio Soldano wrote:
> Hi Anil,
> all clear in theory of course ;-) but ... is the project really active
> (it's the JSR110 RI after all) ? the discussion mailing list archive
> shows 0 messages, nothing relevant on the wiki, a release (1.6.3) six
> months ago and no change after that (also note that 1.6.2 was released
> back in 2006).
> Perhaps I could try raising another bug on sourceforge (even if the
> patch proposal is already there) and see if anybody notices it. Failing
> that, I'll simply fork it on github and cut a -jbossorg release, but I
> wanted others' opinions too ;-)
>
> Cheers
> Alessio
>
> On 05/09/13 17:02, Anil Saldhana wrote:
>> Hi Alessio,
>>      it depends on how active the project is. If it is active, raising bug
>> reports
>> and following up usually gets the resolution. If is is not active,
>> forking is
>> the way to go unfortunately. Alternatively, you can become a contributor
>> to wsdl4j and apply the patch yourself. :)
>>
>> Regards,
>> Anil
>>
>> On 09/05/2013 09:42 AM, Alessio Soldano wrote:
>>> Folks,
>>> when running the jbossws testsuite against WFLY master with security
>>> manager enabled, I've noticed that the following permission is required
>>> to build up JAXWS clients (actually to be able to parse any WSDL):
>>>
>>>       <permission class="java.io.FilePermission"
>>> name="/usr/java/jdk1.7.0_17/jre/lib/wsdl.properties" actions="read"/>
>>>
>>> That's basically a non existing file in my java.home. The reason is in
>>> WSDL4J, which seems to be missing a SecurityException catch block in
>>> javax.wsdl.factory.WSDLFactory#findFactoryImplName().
>>> I thought about reporting the issue, but afaics the project "lives" at
>>> sourceforge.net (on cvs  scm...) and, more important, since Oct 2011
>>> there's already a patch proposal [1] for the issue which has never been
>>> commented / considered.
>>>
>>> How should we move forward here? Suggestions / proposals? Anybody here
>>> is in the JSR-110 EG and can get in touch with the WSDL4J devs?
>>>
>>> Alessio
>>>
>>> [1] http://sourceforge.net/p/wsdl4j/patches/1/
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat