date:20081009



On Oct 8, 2008, at 5:16 PM, Sergey Beryozkin wrote:


Hi

I agree with what Dan suggested - logging a message in a
PolicyVerificationOutInterceptor should suffice in most cases. Few  
more

comments.

I think that asserting a policy on the outbound path makes sense  
only if
a specification for a given policy expression explicitly states that  
it

applies to both inbound and outbound paths or to outbound path only.


Suppose you have this config:




  




Does  apply to the inbound our outbound path?  Or both?  What  
are the semantics here?



on the
server inbound path, a union of all policy expressions is selected  
as at any
moment of time we may need to satisfy requests from clients meeting  
either

all or one of the available alternatives.
All required interceptors are
installed - but the api allows for on-demand interceptors  
installation (for

ex, based in the in message's content & headers).


Correct.  Or more appropriately, based on the actual content of the  
policy.



AFAIK,
PolicyVerificationInInterceptor would say OK as long as at least one  
of the
alternatives is fully satisfied. In your example we have a compact  
policy
expression, so there'no problems if either  or   
has

been asserted.

On the outbound path only the alternative which has been selected  
during the
inbound path should be optionally verified. I don't think any  
alternative
selection algorithm should apply on the outbound path as we already  
have an

alternative active in the scope of a given operation.


That assumes the effective policy is the same on the inbound and  
outbound sides.  I think that's an invalid assumption (as I think you  
are saying, as well).  Or at least I think we should be able to  
discriminate between inbound and outbound policies.  I stand corrected  
in the case of WSDL, but I think we need a way to make the same  
distinction in spring (and however else we retrieve policy).


How about this, for a proposal:





  


 
  


 
  





So on the inbound side you'd get [{foo}Bar, {gnu:Gnat}]

And on the outbound side you'd get [{foo:Bar}, {gnu}Gnat]


If we have the Ex2
(above) then this alternative will simply have no any inbound  
behaviors to
engage (see more below). In Ex1 - it's up to that specific policy's  
out

interceptors to do any additional outbound work.

Thus, in many cases, like in Ex1, if no explicit out policy  
interceptors
have been provided then PolicyVerificationOutInterceptor should  
simply log a
(FINE?) level message as suggested. In fact it's not clear what else  
it can

do other than do this logging on the server side.


I think this gets us over a hump, but I also think it's kind of a cop- 
out.  Why log anything?  Why even do the check?  What's the purpose,  
if there's no tangible side-effect?  Choke up a log with more garbage?





While (on the server side) PolicyVerificationInInterceptor is useful  
in that
it ensures that at least one alternative has been met, its out  
counterpart

is of little use. Unless we provide some hints.


Yup.  If it's of no use, remove it.




We can introduce additional optional hints (in the form of policy
attributes) to both in/out verifiers that this policy only applies  
to the in
or out path or to both paths. Thus, in case of Ex2, In verifier  
won't fail
but Out verifier can log a WARNING (or throw a fault if its phase  
can be

changed). Likewise, in Ex3, In verifier may throw exception while OUT
verifier will keep quiet. In case of Ex1, both in/out verifiers may  
report

failures (through exceptions or logging).


Not sure what you mean here.  Attributes on the wsp:Policy elements,  
themselves?  I'd think there'd be a better way to do that, than to add  
proprietary stuff to standard policy expressions.  At any rate, if  
that's what you mean, then I think we should try to avoid it, since it  
won't be in any way interoperable.





Without such helper attributes the default (server) behavior should  
likely

be :
- PolicyVerificationInInterceptor throws fault if none of the  
alternatives

has been met (as it is now)
- PolicyVerificationOutInterceptor logs a FINE message if not all of  
the
expressions in the alternative selected during the inbound  
invocation has

been met.


Why?  What possible use is this to the user?  The more I think of it,  
the more I realize the PolicyVerificationOutInterceptor on the  
outbound server side is kind of pointless, especially in light of the  
current bug in its behavior.


I'll reiterate that the API on setting a PolicyAlternativeSelector is  
too coarse -- it's on the PolicyEngine, which is basically in 1-1  
correspondence with the Bus.  I can think of 4 different ways you'd  
want to configure one of these guys (client/server in/out), and you'd  
want to be able to configure that on a per-endpoint basis (at least).


-Fred

Re: Initial bits for a DOSGi distribution (CXF-1854)

2008-10-09 Thread Eoghan Glynn



Thanks David, patch applied.

David Bosschaert wrote:

Hi all,

I've attached a patch to https://issues.apache.org/jira/browse/CXF-1854 
which contains the beginning of a distribution of the DOSGi stuff. The 
distribution contains all the required dependencies (OSGi bundles) is 
built as part of the maven build in distribution/multi-bundle/target


Would appreciate if someone could apply.

Thanks!

David


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: More on server response policies


Doh!  That was supposed to be [{foo:Bar}, {bling}Blang]

On Oct 9, 2008, at 9:44 AM, Fred Dushin wrote:


And on the outbound side you'd get [{foo:Bar}, {gnu}Gnat]

NoClassDefFoundError when building the example in CXF 2.0.9 SNAPSHOT



Hi Dan,

I got a java.lang.NoClassDefFoundError: 
org/apache/xml/serializer/TreeWalker when I try to build the sample in 
the latest CXF 2.0.9 SNAPSHOT.
It looks like current CXF 2.0.9-SNAPSHOT shipped xalan-2.7.1.jar don't 
have the org.apache.xml.serializer package.

Can you help me to verify it?

Thanks,

Willem

Re: Release manager for 2.1.3 and/or 2.0.9.....

Does the java.lang.NoClassDefFoundError: 
org/apache/xml/serializer/TreeWalker  relates to change of updating to 
using xalan 2.7.1 ?



Daniel Kulp wrote:

Willem,

Thanks for volunteering to do this.   That's great.

I think it would be good to do 2.0.9 late this week and probably 2.1.3 
middle of next week.   (need to do 2.0.x first due to an "issue" with 
the maven stage plugin which will update the "latest" tag in the 
metadata with 2.0.9 so 2.0.9 would get picked up instead of 2.1.2.  
Thus, we would want 2.1.3 shortly thereafter to restore a 2.1.x version 
as latest).


I have a couple of fixes I'm going to try and get in to 2.1.x this week.   
We also should update to bouncycastle 140 and xalan 2.7.1 for both 2.1.3 
and 2.0.9.   With those versions, we can actually distribute 
bouncycastle and thus ws-security can work "out of the box" and not 
require downloading additional jars.


Dan



On Thursday 02 October 2008, Willem Jiang wrote:
  

Hi Dan,

I'd like to take charge of this CXF release.
Since you and me met a year before, I will send you my key for signing
:)

Cheers,

Willem

On Fri, Oct 3, 2008 at 12:49 AM, Daniel Kulp <[EMAIL PROTECTED]> wrote:


We're rappidly approaching time to do the 2.0.9 and 2.1.3 releases.
It's been about 10 week since 2.0.9 and 7 weeks since 2.1.2.   We
have 33 issues resolved for 2.0.9, and 38 for 2.1.3.   Thus, we
probably should consider doing some releases shortly.

HOWEVER, my hard drive crashed this week and part of recovering from
that, I kind of realized that someone else really should try doing a
release to make sure the knowledge is spread out a bit and isn't all
bottled up in my head.Thus, I'd like to ask for volunteers for
doing the releases.   If no one jumps up, I'll be happy to do it,
but it would definitely be good to get someone else involved.

Requirements:
1) The release process is MUCH easier and more reliable on a Linux
or OSX box.   Things like gpg and ssh/scp "just work".  If someone
want to try Windows, I'm not sure how much I can help.

2) gpg installed and a gpg key generated and available in the public
key servers.   Ideally, it would be signed by other apache folks,
but that's not a requirment.  Anyone near Boston, we could meet for
lunch and sign keys if you want.

3) Time - before building the release, you need a few hours to
review release notes, notice/license files, rat reports, etc  
Post release, there is syncing to the maven repo, updating

confluence, some JIRA admin things, etc   Basically, a few hours
ahead of the build, an hour to build, three days for the vote, and a
few hours afterword.

Anyway, if anyone is interested, speak up.  I'd be happy to look
over your virtual shoulder while you do the stuff to make sure it's
all done right.   Not a problem.

Thanks!

--
J. Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog

Re: Release manager for 2.1.3 and/or 2.0.9.....




On Thursday 09 October 2008 10:13:08 am Willem Jiang wrote:
> Does the java.lang.NoClassDefFoundError:
> org/apache/xml/serializer/TreeWalker  relates to change of updating to
> using xalan 2.7.1 ?

Yea.  Where are you seeing that?

There is a new jar (serializer.jar) in lib that contains that class.   
Basically they split the 2.7.0 jar into two jars, pulling the serializer 
stuff out.

Dan



>
> Daniel Kulp wrote:
> > Willem,
> >
> > Thanks for volunteering to do this.   That's great.
> >
> > I think it would be good to do 2.0.9 late this week and probably 2.1.3
> > middle of next week.   (need to do 2.0.x first due to an "issue" with
> > the maven stage plugin which will update the "latest" tag in the
> > metadata with 2.0.9 so 2.0.9 would get picked up instead of 2.1.2.
> > Thus, we would want 2.1.3 shortly thereafter to restore a 2.1.x version
> > as latest).
> >
> > I have a couple of fixes I'm going to try and get in to 2.1.x this week.
> > We also should update to bouncycastle 140 and xalan 2.7.1 for both 2.1.3
> > and 2.0.9.   With those versions, we can actually distribute
> > bouncycastle and thus ws-security can work "out of the box" and not
> > require downloading additional jars.
> >
> > Dan
> >
> > On Thursday 02 October 2008, Willem Jiang wrote:
> >> Hi Dan,
> >>
> >> I'd like to take charge of this CXF release.
> >> Since you and me met a year before, I will send you my key for signing
> >>
> >> :)
> >>
> >> Cheers,
> >>
> >> Willem
> >>
> >> On Fri, Oct 3, 2008 at 12:49 AM, Daniel Kulp <[EMAIL PROTECTED]> wrote:
> >>> We're rappidly approaching time to do the 2.0.9 and 2.1.3 releases.
> >>> It's been about 10 week since 2.0.9 and 7 weeks since 2.1.2.   We
> >>> have 33 issues resolved for 2.0.9, and 38 for 2.1.3.   Thus, we
> >>> probably should consider doing some releases shortly.
> >>>
> >>> HOWEVER, my hard drive crashed this week and part of recovering from
> >>> that, I kind of realized that someone else really should try doing a
> >>> release to make sure the knowledge is spread out a bit and isn't all
> >>> bottled up in my head.Thus, I'd like to ask for volunteers for
> >>> doing the releases.   If no one jumps up, I'll be happy to do it,
> >>> but it would definitely be good to get someone else involved.
> >>>
> >>> Requirements:
> >>> 1) The release process is MUCH easier and more reliable on a Linux
> >>> or OSX box.   Things like gpg and ssh/scp "just work".  If someone
> >>> want to try Windows, I'm not sure how much I can help.
> >>>
> >>> 2) gpg installed and a gpg key generated and available in the public
> >>> key servers.   Ideally, it would be signed by other apache folks,
> >>> but that's not a requirment.  Anyone near Boston, we could meet for
> >>> lunch and sign keys if you want.
> >>>
> >>> 3) Time - before building the release, you need a few hours to
> >>> review release notes, notice/license files, rat reports, etc
> >>> Post release, there is syncing to the maven repo, updating
> >>> confluence, some JIRA admin things, etc   Basically, a few hours
> >>> ahead of the build, an hour to build, three days for the vote, and a
> >>> few hours afterword.
> >>>
> >>> Anyway, if anyone is interested, speak up.  I'd be happy to look
> >>> over your virtual shoulder while you do the stuff to make sure it's
> >>> all done right.   Not a problem.
> >>>
> >>> Thanks!
> >>>
> >>> --
> >>> J. Daniel Kulp
> >>> [EMAIL PROTECTED]
> >>> http://www.dankulp.com/blog



-- 
Daniel Kulp
[EMAIL PROTECTED]
http://dankulp.com/blog

Re: Release manager for 2.1.3 and/or 2.0.9.....

I can't find the serializer.jar in 2.0.9 SNAPSHOT, but I found it in 
2.1.3 SNAPSHOT.
After went through the commit log , I found there is one different between 


rt/ws/security/pom.xml in 2.0.x and 2.1.x ,

the xalan's dependency scope is runtime in 2.0.x, and uses the default compile 
scope in 2.1.x.

 
xalan
xalan
-2.7.0
+2.7.1
*runtime*

-  
-xml-apis
-xml-apis
-  
+
+xml-apis
+xml-apis
+



Daniel Kulp wrote:


On Thursday 09 October 2008 10:13:08 am Willem Jiang wrote:
  

Does the java.lang.NoClassDefFoundError:
org/apache/xml/serializer/TreeWalker  relates to change of updating to
using xalan 2.7.1 ?



Yea.  Where are you seeing that?

There is a new jar (serializer.jar) in lib that contains that class.   
Basically they split the 2.7.0 jar into two jars, pulling the serializer 
stuff out.


Dan



  

Daniel Kulp wrote:


Willem,

Thanks for volunteering to do this.   That's great.

I think it would be good to do 2.0.9 late this week and probably 2.1.3
middle of next week.   (need to do 2.0.x first due to an "issue" with
the maven stage plugin which will update the "latest" tag in the
metadata with 2.0.9 so 2.0.9 would get picked up instead of 2.1.2.
Thus, we would want 2.1.3 shortly thereafter to restore a 2.1.x version
as latest).

I have a couple of fixes I'm going to try and get in to 2.1.x this week.
We also should update to bouncycastle 140 and xalan 2.7.1 for both 2.1.3
and 2.0.9.   With those versions, we can actually distribute
bouncycastle and thus ws-security can work "out of the box" and not
require downloading additional jars.

Dan

On Thursday 02 October 2008, Willem Jiang wrote:
  

Hi Dan,

I'd like to take charge of this CXF release.
Since you and me met a year before, I will send you my key for signing

:)

Cheers,

Willem

On Fri, Oct 3, 2008 at 12:49 AM, Daniel Kulp <[EMAIL PROTECTED]> wrote:


We're rappidly approaching time to do the 2.0.9 and 2.1.3 releases.
It's been about 10 week since 2.0.9 and 7 weeks since 2.1.2.   We
have 33 issues resolved for 2.0.9, and 38 for 2.1.3.   Thus, we
probably should consider doing some releases shortly.

HOWEVER, my hard drive crashed this week and part of recovering from
that, I kind of realized that someone else really should try doing a
release to make sure the knowledge is spread out a bit and isn't all
bottled up in my head.Thus, I'd like to ask for volunteers for
doing the releases.   If no one jumps up, I'll be happy to do it,
but it would definitely be good to get someone else involved.

Requirements:
1) The release process is MUCH easier and more reliable on a Linux
or OSX box.   Things like gpg and ssh/scp "just work".  If someone
want to try Windows, I'm not sure how much I can help.

2) gpg installed and a gpg key generated and available in the public
key servers.   Ideally, it would be signed by other apache folks,
but that's not a requirment.  Anyone near Boston, we could meet for
lunch and sign keys if you want.

3) Time - before building the release, you need a few hours to
review release notes, notice/license files, rat reports, etc
Post release, there is syncing to the maven repo, updating
confluence, some JIRA admin things, etc   Basically, a few hours
ahead of the build, an hour to build, three days for the vote, and a
few hours afterword.

Anyway, if anyone is interested, speak up.  I'd be happy to look
over your virtual shoulder while you do the stuff to make sure it's
all done right.   Not a problem.

Thanks!

--
J. Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog

Re: More on server response policies

2008-10-09 Thread Sergey Beryozkin

Suppose you have this config:

Does apply to the inbound our outbound path? Or both? What are the
semantics here?

This coarse-graned policy applies to an endpoint so as I said it's up to the implementation as to whether it will affect
in/out/both pathes. As far as the policy verification is concerned, the default behaviour is to fail on the inbound path if a single
alternative includinfg a single policy expression has not been asserted and (to be fixed) log a message on the outbound
path.

All required interceptors are
installed - but the api allows for on-demand interceptors installation (for
ex, based in the in message's content & headers).

Correct. Or more appropriately, based on the actual content of the policy.

Not necessarily. Consider an optional MTOM policy assertion. There's no strict
need to install an MTOM interceptor
in advance, untill a given message arrives. You can 2 messages coming in, one
is non-MTOM, another one is.

AFAIK,
PolicyVerificationInInterceptor would say OK as long as at least one of the
alternatives is fully satisfied. In your example we have a compact policy
expression, so there'no problems if either or has
been asserted.

On the outbound path only the alternative which has been selected during the
inbound path should be optionally verified. I don't think any alternative
selection algorithm should apply on the outbound path as we already have an
alternative active in the scope of a given operation.

That assumes the effective policy is the same on the inbound and outbound sides. I think that's an invalid assumption (as I
think you are saying, as well). Or at least I think we should be able to discriminate between inbound and outbound policies. I
stand corrected in the case of WSDL, but I think we need a way to make the same distinction in spring (and however else we
retrieve policy).

I actually think that the single effective policy should apply to the given operation, in/out. But this policy can contain
expressions which are valid for the outbound only or inbound only or both. I don't think WS-Policy provides for effective polices
for in or out only, It's a single effective policy instance for the scope of a given operation. Though the AssertionInfoMap should
be in/out-specific.

How about this, for a proposal:

I'd just prefer

IMHO this is more compact and easier on the eye. Furthermore, when such policies will be dynamicallyt attached to WSDL instance, it
would provide more hints to client runtimes/tools. Such attribute can also be applied when polices are explicitly attached to WSDL.
For ex, as I said earlier, there's no explicit indication to verifiers on the scope of this policy when it's attached to some
container element like wsdl:port

we have a PolicyAssertion abstraction and we can add a helper method like getScope(), by default it applies to say 'in' only or
in/out with possisble overrides.

To be honest though, I wouldn't be too concerned now about ensuring that outbond policy verifier fails (or reports a warning). I
reckon the default behaviour (of just logging some FINE message) would do in case say ends up in the list of
policies. Only when it's absolutely critical that an outbound message does not leave the server runtime if some policies have not
been applied to the outbound message (SLA agreement with non policy aware client runtimes for ex) then I'd consider adding such
hints.

I think this gets us over a hump, but I also think it's kind of a cop- out. Why log anything? Why even do the check? What's the
purpose, if there's no tangible side-effect? Choke up a log with more garbage?

So we can have a default scope be "in-only", but when we want to block the
response we can override it.

While (on the server side) PolicyVerificationInInterceptor is useful in that
it ensures that at least one alternative has been met, its out counterpart
is of little use. Unless we provide some hints.

Yup. If it's of no use, remove it.

Mostly agreed but see above - we might need it at some time. And it's probably
can behave differently on the client side.

Not sure what you mean here. Attributes on the wsp:Policy elements, themselves? I'd think there'd be a better way to do that,
than to add proprietary stuff to standard policy expressions. At any rate, if that's what you mean, then I think we should try
to avoid it, since it won't be in any way interoperable.

any client runtime should be able to ignore unrecognized attributes. Any policy
expression
should have an extension point for any additional attributes. I honestly think
it's an issue at all.
If we ever have to deal with 3rd party policies with closed schemas then we can
also use your proposed
extension.
We can also suggest to the ws-policy group to consider standardizing on such attribute (as it can be of real help to client
runtimes)

Re: svn commit: r702961 - in /cxf/branches/2.0.x-fixes: ./ distribution/bundle/all/pom.xml distribution/bundle/minimal/pom.xml integration/jca/src/main/java/org/apache/cxf/jca/outbound/ManagedConnecti

2008-10-09 Thread William Tam

Hi Dan,


-@SuppressWarnings("unchecked")
public ManagedConnection matchManagedConnections(Set mcs, Subject subject,
ConnectionRequestInfo reqInfo) throws ResourceException {

Without the @SuppressWarnings, my Eclipse IDE flags me a warning loud
and clear.  (I do mvn -Psetup.eclipse to setup my projects)  Could you
offer some guidelines when @SuppressWarnings would be necessary.

Thanks,
William



On Wed, Oct 8, 2008 at 2:43 PM,  <[EMAIL PROTECTED]> wrote:
> Author: dkulp
> Date: Wed Oct  8 11:43:00 2008
> New Revision: 702961
>
> URL: http://svn.apache.org/viewvc?rev=702961&view=rev
> Log:
> Merged revisions 702959 via svnmerge from
> https://svn.apache.org/repos/asf/cxf/branches/2.1.x-fixes
>
> 
>  r702959 | dkulp | 2008-10-08 14:38:22 -0400 (Wed, 08 Oct 2008) | 11 lines
>
>  Merged revisions 702957 via svnmerge from
>  https://svn.apache.org/repos/asf/cxf/trunk
>
>  
>r702957 | dkulp | 2008-10-08 14:33:50 -0400 (Wed, 08 Oct 2008) | 4 lines
>
>Mark resource.spi stuff optional in the osgi manifest
>Remove an unneeded SuppressWarnings
>Make the prepareOrb call public to make it callable by interceptors if 
> needed
>  
> 
>
> Modified:
>cxf/branches/2.0.x-fixes/   (props changed)
>cxf/branches/2.0.x-fixes/distribution/bundle/all/pom.xml
>cxf/branches/2.0.x-fixes/distribution/bundle/minimal/pom.xml
>
> cxf/branches/2.0.x-fixes/integration/jca/src/main/java/org/apache/cxf/jca/outbound/ManagedConnectionFactoryImpl.java
>
> Propchange: cxf/branches/2.0.x-fixes/
> --
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Wed Oct  8 11:43:00 2008
> @@ -1,3 +1,3 @@
> -/cxf/branches/2.1.x-fixes:673548,674485,674547,674551,674562,674601,674649,674764,674887,675644,675653,677048,677385,678004,678009,678559,678629,678808,678852,678891,678893,679248,679597,680435,681060,681165,681813,681816,682902,682951,683089,683290,683318,684099,684790-684793,684842,684862,684895-684918,685205,685253,686237,686283,686299,686333-686364,686765,686827,687097,687464-687465,689109,689112,689122,691316,691357,691491,691711,691715,691745,692162-692163,692468,692500,694466-694469,694472,694717,694748-694749,694870,695503,695509,695553,69,695563,695875-695877,695940,695980,696436,696455,696721,697086,698129,701526,701634,702275,702443,702527,702582,702604,702610,702642-702643,702649,702760,702870,702873
> -/cxf/trunk:651669-686342,686344-686363,686764,686820,687096,687387,687463,688086,688102,688735,691271,691355,691488,691602,691706,691728,692116,692157,692466,692499,693653,693819,694179,694263,694417,694716,694744,694747,694869,695396,695484,695537,695552,695561,695619,695684,695835,695935,695977,696094,696433,696720,697085,698128,700261,700602,701783,701830,701862,702267,702580,702602,702609,702616,702656
> +/cxf/branches/2.1.x-fixes:673548,674485,674547,674551,674562,674601,674649,674764,674887,675644,675653,677048,677385,678004,678009,678559,678629,678808,678852,678891,678893,679248,679597,680435,681060,681165,681813,681816,682902,682951,683089,683290,683318,684099,684790-684793,684842,684862,684895-684918,685205,685253,686237,686283,686299,686333-686364,686765,686827,687097,687464-687465,689109,689112,689122,691316,691357,691491,691711,691715,691745,692162-692163,692468,692500,694466-694469,694472,694717,694748-694749,694870,695503,695509,695553,69,695563,695875-695877,695940,695980,696436,696455,696721,697086,698129,701526,701634,702275,702443,702527,702582,702604,702610,702642-702643,702649,702760,702870,702873,702959
> +/cxf/trunk:651669-686342,686344-686363,686764,686820,687096,687387,687463,688086,688102,688735,691271,691355,691488,691602,691706,691728,692116,692157,692466,692499,693653,693819,694179,694263,694417,694716,694744,694747,694869,695396,695484,695537,695552,695561,695619,695684,695835,695935,695977,696094,696433,696720,697085,698128,700261,700602,701783,701830,701862,702267,702580,702602,702609,702616,702656,702957
>  /incubator/cxf/trunk:434594-651668
>
> Propchange: cxf/branches/2.0.x-fixes/
> --
> Binary property 'svnmerge-integrated' - no diff available.
>
> Modified: cxf/branches/2.0.x-fixes/distribution/bundle/all/pom.xml
> URL: 
> http://svn.apache.org/viewvc/cxf/branches/2.0.x-fixes/distribution/bundle/all/pom.xml?rev=702961&r1=702960&r2=702961&view=diff
> ==
> --- cxf/branches/2.0.x-fixes/distribution/bundle/all/pom.xml (original)
> +++ cxf/branches/2.0.x-fixes/distribution/bundle/all/pom.xml Wed Oct  8 
> 11:43:00 2008
> @@ -229,6 +229,7 @@
> com.sun*;resolution:=optional,
> javax.jms*;resolution:=optional,
> repackage;resolution:=optional,
> +javax.resource.spi*;resoluti

Re: svn commit: r702961 - in /cxf/branches/2.0.x-fixes: ./ distribution/bundle/all/pom.xml distribution/bundle/minimal/pom.xml integration/jca/src/main/java/org/apache/cxf/jca/outbound/ManagedConnecti


Interesting.   I removed it because my eclipse IDE gave me a warning saying it 
was unneeded.Strange.   Not sure what that would occur.   Hmm

Dan


On Thursday 09 October 2008 11:24:32 am William Tam wrote:
> Hi Dan,
>
>
> -@SuppressWarnings("unchecked")
> public ManagedConnection matchManagedConnections(Set mcs, Subject
> subject, ConnectionRequestInfo reqInfo) throws ResourceException {
>
> Without the @SuppressWarnings, my Eclipse IDE flags me a warning loud
> and clear.  (I do mvn -Psetup.eclipse to setup my projects)  Could you
> offer some guidelines when @SuppressWarnings would be necessary.
>
> Thanks,
> William
>
> On Wed, Oct 8, 2008 at 2:43 PM,  <[EMAIL PROTECTED]> wrote:
> > Author: dkulp
> > Date: Wed Oct  8 11:43:00 2008
> > New Revision: 702961
> >
> > URL: http://svn.apache.org/viewvc?rev=702961&view=rev
> > Log:
> > Merged revisions 702959 via svnmerge from
> > https://svn.apache.org/repos/asf/cxf/branches/2.1.x-fixes
> >
> > 
> >  r702959 | dkulp | 2008-10-08 14:38:22 -0400 (Wed, 08 Oct 2008) | 11
> > lines
> >
> >  Merged revisions 702957 via svnmerge from
> >  https://svn.apache.org/repos/asf/cxf/trunk
> >
> >  
> >r702957 | dkulp | 2008-10-08 14:33:50 -0400 (Wed, 08 Oct 2008) | 4
> > lines
> >
> >Mark resource.spi stuff optional in the osgi manifest
> >Remove an unneeded SuppressWarnings
> >Make the prepareOrb call public to make it callable by interceptors if
> > needed 
> > 
> >
> > Modified:
> >cxf/branches/2.0.x-fixes/   (props changed)
> >cxf/branches/2.0.x-fixes/distribution/bundle/all/pom.xml
> >cxf/branches/2.0.x-fixes/distribution/bundle/minimal/pom.xml
> >   
> > cxf/branches/2.0.x-fixes/integration/jca/src/main/java/org/apache/cxf/jca
> >/outbound/ManagedConnectionFactoryImpl.java
> >
> > Propchange: cxf/branches/2.0.x-fixes/
> > -
> >- --- svn:mergeinfo (original)
> > +++ svn:mergeinfo Wed Oct  8 11:43:00 2008
> > @@ -1,3 +1,3 @@
> > -/cxf/branches/2.1.x-fixes:673548,674485,674547,674551,674562,674601,6746
> >49,674764,674887,675644,675653,677048,677385,678004,678009,678559,678629,6
> >78808,678852,678891,678893,679248,679597,680435,681060,681165,681813,68181
> >6,682902,682951,683089,683290,683318,684099,684790-684793,684842,684862,68
> >4895-684918,685205,685253,686237,686283,686299,686333-686364,686765,686827
> >,687097,687464-687465,689109,689112,689122,691316,691357,691491,691711,691
> >715,691745,692162-692163,692468,692500,694466-694469,694472,694717,694748-
> >694749,694870,695503,695509,695553,69,695563,695875-695877,695940,6959
> >80,696436,696455,696721,697086,698129,701526,701634,702275,702443,702527,7
> >02582,702604,702610,702642-702643,702649,702760,702870,702873
> > -/cxf/trunk:651669-686342,686344-686363,686764,686820,687096,687387,68746
> >3,688086,688102,688735,691271,691355,691488,691602,691706,691728,692116,69
> >2157,692466,692499,693653,693819,694179,694263,694417,694716,694744,694747
> >,694869,695396,695484,695537,695552,695561,695619,695684,695835,695935,695
> >977,696094,696433,696720,697085,698128,700261,700602,701783,701830,701862,
> >702267,702580,702602,702609,702616,702656
> > +/cxf/branches/2.1.x-fixes:673548,674485,674547,674551,674562,674601,6746
> >49,674764,674887,675644,675653,677048,677385,678004,678009,678559,678629,6
> >78808,678852,678891,678893,679248,679597,680435,681060,681165,681813,68181
> >6,682902,682951,683089,683290,683318,684099,684790-684793,684842,684862,68
> >4895-684918,685205,685253,686237,686283,686299,686333-686364,686765,686827
> >,687097,687464-687465,689109,689112,689122,691316,691357,691491,691711,691
> >715,691745,692162-692163,692468,692500,694466-694469,694472,694717,694748-
> >694749,694870,695503,695509,695553,69,695563,695875-695877,695940,6959
> >80,696436,696455,696721,697086,698129,701526,701634,702275,702443,702527,7
> >02582,702604,702610,702642-702643,702649,702760,702870,702873,702959
> > +/cxf/trunk:651669-686342,686344-686363,686764,686820,687096,687387,68746
> >3,688086,688102,688735,691271,691355,691488,691602,691706,691728,692116,69
> >2157,692466,692499,693653,693819,694179,694263,694417,694716,694744,694747
> >,694869,695396,695484,695537,695552,695561,695619,695684,695835,695935,695
> >977,696094,696433,696720,697085,698128,700261,700602,701783,701830,701862,
> >702267,702580,702602,702609,702616,702656,702957
> > /incubator/cxf/trunk:434594-651668
> >
> > Propchange: cxf/branches/2.0.x-fixes/
> > -
> >- Binary property 'svnmerge-integrated' - no diff available.
> >
> > Modified: cxf/branches/2.0.x-fixes/distribution/bundle/all/pom.xml
> > URL:
> > http://svn.apache.org/viewvc/cxf/branches/2.0.x-fixes/distribution/bundle
> >/all/pom.xml?rev=702961&r1=702960&r2=702961&view=diff
> > ==

Re: More on server response policies



On Oct 9, 2008, at 10:38 AM, Sergey Beryozkin wrote:

Does  apply to the inbound our outbound path?  Or both?   
What  are the semantics here?


This coarse-graned policy applies to an endpoint so as I said it's  
up to the   implementation as to whether it will affect in/ 
out/both pathes.


That's fine, in that the AssertionBuilder can render a decision about  
what interceptors to add to the chain.  But that won't solve the bug  
I've identified.


Correct.  Or more appropriately, based on the actual content of  
the  policy.


Not necessarily. ...


I guess I wasn't claiming policy content was the only deciding  
factor.  Let's just drop it.


I actually think that the single effective policy should apply to  
the given operation, in/out. But this policy can contain expressions  
which are valid for the outbound only or inbound only or both. I  
don't think WS-Policy provides for effective polices for in or out  
only, It's a single effective policy instance for the scope of a  
given operation. Though the AssertionInfoMap should be in/out- 
specific.


How are you going to render that calculation?  The policy framework  
has and should have no idea what the content of the assertions is.   
You don't really want to go peeking into the assertion for  
breadcrumbs, do you?



How about this, for a proposal:





 


 
 


 
 






I'd just prefer




So, what you're saying is that the policy framework would know  
something special about the cxf:scope attribute, and that any schema  
for policy assertions would need to be adjusted to support such an  
attribute.  That's kind of messy, isn't it?  Would it also mean that  
policy assertions were less portable, at least as far as copying/ 
pasting policies across documents is concerned?  It's bad enough, with  
all of the namespaces you need to keep track of in a typical CXF  
config file.


I agree that your proposal is semantically equivalent to mine.  I just  
think it's better to treat the customer's (i.e., the customer of the  
policy f/w) policies as kind of sacrosanct.



IMHO this is more compact and easier on the eye.


Well, that's an aesthetic argument, which is hard to argue against,  
because of its subjectivity.  Let's talk about it from a technical,  
rather than aesthetic point of view.



Furthermore, when such policies will be dynamicallyt attached to  
WSDL instance, it would provide more hints to client runtimes/tools.  
Such attribute can also be applied when polices are explicitly  
attached to WSDL. For ex, as I said earlier, there's no explicit  
indication to verifiers on the scope of this policy when it's  
attached to some container element like wsdl:port









Right, but isn't the wsdl:port really equivalent to the jax:ws  
endpoint?  I thought Dan's point was that you could associate policies  
with in/out messages in the binding, and that would be your mechanism  
for specifying different effective policies for the in and out  
channels.  And that works beautifully in WSDL.  My needs are outside  
of WSDL, so I'd like a spring-based mechanism for doing the same kind  
of thing.





we have a PolicyAssertion abstraction and we can add a helper method  
like getScope(), by default it applies to say 'in' only or in/out  
with possisble overrides.


To be honest though, I wouldn't be too concerned now about ensuring  
that outbond policy verifier fails (or reports a warning). I reckon  
the default behaviour (of just logging some FINE message) would do  
in case say   ends up in the list of policies.


Well, I think i) it's a waste of time to do -- why do something if it  
has no purpose -- green computing, and all that.  But also, ii) it's  
just going to raise a question with a customer.  "Why is there is log  
entry that says something failed?  The request passed!  What's going  
on?  Quick, file a bug."



Only when it's absolutely critical that an outbound message does not  
leave the server runtime if some policies have not been applied to  
the outbound message (SLA agreement with non policy aware client  
runtimes for ex) then I'd consider adding such hints.


Hold it -- so you're saying this interceptor should raise a fault?


Yup.  If it's of no use, remove it.


Mostly agreed but see above - we might need it at some time. And  
it's probably can behave differently on the client side.


It's surely needed on the client side -- I wasn't saying to remove  
verification on the outbound side of any side of a request.  My  
suggestion was to remove the interceptor from the outbound server  
response interceptor chain, as it's really doing nothing but chewing  
up clock cycles.


We can also suggest to the ws-policy group to consider standardizing  
on such attribute (as it can be of real help to client runtimes) in  
the next maintenance release of the spec, whenever it happens.


Yeah, well, that's not gonna help me with my Q4 release.



And I'd like to stress again that PolicyAlternativeSelect

cxf-spring integration questions

2008-10-09 Thread Orban, Gyorgy (IT)

Hi,

I would like to ask for some guidance on using CXF together with Spring, more 
specifically in terms of lifecycle management. There seems to be two ways how 
CXF can be integrated with Spring:

1) It can be embedded in Spring as outlined in 
http://cwiki.apache.org/CXF20DOC/deploymentspring.html. In this case, the 
user's application context imports the cxf spring configuration and the CXF 
runtime will be in the same context as the application. For servlet 
environment, this seems to be the only option.

2) CXF can start up a separate context (bus application context) for its 
runtime. Config example for this can be found at  
http://cwiki.apache.org/CXF20DOC/jax-ws-configuration.html (first config, no 
imports).


CXF seems to have its own lifecycle manager component implemented in 
CXFBusLifeCycleManager, which can control the spring context through 
org.apache.cxf.bus.spring.SpringBusFactory.BusApplicationContextLifeCycleListener
 in case 2).

However, if a user chooses to embed cxf in the spring context (case 1) of his 
application there seems to be no default mapping from some of the spring 
lifecycle events to the bus events. For example, CXFBusImpl.shutdown() does not 
get called when spring closes the context because it does not hook into 
Spring's destroy callback, which leaves servers running after the user 
application context is shut down. Is there any reason why that is not done 
automatically? For example, we need to do this now to get servers shut down 
properly:

public class CXFBusSpringLifecycleBridge implements InitializingBean, 
DisposableBean {
@Resource(name = "org.apache.cxf.buslifecycle.BusLifeCycleManager")
private org.apache.cxf.buslifecycle.BusLifeCycleManager 
busLifeCycleManager;

@Resource(name = Bus.DEFAULT_BUS_ID)
private Bus bus;
...
@Override
public void destroy() throws Exception {
((CXFBusImpl) bus).shutdown(true);
}
}

Also, could you please advise on what would be the best way of delegating 
Spring's org.springframework.context.Lifecycle start() and stop() events to cxf 
servers? org.apache.cxf.endpoint.Server.start() and stop() seems to have the 
same semantics as Lifecycle.start() and stop(), so could CXF maybe implement 
the spring Lifecycle interface directly?

Another problem around spring integration seems to be that it includes a 
Jsr250BeanPostProcessor by default, which pollutes the user's config in case 1. 
Should that be maybe made optional similarly to the extensions?

Thanks,
Gyorgy


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.

Re: More on server response policies

2008-10-09 Thread Sergey Beryozkin

Hi Fred

I strat thinking this message gets a bit off-track :-) Few more comments.

That's fine, in that the AssertionBuilder can render a decision about what interceptors to add to the chain. But that won't
solve the bug I've identified.

As we've said many times what will solve this problem is the out verifier
logging a message. For now, untill
we sort out the issue of hints.

I actually think that the single effective policy should apply to the given operation, in/out. But this policy can contain
expressions which are valid for the outbound only or inbound only or both. I don't think WS-Policy provides for effective
polices for in or out only, It's a single effective policy instance for the scope of a given operation. Though the
AssertionInfoMap should be in/out- specific.

How are you going to render that calculation? The policy framework has and should have no idea what the content of the
assertions is. You don't really want to go peeking into the assertion for breadcrumbs, do you?

Sorry, not following you. Neither I'm talking of the policy engine peeking into
the individual assertions,
PolicyAssertion is an interface and the AssertionInfoMap could check the scopes
(when they're introduced)

How about this, for a proposal:

I'd just prefer

So, what you're saying is that the policy framework would know something special about the cxf:scope attribute, and that any
schema for policy assertions would need to be adjusted to support such an attribute. That's kind of messy, isn't it?

Not at all. I think we're getting off track again here. First you're saying
that there're no need
for the out interceptor at all, and now you're saying that something has to be
adjusted. As I said,
any more or less decent schema has the default extension point for 'any'
attributes. Next, often there's
no even need to verify on the outbound path. Only for those polices which
really need to do it we can add
such an attribute.

I agree that your proposal is semantically equivalent to mine. I just think it's better to treat the customer's (i.e., the
customer of the policy f/w) policies as kind of sacrosanct.

IMHO this is more compact and easier on the eye.

Well, that's an aesthetic argument, which is hard to argue against, because of its subjectivity. Let's talk about it from a
technical, rather than aesthetic point of view.

No. It's not an aesthetic argument. This solution is more portable in that it
can be applied to
policies both in the spring configuration and in WSDL. It's more compact and given that you're concerned about the overall
complexity of Ws-Policy expression I don't get the point of this comment : isn't it what we're after = reducing the complexity as
much as possible ?

Finally, I just don't think it works at all :

A single Policy (alternative) expression may contain a bunch of expressions. So
instead of

you suggest creating a single feature per single expression. I disagree.

Right, but isn't the wsdl:port really equivalent to the jax:ws endpoint? I thought Dan's point was that you could associate
policies with in/out messages in the binding, and that would be your mechanism for specifying different effective policies for
the in and out channels. And that works beautifully in WSDL. My needs are outside of WSDL, so I'd like a spring-based
mechanism for doing the same kind of thing.

No, that's not correct. As I've said many times before, the fact that your
policies live in
spring does not mean that they're different from those living in WSDL. Those
which live in Spring
will be attached to WSDL once I fix the pending bug (with truly private stuff
being removed). In both cases
these polices are of common interest to both client and server. This is the
point of using of WS-Policy.
I don't want to conflate this thread with the discussions on teh purpose of
WS-policy though.

We can also suggest to the ws-policy group to consider standardizing on such attribute (as it can be of real help to client
runtimes) in the next maintenance release of the spec, whenever it happens.

Yeah, well, that's not gonna help me with my Q4 release.

I'm sorry - don't get this comment either.

On the client it's none needed either - the client needs to iterate through all the available alternatives and find the best
one.

Interesting. So it should be the policy consumer that selects the alternatives? I don't think the current architecture supports
that, does it?

PolicyAlternativeSelector is broken, It has to go. It does not make sense to
select only the first alternative,
or the last or the middle one because it's never going to go reliably.

Cheers, Sergey

-Fred

IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: cxf-spring integration questions

On Thursday 09 October 2008 11:49:28 am Orban, Gyorgy (IT) wrote:
> 1) It can be embedded in Spring as outlined in
> http://cwiki.apache.org/CXF20DOC/deploymentspring.html. In this case, the
> user's application context imports the cxf spring configuration and the CXF
> runtime will be in the same context as the application. For servlet
> environment, this seems to be the only option.
>
> 2) CXF can start up a separate context (bus application context) for its
> runtime. Config example for this can be found at 
> http://cwiki.apache.org/CXF20DOC/jax-ws-configuration.html (first config,
> no imports).

This can be done in the servlet case as well with a WEB-INF/cxf-servlet.xml.   
Not too popular though as it does limit what can be configured.

> CXF seems to have its own lifecycle manager component implemented in
> CXFBusLifeCycleManager, which can control the spring context through
> org.apache.cxf.bus.spring.SpringBusFactory.BusApplicationContextLifeCycleLi
>stener in case 2).
>
> However, if a user chooses to embed cxf in the spring context (case 1) of
> his application there seems to be no default mapping from some of the
> spring lifecycle events to the bus events. For example,
> CXFBusImpl.shutdown() does not get called when spring closes the context
> because it does not hook into Spring's destroy callback, which leaves
> servers running after the user application context is shut down. Is there
> any reason why that is not done automatically? For example, we need to do
> this now to get servers shut down properly:

A bug probably should be logged here.It probably should have a shutdown 
hook registered with spring.  (and patch would be nice too with the grant to 
apache box checked   ;-)  

> Also, could you please advise on what would be the best way of delegating
> Spring's org.springframework.context.Lifecycle start() and stop() events to
> cxf servers? org.apache.cxf.endpoint.Server.start() and stop() seems to
> have the same semantics as Lifecycle.start() and stop(), so could CXF maybe
> implement the spring Lifecycle interface directly?

Many parts of CXF need to be usable without the spring jars so they cannot 
implement them directly.HOWEVER, we also use spring specific subclasses 
in a bunch of cases that COULD implement them.For example, in the 
org.apache.cxf.jaxws.spring.EndpointDefinitionParser class that handles the 
jaxws:endpoint things, it parsed into a special SpringEndpointImpl. That 
COULD (and does) implement spring specific stuff.   This could be expanded to 
other areas as well.Again, jira's and patches are quite welcome.

> Another problem around spring integration seems to be that it includes a
> Jsr250BeanPostProcessor by default, which pollutes the user's config in
> case 1. Should that be maybe made optional similarly to the extensions?

Well, there is a lot of stuff in CXF itself that is wired together with the 
@Resource/@PostConstruct annotations that that bean post processor handles.   
Thus, a lot of stuff will fail if it it's not there.   What's the problem 
with it?

I know one issue is that if you have Springs jsr250 processor enabled, the 
stuff gets called twice.One option I want to try for that is to add:

@Resource
Bus bus

to the Jsr250BeanPostProcessor.   If bus is not null in the process methods, 
then the Spring 250 processor is enabled (and has injected the Bus) and will 
handle things.   If it IS null, then the spring one is not enabled and we 
need to handle it. I definitely need to verify that though and probably 
run the full test suite with the spring processor turned on to make sure the 
bus is completely setup properly.

-- 
Daniel Kulp
[EMAIL PROTECTED]
http://dankulp.com/blog

Re: How to handle a configuration problem generally in CXF code

On Wednesday 08 October 2008 7:17:59 pm Christian Schneider wrote:
> I would propose to add the following to UncheckedException and
> corresponding "super" calls to all exceptions.
>
> public UncheckedException(String code, ResourceBundle bundle,
> Object...params) {
> this(new Message(code, bundle, params));
> }
>
> public UncheckedException(String code, Throwable t, ResourceBundle
> bundle, Object...params) {
> this(new Message(code, bundle, params), t);
> }
>
> To use these you could do the following at the start of the class:
> static final Logger LOG =
> LogUtils.getL7dLogger(JMSConfigFeature.class); static final ResourceBundle
> BUNDLE = LOG.getResourceBundle();
>
> and then:
> throw new ConfigurationException("JMSCONFIGFEATURE_ONLY_JMS", BUNDLE);

Works for me.   A convienience constructor like:
public UncheckedException(String code, Logger log, Object...params) {
 this(new Message(code, log.getResourceBundle(), params));
}

might be nice to avoid having extra derivable instance variables, but not 
really important.

> I have checked where the i18n Message is used and it seems only to be
> used for exceptions. So would it perhaps make sense to deprecate it and
> always create exceptions like above?
> Was there a special reason for the introduction of i18n Message?

Probably.   It was originally (like REALLY REALLY long time ago) also used for 
Logging before we settled on j.u.l since most logging kits don't support 
resource bundles.   Thus, we needed that just to log i18n messages. Once 
we settled on j.u.l, it probably should have been changed.

> Any opinions?

Go for it.   :-)

Dan


>
> Greetings
>
> Christian
>
> Benson Margulies schrieb:
> > I'm +1 to the constructor. I find the new-ing of messages to be a pain.
> >
> > On Tue, Oct 7, 2008 at 5:27 PM, Christian Schneider
> > <[EMAIL PROTECTED]
> >
> >> wrote:



-- 
Daniel Kulp
[EMAIL PROTECTED]
http://dankulp.com/blog

Re: wsa:Action interop issue

I'm not sure what to say about this one.   Neither CXF or the RI are "wrong" 
here, they are both completely correct per the specifications. 

Putting the "name" there is definitely OK per JAX-WS spec and I definitely 
prefer keeping it there as certain tools sometimes have issues mapping things 
together without it.  (I got bit several times with older versions of wsdl4j)

If we were to generate a wsaw:Action on it, we would follow the rules in the 
WS-A spec for the case where the name is specified and it would be:
wsaw:Action="http://geronimo.apache.org/calculator/Calculator/add";
which is still different than what the RI would be.

In anycase, I think the "proper" thing to say here is "add an @Action 
annotation".   Make sure you completely control it.

Dan

On Tuesday 07 October 2008 11:26:31 pm Jarek Gawor wrote:
> Hi,
>
> I ran into an interesting interop issue with wsa:Action between CXF
> and JAX-WS RI (2.1.4). I have a simple service class, no sei, no
> @Action annotations, something like:
>
> @WebService
> @Addressing
> class Calculator {
>  public int add(in n1, in2) {
>return n1 + n2;
>  }
> }
>
> CXF generated the following wsdl:operation for the "add" method:
>
> 
> 
> 
> 
>
> JAX-WS RI generated the following wsdl:operation for the same method:
>
> 
> wsaw:Action="http://geronimo.apache.org/calculator/Calculator/addRequest"/>
>
> 
>
> Now, the wsa:Action for the CXF generated wsdl:operation would be
> "http://geronimo.apache.org/calculator/Calculator/add";, and for RI is
> "http://geronimo.apache.org/calculator/Calculator/addRequest";. Since
> the wsa:Action are slightly different that might create an interop
> problem. I couldn't really find that much info on this issue in the
> JAX-WS spec but I assume if the @Action is not specified the default
> algorithm (as defined in the WS-A spec) should be used. The wsa:Action
> generated by the RI conforms to that algorithm.
> So I think the CXF should either not add the "name" attribute to
> wsdl:input/output messages or add in an explicit wsa:Action attribute
> as the RI does.
>
> Thoughts?
>
> Jarek

-- 
Daniel Kulp
[EMAIL PROTECTED]
http://dankulp.com/blog

RE: More on server response policies

2008-10-09 Thread Sergey Beryozkin

Hi,

I'd like to try to summarize what we've talked at this thread. Fred - please
feel free to challenge what I'm about to say :-)

Original problem : server-side outbound Policy interceptor assumes that no
policy alternative has been asserted on the outbound path and reports a
failure by (mistakenly) writing to the output stream.

During the discussion (I think/hope :-)) we've mostly agreed that unless
there's a really strong need for the application to depend upon the out
verifier failing, this out verifier should do nothing, possibly just logging
a message and perhaps do nothing at all in most cases.

It's the role of the actual policy interceptors to take stronger action when
necessary. The role of the verifier is to validate that those interceptors
have actually done their work. Unless the (out) verifier is given some hints
about the scope of a given policy expression, it can not reliably assert
that just because this policy has not been asserted on the outbound path it
means that the policy contract has not been fulfilled.

Note that adding such hints only makes sense when it's of paramount
importance that the out verifier validates that a given policy has been
engaged on the out path. In other case they're not needed and thus the out
verifier can keep quiet.

Only when we do want the out verifier to fail (softly with WARNING or throw
some exception) then it would make sense adding the hints to the policy
expressions.

One way to provide such hint is basically to do a custom implementation of
PolicyAssertion and return the value based on the custom knowledge
(similarly to the way interceptors tell about their phases).

Another idea is to introduce new features to represent inbound or outbound
only assertions. IMHO this is a bit too coarse-grained and introducing new
features to represent some qualities of policies (in/out) may not be
justified. That said this idea may be of help when dealing with tightly
controlled 3rd party policy expressions (see next).

Another idea is to introduce a custom attribute, to be added to individual
policy expressions when needed. There's a concern that it may be too
intrusive. IMHO the compactness and portability (can be applied to policies
in the wsdl) of this solution outweighs these concerns. 

Futhermore, IMHO it's unlikely that adding such an attribute would cause any
practical interop/policy validation issues - but if it will then we might be
able to rely on previous proposal or come up with something else such that
we can point to one or more of the assertions inside a given alternative
(lists of qnames or xpaths at the existing policy feature, stripping out
such attributes when publishing them, etc).

I'd like to stress the fact that such hints may only needed when there's an
explicit demand for the out verifier to validate if the policies have been
used on the out path.

Thanks, Sergey
  



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Wiki JAX-RS(JSR-311) documentation

2008-10-09 Thread Ricardo Paiva

There are an error on page:
http://cwiki.apache.org/CXF20DOC/jax-rs-jsr-311.html

the code:


  
  


Should be:


  
  


I tried to fix by myself, bu I don't have permission for that.

Regards,

Ricardo

-- 
Ricardo Paiva
Java & Flex Developer - RHCE
Rio de Janeiro - Brazil
werneck [dot] paiva [at] gmail [dot] com

Re: More on server response policies


Yeah, I think this summarizes it well.

On Oct 9, 2008, at 5:10 PM, Sergey Beryozkin wrote:


Hi,

I'd like to try to summarize what we've talked at this thread. Fred  
- please

feel free to challenge what I'm about to say :-)

Original problem : server-side outbound Policy interceptor assumes  
that no
policy alternative has been asserted on the outbound path and  
reports a

failure by (mistakenly) writing to the output stream.


Correct -- and in general, this will only happen if there is an  
alternative of cardinality > 1.





During the discussion (I think/hope :-)) we've mostly agreed that  
unless
there's a really strong need for the application to depend upon the  
out
verifier failing, this out verifier should do nothing, possibly just  
logging

a message and perhaps do nothing at all in most cases.


Correct.  Dan, you: +1 on logging (FINE or lower log level).  Me: +1  
on removing the validation out interceptor (outbound server side  
only), since it's doing nothing put churning cycles and possibly  
confusing the user.





It's the role of the actual policy interceptors to take stronger  
action when
necessary. The role of the verifier is to validate that those  
interceptors
have actually done their work. Unless the (out) verifier is given  
some hints
about the scope of a given policy expression, it can not reliably  
assert
that just because this policy has not been asserted on the outbound  
path it

means that the policy contract has not been fulfilled.

Note that adding such hints only makes sense when it's of paramount
importance that the out verifier validates that a given policy has  
been
engaged on the out path. In other case they're not needed and thus  
the out

verifier can keep quiet.

Only when we do want the out verifier to fail (softly with WARNING  
or throw
some exception) then it would make sense adding the hints to the  
policy

expressions.

One way to provide such hint is basically to do a custom  
implementation of

PolicyAssertion and return the value based on the custom knowledge
(similarly to the way interceptors tell about their phases).

Another idea is to introduce new features to represent inbound or  
outbound
only assertions. IMHO this is a bit too coarse-grained and  
introducing new

features to represent some qualities of policies (in/out) may not be
justified. That said this idea may be of help when dealing with  
tightly

controlled 3rd party policy expressions (see next).

Another idea is to introduce a custom attribute, to be added to  
individual

policy expressions when needed. There's a concern that it may be too
intrusive. IMHO the compactness and portability (can be applied to  
policies

in the wsdl) of this solution outweighs these concerns.


All three ideas amount to essentially the same idea: that the  
effective policy (hence the policy vocabulary, hence the contents of  
the AssertionInfoMap) is possibly different on the inbound and  
outbound interceptor chains.  /How/ that's done is probably less  
important that /that/ it be done, because I don't think the current  
way is really workable -- Right now I have to hack my way through the  
outbound response AssertionInfoMap, checking off Assertions that have  
already been checked off on the inbound channel, which is a hack  
(requires that I artificially store data on the Exchange, etc), and  
just adds extra overhead to the runtime.


-Fred

Spring + Hibernate + Apache CXF Error

2008-10-09 Thread Saiful Haqqi


hi all,

I try build WS with apache cxf + Sring + Hibernate, but get some error when
implementation with hibernate.

1. Without Hibernate 

my [appContext.xml]


http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:context="http://www.springframework.org/schema/context";
xmlns:cxf="http://cxf.apache.org/core";
xmlns:jaxws="http://cxf.apache.org/jaxws";
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-2.5.xsd
http://cxf.apache.org/core
http://cxf.apache.org/schemas/core.xsd
http://cxf.apache.org/jaxws
http://cxf.apache.org/schemas/jaxws.xsd";
>
  




















that WS work and can response dump data with method
http://localhost:8080/SpringWS/contactus/getMessages.

2. With Hibernate

my [appContext.xml]


http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:context="http://www.springframework.org/schema/context";
xmlns:cxf="http://cxf.apache.org/core";
xmlns:jaxws="http://cxf.apache.org/jaxws";
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-2.5.xsd
http://cxf.apache.org/core
http://cxf.apache.org/schemas/core.xsd
http://cxf.apache.org/jaxws
http://cxf.apache.org/schemas/jaxws.xsd";
>
  





























${jdbc.driver}


${jdbc.url}


${jdbc.username}


${jdbc.password}








${hibernate.dialect}

${hibernate.show_sql}












  



that will get exception
10 Okt 08 5:48:16
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry
destroySingletons
INFO: Destroying singletons in
[EMAIL PROTECTED]:
defining beans
[cxf,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,org.apache.cxf.resource.ResourceManager,org.apache.cxf.configuration.Configurer,org.apache.cxf.binding.BindingFactoryManager,org.apache.cxf.transport.DestinationFactoryManager,org.apache.cxf.transport.ConduitInitiatorManager,org.apache.cxf.wsdl.WSDLManager,org.apache.cxf.phase.PhaseManager,org.apache.cxf.workqueue.WorkQueueManager,org.apache.cxf.buslifecycle.BusLifeCycleManager,org.apache.cxf.endpoint.ServerRegistry,org.apache.cxf.endpoint.ServerLifeCycleManager,org.apache.cxf.endpoint.ClientLifeCycleManager,org.apache.cxf.transports.http.QueryHandlerRegistry,org.apache.cxf.endpoint.EndpointResolverRegistry,org.apache.cxf.headers.HeaderManager,org.apache.cxf.catalog.OASISCatalogManager,org.apache.cxf.endpoint.ServiceContractResolverRegistry,org.apache.cxf.binding.soap.SoapBindingFactory,org.apache.cxf.binding.soap.SoapTransportFactory,org.apache.cxf.binding.soap.customEditorConfigurer,org.apache.cxf.transport.servlet.ServletTransportFactory,contactUsService,occHwDailyService,propertyConfigurer,dataSource,factory,WinOccHwDailyBean];
root of factory hierarchy
10 Okt 08 5:48:16 org.springframework.web.context.ContextLoader
initWebApplicationContext
SEVERE: Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'factory' defined in ServletContext resource
[/WEB-INF/appContext.xml]: Invocation of init method failed; nested
exception is java.lang.NoSuchMethodError:
org.objectweb.asm.ClassVisitor.visit(IILjava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;)V
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1362)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:540)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:485)
at java.security.AccessController.doPrivileged(Native Method)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapab

Re: Spring + Hibernate + Apache CXF Error

2008-10-09 Thread 王洪伟

The version of you are using asm jars (with org.objectweb.asm.ClassVisitor)
is not match with current spring ,try a newer.

Good luck!


2008/10/10 Saiful Haqqi <[EMAIL PROTECTED]>

>
> hi all,
>
> I try build WS with apache cxf + Sring + Hibernate, but get some error when
> implementation with hibernate.
>
> 1. Without Hibernate
>
> my [appContext.xml]
>
> 
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:context="http://www.springframework.org/schema/context";
>xmlns:cxf="http://cxf.apache.org/core";
>xmlns:jaxws="http://cxf.apache.org/jaxws";
>xsi:schemaLocation="http://www.springframework.org/schema/beans
>http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
>http://www.springframework.org/schema/context
>
> http://www.springframework.org/schema/context/spring-context-2.5.xsd
>http://cxf.apache.org/core
>http://cxf.apache.org/schemas/core.xsd
>http://cxf.apache.org/jaxws
>http://cxf.apache.org/schemas/jaxws.xsd";
>>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>implementor="contactus.ContactUsServiceImpl"
>address="/contactus">
>
>
>
> 
>
> that WS work and can response dump data with method
> http://localhost:8080/SpringWS/contactus/getMessages.
>
> 2. With Hibernate
>
> my [appContext.xml]
>
> 
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:context="http://www.springframework.org/schema/context";
>xmlns:cxf="http://cxf.apache.org/core";
>xmlns:jaxws="http://cxf.apache.org/jaxws";
>xsi:schemaLocation="http://www.springframework.org/schema/beans
>http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
>http://www.springframework.org/schema/context
>
> http://www.springframework.org/schema/context/spring-context-2.5.xsd
>http://cxf.apache.org/core
>http://cxf.apache.org/schemas/core.xsd
>http://cxf.apache.org/jaxws
>http://cxf.apache.org/schemas/jaxws.xsd";
>>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>implementor="contactus.ContactUsServiceImpl"
>address="/contactus">
>
>
>
>
>
> implementor="com.wesolve.dvas.spring.ws.domain.service.OccHwDailyServiceImpl"
>address="/occHwDaily">
>
>
>
>id="propertyConfigurer"
>
> class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
>
>
>
>
>id="dataSource"
>class="org.apache.commons.dbcp.BasicDataSource"
>destroy-method="close">
>
>${jdbc.driver}
>
>
>${jdbc.url}
>
>
>${jdbc.username}
>
>
>${jdbc.password}
>
>
>
>
>id="factory"
>class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
> value="classpath:hibernate.cfg.xml"/>
>
>
>${hibernate.dialect}
>
>${hibernate.show_sql}
>
>
>
>
>
>
>
>
>
>id="WinOccHwDailyBean"
>class="com.wesolve.dvas.spring.hibernate.dao.WinOccHwDailyDaoImpl">
>
>
>
>
> 
>
> that will get exception
> 10 Okt 08 5:48:16
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry
> destroySingletons
> INFO: Destroying singletons in
>
> [EMAIL PROTECTED]
> :
> defining beans
>
> [cxf,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,org.apache.cxf.resource.ResourceManager,org.apache.cxf.configuration.Configurer,org.apache.cxf.binding.BindingFactoryManager,org.apache.cxf.transport.DestinationFactoryManager,org.apache.cxf.transport.ConduitInitiatorManager,org.apache.cxf.wsdl.WSDLManager,org.apache.cxf.phase.PhaseManager,org.apache.cxf.workqueue.WorkQueueManager,org.apache.cxf.buslifecycle.BusLifeCycleManager,org.apache.cxf.endpoint.ServerRegistry,org.apache.cxf.endpoint.ServerLifeCycleManager,org.apache.cxf.endpoint.ClientLifeCycleManager,org.apache.cxf.transports.http.QueryHandlerRegistry,org.apache.cxf.endpoint.EndpointResolverRegistry,org.apache.cxf.headers.HeaderManager,org.apache.cxf.catalog.OASISCatalogManager,org.apache.cxf.endpoint.ServiceContractResolverRegistry,org.apache.cxf.binding.soap.SoapBindingFactory,org.apache.cxf.binding.soap.SoapTransportFactory,org.apache.cxf.binding.soap.customEditorConfigurer,org.apache.cxf.transport.servlet.ServletTransportFactory,contactUsService,occHwDailyService,propertyConfigurer,dataSource,factory,WinOccHwDailyBean];
> root of factory hierarchy
> 10 Okt 08 5:48:16 org.springframework.web.context

Re: Spring + Hibernate + Apache CXF Error

2008-10-09 Thread Saiful Haqqi


> The version of you are using asm jars (with org.objectweb.asm.ClassVisitor)
> is not match with current spring ,try a newer.
>
> Good luck!

In my wat file containt with more than one asm jar file

1. asm <--- hibernate
2. asm-2.2.3 <-- apache cxf
3. asm-all-3.1 <--- my own add
4. asm-attrs <--- hibernate
5. cglib-2.1.3 <-- hibernate
6. cglib-nodep-2.1_3 < my own add

with one is the right jar file asm-all-3.1 or cglib-nodep-2.1_3 or both must
be included in my war file?

~ saiful haqqi ~

-- 
View this message in context: 
http://www.nabble.com/Spring-%2B-Hibernate-%2B-Apache-CXF-Error-tp19908825p19910531.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Re: Spring + Hibernate + Apache CXF Error

2008-10-09 Thread Saiful Haqqi




Saiful Haqqi wrote:
> 
>> The version of you are using asm jars (with
>> org.objectweb.asm.ClassVisitor)
>> is not match with current spring ,try a newer.
>>
>> Good luck!
> 
> I am just use asm-all and cglib-nodep now and does't get any exception
> when deploying spring application.
> 
> But I get new exception when call the method of web service
> 
> INFO: Application has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: ApplicationObjectSupport instance
> [EMAIL PROTECTED] does not run in an ApplicationContext
> at
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:119)
> 
> that is still related with asm or cglib ... ?!
> 
> ~ saiful haqqi ~
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Spring-%2B-Hibernate-%2B-Apache-CXF-Error-tp19908825p19910764.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Re: Spring + Hibernate + Apache CXF Error