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

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Alessio Soldano
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/

--
Alessio Soldano
Web Service Lead, JBoss

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Stuart Douglas
We could alwayy fork it and do our own release. That is what we have done to get around some JSF problems. 

Stuart


On Thu, Sep 5, 2013 at 4:42 PM, Alessio Soldano <[hidden email]> 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/

--
Alessio Soldano
Web Service Lead, JBoss

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Anil Saldhana
In reply to this post by Alessio Soldano
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Alessio Soldano
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
Alessio Soldano
Web Service Lead, JBoss

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Alessio Soldano
Hi Brian,

On 05/09/13 18:34, Brian Stansberry wrote:
> 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.
Sure.

Btw, I've tried creating a new bug at
https://sourceforge.net/p/wsdl4j/bugs/ after having logged with my
sourceforge account, but looks like I don't have enough permissions...

> 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 would go with a different V (suffixed with jbossorg).

Alessio

--
Alessio Soldano
Web Service Lead, JBoss

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Brian Stansberry
On 9/6/13 8:32 AM, Alessio Soldano wrote:

> Hi Brian,
>
> On 05/09/13 18:34, Brian Stansberry wrote:
>> 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.
> Sure.
>
> Btw, I've tried creating a new bug at
> https://sourceforge.net/p/wsdl4j/bugs/ after having logged with my
> sourceforge account, but looks like I don't have enough permissions...
>
>> 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 would go with a different V (suffixed with jbossorg).
>

Sounds fine.

I realize now I was muddled in my thinking when I asked this question.
Your fork is different from most -redhat productization rebuilds because
you are changing source, not just rebuilding. But, whether a fork
changes the G, the A or the V the original version string (1.1.1.GA or
whatever) is going to remain as part of the V, even though the code has
changed. So there's no real advantage in changing the G instead of
adding a suffix to the V.


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Max Rydahl Andersen-2
Reason to change G - make it so you can use both libraries in your dependency tree.
Reason to keep G - make it so you can't use both libraries in your dependency tree.

(there are more but that one is the key reason enterprise builds just uses V changes,
so you don't mix original project with the supported one by accident.)

/max

On Fri, Sep 06, 2013 at 09:08:21AM -0500, Brian Stansberry wrote:

>On 9/6/13 8:32 AM, Alessio Soldano wrote:
>> Hi Brian,
>>
>> On 05/09/13 18:34, Brian Stansberry wrote:
>>> 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.
>> Sure.
>>
>> Btw, I've tried creating a new bug at
>> https://sourceforge.net/p/wsdl4j/bugs/ after having logged with my
>> sourceforge account, but looks like I don't have enough permissions...
>>
>>> 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 would go with a different V (suffixed with jbossorg).
>>
>
>Sounds fine.
>
>I realize now I was muddled in my thinking when I asked this question.
>Your fork is different from most -redhat productization rebuilds because
>you are changing source, not just rebuilding. But, whether a fork
>changes the G, the A or the V the original version string (1.1.1.GA or
>whatever) is going to remain as part of the V, even though the code has
>changed. So there's no real advantage in changing the G instead of
>adding a suffix to the V.
>
>
>--
>Brian Stansberry
>Principal Software Engineer
>JBoss by Red Hat
>_______________________________________________
>wildfly-dev mailing list
>[hidden email]
>https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev