July 2013 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3674) Allow WebSerivceFactory to parse new {http://xmlns.jcp.org/xml/ns/javaee}webservice element

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3674?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3674: ---------------------------------- Fix Version/s: jbossws-cxf-4.2 > Allow WebSerivceFactory to parse new {http://xmlns.jcp.org/xml/ns/javaee}webservice element > -------------------------------------------------------------------------------------------- > > Key: JBWS-3674 > URL: https://issues.jboss.org/browse/JBWS-3674 > Project: JBoss Web Services > Issue Type: Task > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Jim Ma > Assignee: Jim Ma > Fix For: jbossws-cxf-4.2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3674) Allow WebSerivceFactory to parse new {http://xmlns.jcp.org/xml/ns/javaee}webservice element

by Jim Ma (JIRA)

Jim Ma created JBWS-3674: ---------------------------- Summary: Allow WebSerivceFactory to parse new {http://xmlns.jcp.org/xml/ns/javaee}webservice element Key: JBWS-3674 URL: https://issues.jboss.org/browse/JBWS-3674 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Jim Ma Assignee: Jim Ma -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3673) WS-Provide support for @PolicySets

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3673: ------------------------------------- Summary: WS-Provide support for @PolicySets Key: JBWS-3673 URL: https://issues.jboss.org/browse/JBWS-3673 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-cxf, tools-jaxws Reporter: Alessio Soldano Fix For: jbossws-cxf-4.3 This is about adding support for the @PolicySets annotation in WS-Provide. See description at https://issues.jboss.org/browse/JBWS-3648 for additional details. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3648) WS-Policy code-first improvements

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3648?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3648: ---------------------------------- Summary: WS-Policy code-first improvements (was: WS-Policy code-first improvements and tooling) > WS-Policy code-first improvements > --------------------------------- > > Key: JBWS-3648 > URL: https://issues.jboss.org/browse/JBWS-3648 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf, productivity > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.2 > > > I'd like to see some kind of ws-policy oriented tooling in JBossWS. Ideally we should provide some mechanisms for basic code-first development; currently stuff like ws-security configuration through policies is actually contract based: the user is expected to either provide a wsdl with proper policies or to use policy attachment, which is basically the same, writing the actual policy assertion is required. > An idea could be to have a group of pre-defined policy assertions' sets for known scenarios (for ws-security those could be based e.g. on the Oasis WS-Security Policy Examples [1]). Each set would be composed of 'placement points' with a policy to be attached at each of those points. We'd then possibly have a custom CXF FactoryBeanListener to be registered in the FactoryBeanListenerManager; the new listener would perform something similar to what the PolicyAnnotationListener does (based on the @Policies/@Policy in the code), that is attaching policies to the proper attach points. An additional step would be to support merging (effective policy through Neethi?) multiple sets at the same time (say, you want e.g. a specific ws-security set plus a ws-rm set). > With such thing, we could provide the initial sets and let users pick the sets they want for a given endpoint (perhaps through a custom annotation, or possibly better specifying the sets' names within a property in a selected Endpoint Config). > The initial policy sets could be stored as xml files in one of the jbossws-cxf jars and we could provide a mechanism for reading additional ones from the current classpath (to let users add additional ones). > Finally, this would open up to further tooling improvements; e.g. 1) wsprovide could be enhanced to process the @EndpointConfig annotation, get the policy sets and produce a ws-policy enabled wsdl, 2) we could even provide an 'educational' gui tool showing assertions enabled/disabled depending on the selected sets, etc. > [1] http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3648) WS-Policy code-first improvements and tooling

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3648?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3648: --------------------------------------- Joseph, please see: https://docs.jboss.org/author/display/JBWS/WS-Policy (just applied a minor update). I'm factoring out the tooling part of the work mentioned in the jira to a new one, the core of the Policy Set stuff is however completed (as per doc above). > WS-Policy code-first improvements and tooling > --------------------------------------------- > > Key: JBWS-3648 > URL: https://issues.jboss.org/browse/JBWS-3648 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf, productivity > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.2 > > > I'd like to see some kind of ws-policy oriented tooling in JBossWS. Ideally we should provide some mechanisms for basic code-first development; currently stuff like ws-security configuration through policies is actually contract based: the user is expected to either provide a wsdl with proper policies or to use policy attachment, which is basically the same, writing the actual policy assertion is required. > An idea could be to have a group of pre-defined policy assertions' sets for known scenarios (for ws-security those could be based e.g. on the Oasis WS-Security Policy Examples [1]). Each set would be composed of 'placement points' with a policy to be attached at each of those points. We'd then possibly have a custom CXF FactoryBeanListener to be registered in the FactoryBeanListenerManager; the new listener would perform something similar to what the PolicyAnnotationListener does (based on the @Policies/@Policy in the code), that is attaching policies to the proper attach points. An additional step would be to support merging (effective policy through Neethi?) multiple sets at the same time (say, you want e.g. a specific ws-security set plus a ws-rm set). > With such thing, we could provide the initial sets and let users pick the sets they want for a given endpoint (perhaps through a custom annotation, or possibly better specifying the sets' names within a property in a selected Endpoint Config). > The initial policy sets could be stored as xml files in one of the jbossws-cxf jars and we could provide a mechanism for reading additional ones from the current classpath (to let users add additional ones). > Finally, this would open up to further tooling improvements; e.g. 1) wsprovide could be enhanced to process the @EndpointConfig annotation, get the policy sets and produce a ws-policy enabled wsdl, 2) we could even provide an 'educational' gui tool showing assertions enabled/disabled depending on the selected sets, etc. > [1] http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3648) WS-Policy code-first improvements and tooling

by Joseph Hwang (JIRA)

[ https://issues.jboss.org/browse/JBWS-3648?page=com.atlassian.jira.plugin.... ] Joseph Hwang commented on JBWS-3648: ------------------------------------ Nice job, Alessio. Thanks! Any documents? > WS-Policy code-first improvements and tooling > --------------------------------------------- > > Key: JBWS-3648 > URL: https://issues.jboss.org/browse/JBWS-3648 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf, productivity > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.2 > > > I'd like to see some kind of ws-policy oriented tooling in JBossWS. Ideally we should provide some mechanisms for basic code-first development; currently stuff like ws-security configuration through policies is actually contract based: the user is expected to either provide a wsdl with proper policies or to use policy attachment, which is basically the same, writing the actual policy assertion is required. > An idea could be to have a group of pre-defined policy assertions' sets for known scenarios (for ws-security those could be based e.g. on the Oasis WS-Security Policy Examples [1]). Each set would be composed of 'placement points' with a policy to be attached at each of those points. We'd then possibly have a custom CXF FactoryBeanListener to be registered in the FactoryBeanListenerManager; the new listener would perform something similar to what the PolicyAnnotationListener does (based on the @Policies/@Policy in the code), that is attaching policies to the proper attach points. An additional step would be to support merging (effective policy through Neethi?) multiple sets at the same time (say, you want e.g. a specific ws-security set plus a ws-rm set). > With such thing, we could provide the initial sets and let users pick the sets they want for a given endpoint (perhaps through a custom annotation, or possibly better specifying the sets' names within a property in a selected Endpoint Config). > The initial policy sets could be stored as xml files in one of the jbossws-cxf jars and we could provide a mechanism for reading additional ones from the current classpath (to let users add additional ones). > Finally, this would open up to further tooling improvements; e.g. 1) wsprovide could be enhanced to process the @EndpointConfig annotation, get the policy sets and produce a ws-policy enabled wsdl, 2) we could even provide an 'educational' gui tool showing assertions enabled/disabled depending on the selected sets, etc. > [1] http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3672) Clone Repository to local with eclipse, got an error "java.net.UnknownHostException"

by terry sun (JIRA)

[ https://issues.jboss.org/browse/JBWS-3672?page=com.atlassian.jira.plugin.... ] terry sun updated JBWS-3672: ---------------------------- Description: 1)New an openshift application in eclipse. 2)Login openshift with a right credential. 3)Set SSH2 preference and network confirguration.(Please see the screenshot.) I have already added bypass [*.rhcloud.com]. then Click on [finish] button ,got [Could not clone the repository. Authentication failed. Please make sure that you added your private key to the ssh preferences. ssh://51f0facc5973ca35ad00001f@dba1-alwaysterry.rhcloud.com/~/git/dba1.git/: java.net.UnknownHostException: dba1-alwaysterry.rhcloud.com ] was: 1)New an openshift application in eclipse. 2)Login openshift with a right credential. 3)Set SSH2 preference and network confirguration.(Please see the screenshot.) then Click on [finish] button ,got [Could not clone the repository. Authentication failed. Please make sure that you added your private key to the ssh preferences. ssh://51f0facc5973ca35ad00001f@dba1-alwaysterry.rhcloud.com/~/git/dba1.git/: java.net.UnknownHostException: dba1-alwaysterry.rhcloud.com ] > Clone Repository to local with eclipse,got an error "java.net.UnknownHostException" > ----------------------------------------------------------------------------------- > > Key: JBWS-3672 > URL: https://issues.jboss.org/browse/JBWS-3672 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: terry sun > > 1)New an openshift application in eclipse. > 2)Login openshift with a right credential. > 3)Set SSH2 preference and network confirguration.(Please see the screenshot.) > I have already added bypass [*.rhcloud.com]. > then Click on [finish] button ,got > [Could not clone the repository. Authentication failed. > Please make sure that you added your private key to the ssh preferences. > ssh://51f0facc5973ca35ad00001f@dba1-alwaysterry.rhcloud.com/~/git/dba1.git/: java.net.UnknownHostException: dba1-alwaysterry.rhcloud.com ] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3672) Clone Repository to local with eclipse, got an error "java.net.UnknownHostException"

by terry sun (JIRA)

terry sun created JBWS-3672: ------------------------------- Summary: Clone Repository to local with eclipse,got an error "java.net.UnknownHostException" Key: JBWS-3672 URL: https://issues.jboss.org/browse/JBWS-3672 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: terry sun 1)New an openshift application in eclipse. 2)Login openshift with a right credential. 3)Set SSH2 preference and network confirguration.(Please see the screenshot.) then Click on [finish] button ,got [Could not clone the repository. Authentication failed. Please make sure that you added your private key to the ssh preferences. ssh://51f0facc5973ca35ad00001f@dba1-alwaysterry.rhcloud.com/~/git/dba1.git/: java.net.UnknownHostException: dba1-alwaysterry.rhcloud.com ] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3671) AbstractServerConfig keep stale reference to server config after reboot

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3671?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3671: ---------------------------------- Affects Version/s: jbossws-cxf-4.1.1 > AbstractServerConfig keep stale reference to server config after reboot > ----------------------------------------------------------------------- > > Key: JBWS-3671 > URL: https://issues.jboss.org/browse/JBWS-3671 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Affects Versions: jbossws-cxf-4.1.1 > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.2 > > > As a consequence of JBWS-3576 fix, the AbstractServerConfig's reference to the AS container ServerConfig might turn into a stale object if the server is reloaded through management. We need to clean up the static references in such cases. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3671) AbstractServerConfig keep stale reference to server config after reboot

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3671?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3671: ---------------------------------- Description: As a consequence of JBWS-3576 fix, the AbstractServerConfig's reference to the AS container ServerConfig might turn into a stale object if the server is reloaded through management. We need to clean up the static references in such cases. > AbstractServerConfig keep stale reference to server config after reboot > ----------------------------------------------------------------------- > > Key: JBWS-3671 > URL: https://issues.jboss.org/browse/JBWS-3671 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.2 > > > As a consequence of JBWS-3576 fix, the AbstractServerConfig's reference to the AS container ServerConfig might turn into a stale object if the server is reloaded through management. We need to clean up the static references in such cases. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues July 2013