RE: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE > -Original Message- > From: Simon Nash [mailto:n...@apache.org] > Sent: Sunday, February 20, 2011 4:06 PM > To: dev@tuscany.apache.org > Subject: Re: PolicyHandler exception handling issue - > PolicyHandler.afterInvoke() is not called when SOAPFault is generated > (UNCLASSIFIED) > > Simon Nash wrote: > > Gang Yang wrote: > >> --- Cut --- > >> > >> 4. PolicyHandler.afterInvoke is not called when Fault is generated. > So > >> far, I have no workaround on this and would like a fix. If I > remember > >> the code correctly, a quick fix is possible if > >> Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic() can catch > >> the exception, create the Fault body and call > >> PolicyHandler.afterInvoke() on the service side. I'm not sure how > the > >> client (requester) side works, but the PolicyHandler.afterInvoke() > is > >> also skipped on the return with the Fault. > >> > > I'll take a look at this code and post some comments on how I think > the > > problem could be addressed. > > > Hi Gang, > I've looked at this code and it doesn't seem like a simple fix. > > 1. On the service side, any business exceptions from the implementation > cause afterInvoke() to be skipped. Tuscany creates an AxisFault > wrapping the business exception, and throws this back to Axis2 > for it to generate the on-the-wire fault. > > 2. On the service side, any system exceptions from the implementation > (e.g., ServiceRuntimeException) or from beforeInvoke() cause > afterInvoke() to be skipped. Tuscany creates an AxisFault by > calling > AxisFault.makeFault() and throws this back to Axis2 for it to > generate the on-the-wire fault. > > 3. On the reference side, any AxisFault (either created by Axis2 or > created by Tuscany on the service side because of cases 1 or 2) > causes afterInvoke() to be skipped. > > I'm assuming that both cases 1 and 2 are a problem for what you need > to do. Your suggestion of moving responsibility for creating the > fault body from Axis2 to Tuscany seems like a big change with plenty > of opportunity for things to go wrong because Axis2 would then take > different code paths when Tuscany returns back to it. I don't know > Axis2 well enough to know whether it is considered correct for the > business method to create a fault body as the operation response and > return normally instead of throwing an AxisFault. This change could > affect other scenarios such as handling business exceptions, so > it would need very careful thought and thorough testing. > > For case 3, Tuscany could catch the AxisFault, call afterInvoke() > and then rethrow the AxisFault. I wouldn't be concerned about making > this change because it only affects a small amount of Tuscany code > and doesn't have any side effects on Axis2. > >Simon Hi, Simon, I have not been able to find any workaround for case 1 and 2. I can see in the debugger that the generation of response message from the AxisFault happens much later and I agree with you that it's not a simple fix. It looks to me that I have to live with it. It's not the end of world since we achieved the main goal by blocking the request in beforeInvoke. It's just the response that is not gracefully handled by security process. For case 3, will afterInvoke will be called with the response MessageContext that contains the response SOAP message? If so, I would like your proposed workaround/fix for case 3 to be included if possible. It'll give us a compatible Fault handling with other services (non-Tuscany). It'll also enable auditing when Fault occurs. Thanks, Gang Classification: UNCLASSIFIED Caveats: NONE
Re: Callback and Tuscany 2.0 Samples
Please do. It saves a lot of pain and time trying to make it work. (Well, it won't really work). Kind Regards Urso 2011/2/22 ant elder > We've not done anything about this yet so unless anyone says otherwise > i'm going to move the jaxws versions of the WS binding out to contrib. > > I still think it would be good to have the version that works with > just Java and no other dependencies but until we have that working > more completely or someone working on it then it seems better to not > be confusing users like this. > > ...ant > > -- Forwarded message -- > From: Urso Wieske > Date: Mon, Jan 17, 2011 at 7:20 PM > Subject: Re: Callback and Tuscany 2.0 Samples > To: u...@tuscany.apache.org, antel...@apache.org > > > Hi Ant, > Well, I suggest to remove JAXWS RI. Some SCA characteristics such as > Callback through binding.ws are not working properly. > I use the maven tuscany plugin in Eclipse to build my projects. (Ease > of use and development) > Kind Regards > Urso > > 2011/1/17 ant elder > > > > You should be able to use the Axis2 based WS binding with the Tuscany > > plugin instead of the JAXWS RI based one by adding the dependencies as > > follows: > > > > > > org.apache.tuscany.maven.plugins > > maven-tuscany-plugin > > 2.0-SNAPSHOT > > > > > > org.apache.tuscany.sca > > > tuscany-binding-ws-runtime-axis2 > > 2.0-SNAPSHOT > > > > > > org.mortbay.jetty > > jetty > > 6.1.19 > > > > > > > > > > We need to decide if we want to keep maintaining the JAXWS RI based WS > > binding or drop it and just use the Axis2 based one, its not getting > > updated much these days so is getting out of date, i guess thats a > > discussion for the dev list. > > > > It would be interesting to hear a bit more about how you use the > > Tuscany plugin, you say you use it in Eclipse, could you tell us a bit > > more about what you do? > > > > ...ant >
RE: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE Hi, Simon L., Forgot to ask. From what you described, it sounds promising in Tuscany 2.0 using interceptors approach. Based on your quick assessment, how complete is Tuscany 2.0 policy interceptor framework? Would it now support the four capabilities I raised and summarized earlier in this thread? If not, would 1 and 4 at least be supported and 2 and 3 be still working using the workaround? Below is the list I copied from earlier post. Of course in the interceptor approach, there wouldn't be before/afterInvoke(), but just invoke, which would invoke the next in the invocation chain and adding logic before and after the next.invoke(). 1. PolicyHandler.afterInvoke() needs to be called with the outbound MessageContext instead of the inbound MC. This is critical for WS-security. I have provided my fixes in the JIRA. With some generalization we discussed, I think this should be fixable in 1.6.x. 2. SOAP message encryption is not supported because the PolicyHandler.beforeInvoke() is called after Axis2 dispatching phase, which needs to analize SOAP body in order to determine the endpoint method. This can be worked around by defining SOAPaction in WSDL or Java interface using @WebMethod. However, a future fix is still nice to have. 3. A state-sharing mechanism is needed to allow sharing states among service side interceptors/handlers, component and reference side interceptors/handlers. I'm currently using the ThreadLocal as a workaround, which I wish to have your blessing - for now, it's only used from the service handler to component and then to reference handler and I hope you can confirm that the same thread is used for processing. However, we all agreed that this is not desirable to use ThreadLocal in the service framework and a state-sharing mechanism is needed. 4. PolicyHandler.afterInvoke is not called when Fault is generated. So far, I have no workaround on this and would like a fix. If I remember the code correctly, a quick fix is possible if Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic() can catch the exception, create the Fault body and call PolicyHandler.afterInvoke() on the service side. I'm not sure how the client (requester) side works, but the PolicyHandler.afterInvoke() is also skipped on the return with the Fault. Thanks, Gang > -Original Message- > From: Simon Laws [mailto:simonsl...@googlemail.com] > Sent: Tuesday, February 22, 2011 6:18 AM > To: dev@tuscany.apache.org > Subject: Re: PolicyHandler exception handling issue - > PolicyHandler.afterInvoke() is not called when SOAPFault is generated > (UNCLASSIFIED) > > On Tue, Feb 22, 2011 at 9:03 AM, Simon Nash wrote: > > Gang Yang wrote: > >> > >> --- Cut --- > >>> > >>> How about plugging your code into an Axis2 handler instead of a > Tuscany > >>> handler? Is there is a way to get control after Axis2 has built > the > >>> SOAPFault and before the fault is sent on the wire? > >>> > >>> Simon > >>> > >> > >> Our security software has been integrated with Axis2 and other WS > >> frameworks such as JAX-WS and JAX-RPC. The problem here is that we > are > >> supposed to integrate with Tuscany. Axis2 is just a ws binding > provider and > >> it's hidden behind Tuscany:-). In an earlier quick effort, I have > modified > >> tuscany-sca-all-1.6.jar to add Axis2 handlers in a hard-coded way. > But > >> that's not a good solution and it's not flexiable. > >> > >> > > Why do the Axis2 handlers need to be part of the Tuscany jar? Is > this > > a classloader issue? Perhaps there is a way to customize Tuscany's > use > > of classloaders to allow Axis2 handlers to be loaded from outside the > > Tuscany jar. For example, it's possible to set up Tuscany 1.x to run > with > > a different version of Axis2 from that included with the tuscany-sca- > all > > jar, as described in [1] (please read the whole thread). > > > > Simon > > > > [1] http://www.mail-archive.com/user@tuscany.apache.org/msg02597.html > > > > > > Trying to catch up > > I think there is a question here of how generic the security code is. > > If it's common code that is intended to encrypt messages regardless of > what binding is used then it needs to be independent of the binding. > It it does depend on the type of binding then things are different. > For WS Security support in 1.x we chose to use the Rampart module of > Axis so our security policies in that area just provide configuration > to the Rampart module. Hence we allow the guts of Axis to do whatever > it needs to do and just provide the appropriate configuration. > > This case of providing a bespoke policy that has to run in the context > of a binding is, as we are finding here, tricky because in 1.x we > started out with an infrastructure model that treated the binding as a > black box. The policy handlers beforeInvoke/afterInvoke were a first > attempt to resolve it but we added then in a very binding specific > way. I.e. where
RE: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Classification: UNCLASSIFIED
Caveats: NONE
Hi, Simon L.,
My comments follow.
Thanks,
Gang
--- cut ---
>
> Trying to catch up
>
> I think there is a question here of how generic the security code is.
>
> If it's common code that is intended to encrypt messages regardless of
> what binding is used then it needs to be independent of the binding.
> It it does depend on the type of binding then things are different.
> For WS Security support in 1.x we chose to use the Rampart module of
> Axis so our security policies in that area just provide configuration
> to the Rampart module. Hence we allow the guts of Axis to do whatever
> it needs to do and just provide the appropriate configuration.
>
> This case of providing a bespoke policy that has to run in the context
> of a binding is, as we are finding here, tricky because in 1.x we
> started out with an infrastructure model that treated the binding as a
> black box. The policy handlers beforeInvoke/afterInvoke were a first
> attempt to resolve it but we added then in a very binding specific
> way. I.e. where they appear and get called is binding dependent.
Yes, you are right. The "black box" treatment is the root cause of the
problems in 1.6.x ws binding implementation. For security, it needs to
access some intermediate states in that black box and insert logic in
the middle. The four issues I raised and summarized in this thread are
all related to this needs.
>
> We backed away from this approach for the JMS and HTTP bindings in 1.x
> and created the binding chain [1]. We went this route to support
> features, such as wireFormat and operationSelection, that the OASIS
> specifications introduced. What it does is introduce the familiar
> handler infrastructure into the guts of the binding implementation so
> opening up the black box and making it more pluggable. So, for
> example, on the reference side you might find that a binding does the
> following
>
> Set up the binding context -> some arbitrary handlers (policy,
> wireFormat etc) -> transport processing
>
> And on the service side the reverse is true.
>
> transport processing -> some arbitrary handlers (policy, wireFormat
> etc) -> Operation selection
I like the above visual pictures. I remember seeing the list of phases
in the interceptor framework code that would have supported this
pictures. I guess it's just not yet completely implemented.
>
> In 2.x the JMS and HTTP binding came over from 1.x pretty much as is
> and we started converting the ws-axis binding to this pattern. The new
> PolicyProvider interface has extra methods [2] which still support
> policy interceptors being created for the normal operation chain but
> adds the ability to create interceptors for the binding chain and also
> allows the provider the opportunity to configure a binding directly if
> required.
>
> Another thing we started looking at in 2.x was alternative
> implementations of binding.ws. In particular we started looking at
> what it would take to build the binding on top of JAXWS. We have a
> simple JDK/RI based version running but didn't get the Axis/JAXWS
> version running. We redirected our effort to getting the existing
> binding-ws-axis2 binding to being compliant with the OASIS specs. If
> someone were to finish off the JAXWS support then in theory you could
> add JAXWS interceptors directly the ws binding
>
> None of this information is directly helping solve Yang's immediate
> problem but I want to make sure issues raised on this thread are
> resolved in 2.x. I suspect that some of these issues are still
> relevant.
>
> Re. the question of calling afterInvoke() in fault cases. Would there
> be problem with letting the infrastructure continue to do the fault
> processing but give afterInvoke() a chance to process any faults
> created, for example, in Axis2ServiceInOutSyncMessageReceiver ..
>
>
> } catch (InvocationTargetException e) {
> Throwable t = e.getCause();
> if (t instanceof FaultException &&
> ((FaultException)t).getFaultInfo() instanceof OMElement) {
> OMElement faultDetail =
> (OMElement)((FaultException)t).getFaultInfo();
> inMC.setProperty(Constants.FAULT_NAME,
> faultDetail.getQName().getLocalPart());
> AxisFault f = new AxisFault(null, e.getMessage(),
> "faultNode", "faultRole", faultDetail);
> ***throw f;
> }
> if (t instanceof Exception) {
> ***throw AxisFault.makeFault((Exception)t);
> }
> logger.log(Level.SEVERE, e.getMessage(), t);
> ***throw new ServiceRuntimeException(e);
> } catch (Throwable e) {
> logger.log(Level.SEVERE, e.getMessage(), e);
> ***throw AxisFault.makeFault(e);
> }
>
> give afterInvoke the chance to process here ***. A similar thing could
> be done in the invoke() operation of Axis2BindingInvoker. What
> processing are you expecting to do on
RE: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE > Why do the Axis2 handlers need to be part of the Tuscany jar? Is this > a classloader issue? Perhaps there is a way to customize Tuscany's use > of classloaders to allow Axis2 handlers to be loaded from outside the > Tuscany jar. For example, it's possible to set up Tuscany 1.x to run > with > a different version of Axis2 from that included with the tuscany-sca- > all > jar, as described in [1] (please read the whole thread). > >Simon > > [1] http://www.mail-archive.com/user@tuscany.apache.org/msg02597.html Hi, Simon, The issue is not the classloader. The reason I had to modify the Tuscany-sca-all-1.6.jar was that I needed to modify the axis2.xml configuration file to add our Axis2 module declaration. Our Axis2 module package and handler code were packaged separately. Even with this approach, it's still not flexible enough because the module declaration I added in axis2.xml could only be a global one that applies to all services deployed in Axis2/Tuscany. We needed to the flexibility to declare different modules for difference services and references, which needs to be done in the service/reference creation stage, but Tuscany hid the service/reference creation from us, which is the right thing to do, so I could not do so. I like the Tuscany policy interceptor/handler approach much better. It just needs some refinement and enhancement to fully support the security. Thanks, Gang Classification: UNCLASSIFIED Caveats: NONE
Fwd: Callback and Tuscany 2.0 Samples
We've not done anything about this yet so unless anyone says otherwise i'm going to move the jaxws versions of the WS binding out to contrib. I still think it would be good to have the version that works with just Java and no other dependencies but until we have that working more completely or someone working on it then it seems better to not be confusing users like this. ...ant -- Forwarded message -- From: Urso Wieske Date: Mon, Jan 17, 2011 at 7:20 PM Subject: Re: Callback and Tuscany 2.0 Samples To: u...@tuscany.apache.org, antel...@apache.org Hi Ant, Well, I suggest to remove JAXWS RI. Some SCA characteristics such as Callback through binding.ws are not working properly. I use the maven tuscany plugin in Eclipse to build my projects. (Ease of use and development) Kind Regards Urso 2011/1/17 ant elder > > You should be able to use the Axis2 based WS binding with the Tuscany > plugin instead of the JAXWS RI based one by adding the dependencies as > follows: > > > org.apache.tuscany.maven.plugins > maven-tuscany-plugin > 2.0-SNAPSHOT > > > org.apache.tuscany.sca > tuscany-binding-ws-runtime-axis2 > 2.0-SNAPSHOT > > > org.mortbay.jetty > jetty > 6.1.19 > > > > > We need to decide if we want to keep maintaining the JAXWS RI based WS > binding or drop it and just use the Axis2 based one, its not getting > updated much these days so is getting out of date, i guess thats a > discussion for the dev list. > > It would be interesting to hear a bit more about how you use the > Tuscany plugin, you say you use it in Eclipse, could you tell us a bit > more about what you do? > > ...ant
Re: [VOTE] Release Tuscany SCA 2.0 Beta2 RC3
On 14/02/2011 09:11, ant elder wrote: On Sun, Feb 13, 2011 at 7:43 AM, Florian Moga wrote: Please review and vote on RC3 of the Java SCA 2.0 Beta2 release. The artifacts are at: http://people.apache.org/~fmoga/tuscany/2.0-beta2-RC3/ The release tag is at: https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-Beta2-RC3/ Florian This looks good to me so +1. A couple of issues: - I couldn't find your signing key in a public key server, have you uploaded it anywhere? - there are some testing artifacts in the staging repo we don't really need and which could be deleted - the ones from distribution\tomcat\testing, you could just delete them from the staging repo now. We should move those to be under testing/itest really. Otherwise all looks fine. ...ant Folks, My belated +1 - I only got around to trying it out over the weekend. Thanks for the improvements in the basic samples. At least now there is a set of simple instructions that work for the novice to get the "hello world" type applications running. Yours, Mike.
Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
On Tue, Feb 22, 2011 at 9:03 AM, Simon Nash wrote:
> Gang Yang wrote:
>>
>> --- Cut ---
>>>
>>> How about plugging your code into an Axis2 handler instead of a Tuscany
>>> handler? Is there is a way to get control after Axis2 has built the
>>> SOAPFault and before the fault is sent on the wire?
>>>
>>> Simon
>>>
>>
>> Our security software has been integrated with Axis2 and other WS
>> frameworks such as JAX-WS and JAX-RPC. The problem here is that we are
>> supposed to integrate with Tuscany. Axis2 is just a ws binding provider and
>> it's hidden behind Tuscany:-). In an earlier quick effort, I have modified
>> tuscany-sca-all-1.6.jar to add Axis2 handlers in a hard-coded way. But
>> that's not a good solution and it's not flexiable.
>>
>>
> Why do the Axis2 handlers need to be part of the Tuscany jar? Is this
> a classloader issue? Perhaps there is a way to customize Tuscany's use
> of classloaders to allow Axis2 handlers to be loaded from outside the
> Tuscany jar. For example, it's possible to set up Tuscany 1.x to run with
> a different version of Axis2 from that included with the tuscany-sca-all
> jar, as described in [1] (please read the whole thread).
>
> Simon
>
> [1] http://www.mail-archive.com/user@tuscany.apache.org/msg02597.html
>
>
Trying to catch up
I think there is a question here of how generic the security code is.
If it's common code that is intended to encrypt messages regardless of
what binding is used then it needs to be independent of the binding.
It it does depend on the type of binding then things are different.
For WS Security support in 1.x we chose to use the Rampart module of
Axis so our security policies in that area just provide configuration
to the Rampart module. Hence we allow the guts of Axis to do whatever
it needs to do and just provide the appropriate configuration.
This case of providing a bespoke policy that has to run in the context
of a binding is, as we are finding here, tricky because in 1.x we
started out with an infrastructure model that treated the binding as a
black box. The policy handlers beforeInvoke/afterInvoke were a first
attempt to resolve it but we added then in a very binding specific
way. I.e. where they appear and get called is binding dependent.
We backed away from this approach for the JMS and HTTP bindings in 1.x
and created the binding chain [1]. We went this route to support
features, such as wireFormat and operationSelection, that the OASIS
specifications introduced. What it does is introduce the familiar
handler infrastructure into the guts of the binding implementation so
opening up the black box and making it more pluggable. So, for
example, on the reference side you might find that a binding does the
following
Set up the binding context -> some arbitrary handlers (policy,
wireFormat etc) -> transport processing
And on the service side the reverse is true.
transport processing -> some arbitrary handlers (policy, wireFormat
etc) -> Operation selection
In 2.x the JMS and HTTP binding came over from 1.x pretty much as is
and we started converting the ws-axis binding to this pattern. The new
PolicyProvider interface has extra methods [2] which still support
policy interceptors being created for the normal operation chain but
adds the ability to create interceptors for the binding chain and also
allows the provider the opportunity to configure a binding directly if
required.
Another thing we started looking at in 2.x was alternative
implementations of binding.ws. In particular we started looking at
what it would take to build the binding on top of JAXWS. We have a
simple JDK/RI based version running but didn't get the Axis/JAXWS
version running. We redirected our effort to getting the existing
binding-ws-axis2 binding to being compliant with the OASIS specs. If
someone were to finish off the JAXWS support then in theory you could
add JAXWS interceptors directly the ws binding
None of this information is directly helping solve Yang's immediate
problem but I want to make sure issues raised on this thread are
resolved in 2.x. I suspect that some of these issues are still
relevant.
Re. the question of calling afterInvoke() in fault cases. Would there
be problem with letting the infrastructure continue to do the fault
processing but give afterInvoke() a chance to process any faults
created, for example, in Axis2ServiceInOutSyncMessageReceiver ..
} catch (InvocationTargetException e) {
Throwable t = e.getCause();
if (t instanceof FaultException &&
((FaultException)t).getFaultInfo() instanceof OMElement) {
OMElement faultDetail =
(OMElement)((FaultException)t).getFaultInfo();
inMC.setProperty(Constants.FAULT_NAME,
faultDetail.getQName().getLocalPart());
AxisFault f = new AxisFault(null, e.getMessage(),
"faultNode", "faultRole", faultDetail);
***throw f;
}
if (t instanceof Exception) {
***throw
Re: [VOTE] Release Tuscany SCA 2.0 Beta2 RC3
Done. Waiting for the mirrors to sync up. On Tue, Feb 22, 2011 at 10:50 AM, ant elder wrote: > On Tue, Feb 22, 2011 at 8:48 AM, ant elder wrote: > > >> Also, I've noticed that the naming has been changed from the latest > release > >> > (apache-tuscany-sca-all-2.0-Beta1.zip to > apache-tuscany-distribution-all-2.0-Beta2.zip). > >> Is that fine? > > > > I think its ok, to change it we'd have to completely respin and revote > > which doesn't seem worth it. > > Actually, is that true? Maybe you can just rename them when copied to > the distribution area. If the signatures still verify correctly then > that could be fine. > > ...ant >
Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Gang Yang wrote: --- Cut --- How about plugging your code into an Axis2 handler instead of a Tuscany handler? Is there is a way to get control after Axis2 has built the SOAPFault and before the fault is sent on the wire? Simon Our security software has been integrated with Axis2 and other WS frameworks such as JAX-WS and JAX-RPC. The problem here is that we are supposed to integrate with Tuscany. Axis2 is just a ws binding provider and it's hidden behind Tuscany:-). In an earlier quick effort, I have modified tuscany-sca-all-1.6.jar to add Axis2 handlers in a hard-coded way. But that's not a good solution and it's not flexiable. Why do the Axis2 handlers need to be part of the Tuscany jar? Is this a classloader issue? Perhaps there is a way to customize Tuscany's use of classloaders to allow Axis2 handlers to be loaded from outside the Tuscany jar. For example, it's possible to set up Tuscany 1.x to run with a different version of Axis2 from that included with the tuscany-sca-all jar, as described in [1] (please read the whole thread). Simon [1] http://www.mail-archive.com/user@tuscany.apache.org/msg02597.html
Re: [VOTE] Release Tuscany SCA 2.0 Beta2 RC3
On Tue, Feb 22, 2011 at 8:48 AM, ant elder wrote: >> Also, I've noticed that the naming has been changed from the latest release >> (apache-tuscany-sca-all-2.0-Beta1.zip to apache-tuscany-distribution-all-2.0-Beta2.zip). >> Is that fine? > > I think its ok, to change it we'd have to completely respin and revote > which doesn't seem worth it. Actually, is that true? Maybe you can just rename them when copied to the distribution area. If the signatures still verify correctly then that could be fine. ...ant
Re: [VOTE] Release Tuscany SCA 2.0 Beta2 RC3
On Tue, Feb 22, 2011 at 8:37 AM, Florian Moga wrote: > I've followed the instructions found on the wiki page and created this page > [1]. It's been almost one day and the distribution packages are not being > available through the mirrors. It isn't specified in the release guide but > shouldn't I copy the distribution artifacts, CHANGES and RELEASE_NOTES files > to http://www.apache.org/dist//tuscany/java/sca/2.0-Beta2/? Yes they need to be manually copied there. > Also, I've noticed that the naming has been changed from the latest release > (apache-tuscany-sca-all-2.0-Beta1.zip to apache-tuscany-distribution-all-2.0-Beta2.zip). > Is that fine? I think its ok, to change it we'd have to completely respin and revote which doesn't seem worth it. I guess it must be due to the way all the artifacts get deployed in one go now, but we can tweak the artifact names in the pom.xml to change this for next time. ...ant
Re: [VOTE] Release Tuscany SCA 2.0 Beta2 RC3
I've followed the instructions found on the wiki page and created this page [1]. It's been almost one day and the distribution packages are not being available through the mirrors. It isn't specified in the release guide but shouldn't I copy the distribution artifacts, CHANGES and RELEASE_NOTES files to http://www.apache.org/dist//tuscany/java/sca/2.0-Beta2/? Also, I've noticed that the naming has been changed from the latest release (apache-tuscany-sca-all-2.0-Beta1.zip to apache-tuscany-distribution-all-2.0-Beta2.zip). Is that fine? [1] https://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+2.0-Beta2 On Sun, Feb 20, 2011 at 1:52 PM, Florian Moga wrote: > Thanks Ant, I've just added my key to the file. It doesn't appear on the > website yet. Can we perform a sync or is it done automatically? > > Considering the amount of work to be done in trunk/ I'm also calling +1 for > doing this release. > > The vote passes with +1 from: > Ant Elder > Simon Laws > Luciano Resende > Florian Moga > and no -1 votes. > > Thank you everyone for voting. > > I'll continue with the next steps I found here > https://cwiki.apache.org/confluence/display/TUSCANYxDOCx2x/Making+Releases > > > On Sun, Feb 20, 2011 at 10:41 AM, ant elder wrote: > >> On Fri, Feb 18, 2011 at 11:22 AM, Florian Moga >> wrote: >> > On Fri, Feb 18, 2011 at 12:17 PM, Simon Laws > > >> > wrote: >> >> >> >> The only thing I noticed was that RELEASE_NOTES have the wrong date at >> >> the top. This is not a blocker IMO. >> > >> > I could modify it right there if that's allowed. >> > >> >> No we can't modify that now. The contents of the SVN tag should match >> whats in the distributions so if its modified in SVN then we'd need to >> respin the distributions and have a new vote. >> >> >> >> >> I didn't spend much time on the samples for obvious reasons but the >> >> simple ones run. I get a clean build of the source with a clean repo >> >> on Linux. >> >> >> >> MD5 is OK but my remaining question is about getting the KEYS file >> >> (http://www.apache.org/dist/tuscany/KEYS) updated with your public >> >> key. Ant made comments about keys so maybe this is already in train. >> > >> > How can I edit the file? My public key is also available here [1]. >> > [1] https://svn.apache.org/repos/asf/tuscany/KEYS >> > >> >> Log on to people.apache.org and then you can find that KEYS file at >> /x1/www/www.apache.org/content/dist/tuscany >> >> ...ant >> > >
