[jira] [Resolved] (CXF-4585) Updated the cxf imports version range of sts-core bundle
[ https://issues.apache.org/jira/browse/CXF-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CXF-4585. --- Resolution: Not A Problem > Updated the cxf imports version range of sts-core bundle > > > Key: CXF-4585 > URL: https://issues.apache.org/jira/browse/CXF-4585 > Project: CXF > Issue Type: Improvement > Components: Services >Reporter: Willem Jiang >Assignee: Willem Jiang >Priority: Minor > Fix For: 2.6.4, 2.7.1 > > > sts service should not have the hard dependency on the current version of CXF. > Setup the version range could help the user to deploy the service into > different version of CXF. -- 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
[jira] [Commented] (CXF-4585) Updated the cxf imports version range of sts-core bundle
[ https://issues.apache.org/jira/browse/CXF-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489285#comment-13489285 ] Willem Jiang commented on CXF-4585: --- I just reverted the patch from trunk and 2.6.x-fixed branch. > Updated the cxf imports version range of sts-core bundle > > > Key: CXF-4585 > URL: https://issues.apache.org/jira/browse/CXF-4585 > Project: CXF > Issue Type: Improvement > Components: Services >Reporter: Willem Jiang >Assignee: Willem Jiang >Priority: Minor > Fix For: 2.6.4, 2.7.1 > > > sts service should not have the hard dependency on the current version of CXF. > Setup the version range could help the user to deploy the service into > different version of CXF. -- 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
[jira] [Created] (DOSGI-137) Possible bug in TopologyManagerImport when checking if an Endpoint is already imported
Christian Schneider created DOSGI-137:
-
Summary: Possible bug in TopologyManagerImport when checking if an
Endpoint is already imported
Key: DOSGI-137
URL: https://issues.apache.org/jira/browse/DOSGI-137
Project: CXF Distributed OSGi
Issue Type: Bug
Affects Versions: 1.3.1
Reporter: Christian Schneider
Assignee: Christian Schneider
Fix For: 1.4
In TopologyManagerImport.importServices we seem to check if we already imported
an endpoint. (See snippet below).
private void importServices(String filter) {
List importRegistrations =
getImportedServices(filter);
for (EndpointDescription epd : importPossibilities.get(filter)) {
if (!importRegistrations.contains(epd)) {
I have two concerns with this:
1. importRegistrations is a List but we check using
contains(epd) which is an EndpointDescription. I think this can never return
true.
I have prepared a code that can fix this:
private boolean alreadyImported(EndpointDescription epd,
List importRegistrations) {
for (ImportRegistration ir : importRegistrations) {
if (epd.equals(ir.getImportReference().getImportedEndpoint())) {
return true;
}
}
return false;
}
As soon as I fix it though the second concern below may be an issue.
2. We only have one list of ImportRegistrations. In case a RemoteServiceAdmin
is added this means that we would not add it to this new RemoteServiceAdmin. So
the question here is: Do we want to import each service with each RSA or only
with one?
So any ideas how to proceed here?
--
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
[jira] [Resolved] (CXF-4552) typical HTML form payload does not seem to work when HTML form is used
[
https://issues.apache.org/jira/browse/CXF-4552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-4552.
---
Resolution: Fixed
mapping multiple parts with the same content id to a collection parameter bound
to that content id with Multipart annotation is also supported
> typical HTML form payload does not seem to work when HTML form is used
> --
>
> Key: CXF-4552
> URL: https://issues.apache.org/jira/browse/CXF-4552
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.5.2
> Environment: mitenm@pinkydebian:~$ uname -a; java -version
> Linux pinkydebian 2.6.32-5-686 #1 SMP Sun May 6 04:01:19 UTC 2012 i686
> GNU/Linux
> java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) Client VM (build 23.0-b21, mixed mode)
> mitenm@pinkydebian:~$
>Reporter: Miten Mehta
>Assignee: Sergey Beryozkin
> Fix For: 2.7.1, 2.6.3, 2.5.6
>
>
> I am using HTML form below to upload files using jax-rs but the attachments
> parameter is null.
> The code and error are shown:
> form:
>
>
>
>
>
> enctype="multipart/form-data"
>method="post">
>
>What is your name?
>What files are you sending?
>
>
>
>
>
> code:
> package demo.jaxrs.server;
> import java.io.BufferedReader;
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.InputStreamReader;
> import java.util.List;
> import javax.ws.rs.Consumes;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
> import javax.ws.rs.core.Response;
> import org.apache.cxf.jaxrs.ext.multipart.Multipart;
> import org.apache.cxf.message.Attachment;
> @Path("/files/")
> public class MultipartService {
>
> @Path("/upload")
> @Consumes("multipart/form-data")
> @Produces("text/html")
> @POST
> public Response addAttachments(@Multipart("submit-name") String
> submitName,
> @Multipart("files") List files) {
>
> System.out.println(submitName);
> System.out.println(files);
> for(Attachment a:files) {
> System.out.println(a.getId());
> InputStream is;
> try {
> is = a.getDataHandler().getInputStream();
> BufferedReader r = new BufferedReader(new
> InputStreamReader(is));
> System.out.println(r.readLine());
> } catch (IOException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> }
>
> return Response.ok("Files
> Saved").type("text/html").build();
> }
> }
> beans.xml:
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:jaxrs="http://cxf.apache.org/jaxrs";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/jaxrs.xsd";>
>
>
>
>class="org.apache.cxf.interceptor.LoggingInInterceptor"/>
>
>
>
>
>
>
>
>
>
>
>
> error log:
> 17:10:58 INFO context.ContextLoader - Root WebApplicationContext:
> initialization completed in 1422 ms
> 17:10:58 DEBUG support.DefaultListableBeanFactory - Returning cached instance
> of singleton bean 'cxf'
> Oct 09, 2012 5:02:09 PM org.apache.cxf.interceptor.LoggingInInterceptor
> INFO: Inbound Message
>
> ID: 1
> Address: http://pinkydebian:8080/jax_rs_basic/cxf/files/upload
> Encoding: ISO-8859-1
> Http-Method: POST
> Content-Type: multipart/form-data;
> boundary=---222852432428027
> Headers:
> {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8],
> accept-encoding=[gzip, deflate], accept-language=[en-us,en;q=0.5],
> connection=[keep-alive], Content-Length=[469],
> content-type=[multipart/form-data;
> boundary=---222852432428027],
> host=[pinkydebian:8080],
> referer=[http://pinkydebian:8080/jax_rs_basic/multipart.html],
> user-agent=[Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101
> Firefox/15.0.1]}
> Payload: -222852432428027
> Content-Disposition: form-data; name="submit-name"
> Miten
> -222852432428027
> Content-Disposition: form-data; name="files"; filename="kingfisher.txt"
> Content-Type: text/plain
> Service Temporarily Unavaila
[jira] [Commented] (CXF-4608) DOMSource is returned rather than StAXSource
[
https://issues.apache.org/jira/browse/CXF-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489407#comment-13489407
]
Daniel Kulp commented on CXF-4608:
--
It kind of depends on what you need from the WSDL. If you just need the
SOAPAction, then the action fix is definitely usable. If you need more than
that (primarily would be things like WS-Security Policy fragments or similar),
then a deeper workaround would be needed.
> DOMSource is returned rather than StAXSource
>
>
> Key: CXF-4608
> URL: https://issues.apache.org/jira/browse/CXF-4608
> Project: CXF
> Issue Type: Bug
> Components: Services
>Affects Versions: 2.4.2
>Reporter: Steven Hawkins
>Assignee: Daniel Kulp
> Fix For: 2.5.7, 2.6.4, 2.7.1
>
>
> A Service created from a WSDL that has doc literal wrapped operations will
> always return DOMSource regardless of the source type requested by the
> Dispatch.invoke method.
> For example using a WSDL such as: http://www.xignite.com/xQuotes.asmx?WSDL,
> the following code highlights the issue with a class cast exception on the
> last line:
> {code}
> Service service = Service.create(wsdl, new
> QName("http://www.xignite.com/services/";, "XigniteQuotes"));
> Dispatch dispatch = wsdlService.createDispatch(new
> QName("http://www.xignite.com/services/";, "XigniteQuotesSoap"),
> StAXSource.class, Service.Mode.PAYLOAD);
> QName opQName = new QName("http://www.xignite.com/services/";, "GetFundQuote");
> dispatch.getRequestContext().put(MessageContext.WSDL_OPERATION, opQName);
> StAXSource result = dispatch.invoke(someDoc);
> {code}
--
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
[jira] [Resolved] (DOSGI-137) Possible bug in TopologyManagerImport when checking if an Endpoint is already imported
[
https://issues.apache.org/jira/browse/DOSGI-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved DOSGI-137.
---
Resolution: Fixed
> Possible bug in TopologyManagerImport when checking if an Endpoint is already
> imported
> --
>
> Key: DOSGI-137
> URL: https://issues.apache.org/jira/browse/DOSGI-137
> Project: CXF Distributed OSGi
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Christian Schneider
>Assignee: Christian Schneider
> Fix For: 1.4
>
>
> In TopologyManagerImport.importServices we seem to check if we already
> imported an endpoint. (See snippet below).
>
> private void importServices(String filter) {
> List importRegistrations =
> getImportedServices(filter);
> for (EndpointDescription epd : importPossibilities.get(filter)) {
> if (!importRegistrations.contains(epd)) {
>
> I have two concerns with this:
> 1. importRegistrations is a List but we check using
> contains(epd) which is an EndpointDescription. I think this can never return
> true.
> I have prepared a code that can fix this:
> private boolean alreadyImported(EndpointDescription epd,
> List importRegistrations) {
> for (ImportRegistration ir : importRegistrations) {
> if (epd.equals(ir.getImportReference().getImportedEndpoint())) {
> return true;
> }
> }
> return false;
> }
> As soon as I fix it though the second concern below may be an issue.
> 2. We only have one list of ImportRegistrations. In case a RemoteServiceAdmin
> is added this means that we would not add it to this new RemoteServiceAdmin.
> So the question here is: Do we want to import each service with each RSA or
> only with one?
> So any ideas how to proceed here?
--
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
[jira] [Resolved] (DOSGI-136) Refactor zookeeper server and add metatype config
[ https://issues.apache.org/jira/browse/DOSGI-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-136. --- Resolution: Fixed > Refactor zookeeper server and add metatype config > - > > Key: DOSGI-136 > URL: https://issues.apache.org/jira/browse/DOSGI-136 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.3.1 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 1.4 > > > I intend to refactor the zookeeper server classes a bit to make them more > readable and improve the error handling. > As a small functional change I will introduce a default clientPort so people > can directly run with the defaults if they want. > I also will add metatype configs so it is easier to configure the zookeeper > server using the webconsole. -- 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
[jira] [Resolved] (DOSGI-134) Refactoring of TopologyManager
[ https://issues.apache.org/jira/browse/DOSGI-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-134. --- Resolution: Fixed 1404960 02.11.2012 14:42:02, by cschneider DOSGI-134 DOSGI-137 Reordering packages in TopologyManager, fixing bug in checking if an Endpoint is already imported M /cxf/dosgi/trunk/dsw/cxf-topology-manager/src/main/java/org/apache/cxf/dosgi/topologymanager/Activator.java D /cxf/dosgi/trunk/dsw/cxf-topology-manager/src/main/java/org/apache/cxf/dosgi/topologymanager/EndpointListenerManager.java D /cxf/dosgi/trunk/dsw/cxf-topology-manager/src/main/java/org/apache/cxf/dosgi/topologymanager/EndpointListenerNotifier.java D /cxf/dosgi/trunk/dsw/cxf-topology-manager/src/main/java/org/apache/cxf/dosgi/topologymanager/ExportRepository.java D /cxf/dosgi/trunk/dsw/cxf-topology-manager/src/main/java/org/apache/cxf/dosgi/topologymanager/ListenerHookImpl.java D /cxf/dosgi/trunk/dsw/cxf-topology-manager/src/main/java/org/apache/cxf/dosgi/topologymanager/RefManager.java D /cxf/dosgi/trunk/dsw/cxf-topology-manager/src/main/java/org/apache/cxf/dosgi/topologymanager/RemoteServiceAdminLifeCycleListener.java D /cxf/dosgi/trunk/dsw/cxf-topology-manager/src/main/java/org/apache/cxf/dosgi/topologymanager/RemoteServiceAdminTracker.java D /cxf/dosgi/trunk/dsw/cxf-topology-manager/src/main/java/org/apache/cxf/dosgi/topologymanager/ServiceInterestListener.java D /cxf/dosgi/trunk/dsw/cxf-topology-manager/src/main/java/org/apache/cxf/dosgi/topologymanager/TopologyManager.java And 24 more > Refactoring of TopologyManager > -- > > Key: DOSGI-134 > URL: https://issues.apache.org/jira/browse/DOSGI-134 > Project: CXF Distributed OSGi > Issue Type: Improvement >Affects Versions: 1.3.1 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 1.4 > > Attachments: DOSGI-134-1.patch, DOSGI-134-2.patch, > org.apache.cxf.dosgi.topologymanager-after.png > > > Currently the topology manager project contains a lot of cycles between the > classes. The code is also rather difficult to understand. > I have prepared a refactoring to resolve the cycles and make the code a lot > more readable. As the changes are pretty big I will first add a patch and > wait for some feedback. -- 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
[jira] [Commented] (DOSGI-109) NullPointerException in ToloplogyManager during bundle stop
[ https://issues.apache.org/jira/browse/DOSGI-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489430#comment-13489430 ] Christian Schneider commented on DOSGI-109: --- Can you retest with current snapshot. I think the exception should not happen anymore. > NullPointerException in ToloplogyManager during bundle stop > --- > > Key: DOSGI-109 > URL: https://issues.apache.org/jira/browse/DOSGI-109 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Bert Jacobs >Assignee: Christian Schneider > > When I stop the topologymanager, the following exception pops up: > java.lang.NullPointerException > at > org.apache.cxf.dosgi.topologymanager.TopologyManager.removeRemoteServiceAdmin(TopologyManager.java:139) > at > org.apache.cxf.dosgi.topologymanager.RemoteServiceAdminList.removeRemoteServiceAdmin(RemoteServiceAdminList.java:83) > at > org.apache.cxf.dosgi.topologymanager.RemoteServiceAdminList$1.removedService(RemoteServiceAdminList.java:68) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:922) > at > org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:351) > at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:403) > at > org.apache.cxf.dosgi.topologymanager.RemoteServiceAdminList.stop(RemoteServiceAdminList.java:99) > at > org.apache.cxf.dosgi.topologymanager.Activator.stop(Activator.java:83) > at > org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:651) > at org.apache.felix.framework.Felix.stopBundle(Felix.java:2216) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1192) > at > org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) > at java.lang.Thread.run(Thread.java:679) > The Utils.getEndpointListeners method returns null, causing problems in the > for-each below. -- 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
[jira] [Assigned] (DOSGI-109) NullPointerException in ToloplogyManager during bundle stop
[ https://issues.apache.org/jira/browse/DOSGI-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned DOSGI-109: - Assignee: Christian Schneider > NullPointerException in ToloplogyManager during bundle stop > --- > > Key: DOSGI-109 > URL: https://issues.apache.org/jira/browse/DOSGI-109 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Bert Jacobs >Assignee: Christian Schneider > > When I stop the topologymanager, the following exception pops up: > java.lang.NullPointerException > at > org.apache.cxf.dosgi.topologymanager.TopologyManager.removeRemoteServiceAdmin(TopologyManager.java:139) > at > org.apache.cxf.dosgi.topologymanager.RemoteServiceAdminList.removeRemoteServiceAdmin(RemoteServiceAdminList.java:83) > at > org.apache.cxf.dosgi.topologymanager.RemoteServiceAdminList$1.removedService(RemoteServiceAdminList.java:68) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:922) > at > org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:351) > at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:403) > at > org.apache.cxf.dosgi.topologymanager.RemoteServiceAdminList.stop(RemoteServiceAdminList.java:99) > at > org.apache.cxf.dosgi.topologymanager.Activator.stop(Activator.java:83) > at > org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:651) > at org.apache.felix.framework.Felix.stopBundle(Felix.java:2216) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1192) > at > org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) > at java.lang.Thread.run(Thread.java:679) > The Utils.getEndpointListeners method returns null, causing problems in the > for-each below. -- 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
[jira] [Assigned] (DOSGI-123) ZooKeeper registrations are not recreated on ZooKeeper server restart
[ https://issues.apache.org/jira/browse/DOSGI-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned DOSGI-123: - Assignee: Christian Schneider > ZooKeeper registrations are not recreated on ZooKeeper server restart > - > > Key: DOSGI-123 > URL: https://issues.apache.org/jira/browse/DOSGI-123 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: Discovery >Affects Versions: 1.3.1 >Reporter: David Bosschaert >Assignee: Christian Schneider > > Remote service registrations with ZooKeeper are lost when the ZooKeeper > server dies. If the ZooKeeper server is restarted these registrations should > be recreated. > To reproduce: > 1. Start the zookeeper server > 2. Register a remote client > 3. Run a client to verify that it works > 4. Stop the zookeeper server > 5. Start the remote client again > 6. Start the zookeeper server > At this point the client is not notified of the remote service. Steps 5 and 6 > can also be reversed. -- 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
[jira] [Updated] (DOSGI-123) ZooKeeper registrations are not recreated on ZooKeeper server restart
[ https://issues.apache.org/jira/browse/DOSGI-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated DOSGI-123: -- Fix Version/s: 1.4 > ZooKeeper registrations are not recreated on ZooKeeper server restart > - > > Key: DOSGI-123 > URL: https://issues.apache.org/jira/browse/DOSGI-123 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: Discovery >Affects Versions: 1.3.1 >Reporter: David Bosschaert >Assignee: Christian Schneider > Fix For: 1.4 > > > Remote service registrations with ZooKeeper are lost when the ZooKeeper > server dies. If the ZooKeeper server is restarted these registrations should > be recreated. > To reproduce: > 1. Start the zookeeper server > 2. Register a remote client > 3. Run a client to verify that it works > 4. Stop the zookeeper server > 5. Start the remote client again > 6. Start the zookeeper server > At this point the client is not notified of the remote service. Steps 5 and 6 > can also be reversed. -- 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
[jira] [Assigned] (DOSGI-70) Reconnect automatically to Zookeeper after a connection loss / timeout
[ https://issues.apache.org/jira/browse/DOSGI-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned DOSGI-70: Assignee: Christian Schneider > Reconnect automatically to Zookeeper after a connection loss / timeout > -- > > Key: DOSGI-70 > URL: https://issues.apache.org/jira/browse/DOSGI-70 > Project: CXF Distributed OSGi > Issue Type: Improvement > Components: Discovery >Affects Versions: 1.0, 1.1, 1.2 >Reporter: Julien Vey >Assignee: Christian Schneider > Fix For: 1.4 > > Attachments: cxf-dosgi-ri-discovery-distributed.patch > > > When a remote service is disconnected from the ZooKeeper Server and when the > session is expired, it should be able to try to reconnect automatically. > Here the discussion on the mailing list : > http://old.nabble.com/DOSGI-Discovery-with-Zookeeper%2C-re-establish-session-after-a-timeout-tt28305408.html > > Some links to zookeeper about this matter > http://wiki.apache.org/hadoop/ZooKeeper/FAQ#A3 > http://hadoop.apache.org/zookeeper/docs/current/zookeeperProgrammers.html#ch_zkSessions -- 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
[jira] [Updated] (DOSGI-70) Reconnect automatically to Zookeeper after a connection loss / timeout
[ https://issues.apache.org/jira/browse/DOSGI-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated DOSGI-70: - Fix Version/s: 1.4 > Reconnect automatically to Zookeeper after a connection loss / timeout > -- > > Key: DOSGI-70 > URL: https://issues.apache.org/jira/browse/DOSGI-70 > Project: CXF Distributed OSGi > Issue Type: Improvement > Components: Discovery >Affects Versions: 1.0, 1.1, 1.2 >Reporter: Julien Vey >Assignee: Christian Schneider > Fix For: 1.4 > > Attachments: cxf-dosgi-ri-discovery-distributed.patch > > > When a remote service is disconnected from the ZooKeeper Server and when the > session is expired, it should be able to try to reconnect automatically. > Here the discussion on the mailing list : > http://old.nabble.com/DOSGI-Discovery-with-Zookeeper%2C-re-establish-session-after-a-timeout-tt28305408.html > > Some links to zookeeper about this matter > http://wiki.apache.org/hadoop/ZooKeeper/FAQ#A3 > http://hadoop.apache.org/zookeeper/docs/current/zookeeperProgrammers.html#ch_zkSessions -- 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
[jira] [Resolved] (DOSGI-120) NullPointerException on export
[
https://issues.apache.org/jira/browse/DOSGI-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved DOSGI-120.
---
Resolution: Fixed
Fix Version/s: 1.4
*140496911/2/12 3:09 PM 1 cschneider DOSGI-120 Added a
safeguard vs to avoid NPE
Can you check if the NPE still occurs for you? I could not reproduce it after
the change.
> NullPointerException on export
> --
>
> Key: DOSGI-120
> URL: https://issues.apache.org/jira/browse/DOSGI-120
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: DSW
>Affects Versions: 1.3.1
>Reporter: Bert Jacobs
>Priority: Minor
> Fix For: 1.4
>
>
> When I unregister and register a service to export it, then this exception
> popped up:
> {code}
> Exception in thread "pool-1-thread-3" java.lang.NullPointerException
> at
> org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.isCreatedByThisRSA(RemoteServiceAdminCore.java:299)
> at
> org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportService(RemoteServiceAdminCore.java:115)
> at
> org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:72)
> at
> org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:66)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:66)
> at
> org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:38)
> at
> org.apache.cxf.dosgi.topologymanager.TopologyManager$2.run(TopologyManager.java:267)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}
> Eventually my service got deployed, but it is annoying that exceptions like
> these fill the logs.
--
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
[jira] [Assigned] (DOSGI-113) Integration with pax-logging not possible
[ https://issues.apache.org/jira/browse/DOSGI-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned DOSGI-113: - Assignee: Christian Schneider > Integration with pax-logging not possible > - > > Key: DOSGI-113 > URL: https://issues.apache.org/jira/browse/DOSGI-113 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: Product >Affects Versions: 1.3 > Environment: Felix and Eclipse >Reporter: Sven Viehmeier >Assignee: Christian Schneider >Priority: Minor > Labels: logging > Fix For: 1.4 > > > I tried to integrate Apache CXF 1.2 and 1.3 with pax-logging. It failed with > both versions: > - Apache CXF 1.2: pax-logging does not export package "org.apache.log4j.jmx". > So as long as this package is needed by CXF, this would be an issue of > pax-logging > - Apache CXF 1.3: Dependencies could all be resolved and pax-logging > integrates fine with my own code (which uses Log4j as the API), but the > logging messages from CXF still appear on the console and not where I > configured it. I also tried to switch CXF to use Log4j instead of SLF4J, but > it seems that the system property "org.apache.cxf.Logger" is not respected. > Please see the users mailing list with the topic "Configure logging in CXF + > pax-web + Jetty" > ([http://mail-archives.apache.org/mod_mbox/cxf-users/201202.mbox/%3c4f3b8181.9080...@gmail.com%3E]) > for more 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
[jira] [Resolved] (DOSGI-113) Integration with pax-logging not possible
[ https://issues.apache.org/jira/browse/DOSGI-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-113. --- Resolution: Fixed Fix Version/s: 1.4 This should work now. Please reopen if you still have issues > Integration with pax-logging not possible > - > > Key: DOSGI-113 > URL: https://issues.apache.org/jira/browse/DOSGI-113 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: Product >Affects Versions: 1.3 > Environment: Felix and Eclipse >Reporter: Sven Viehmeier >Assignee: Christian Schneider >Priority: Minor > Labels: logging > Fix For: 1.4 > > > I tried to integrate Apache CXF 1.2 and 1.3 with pax-logging. It failed with > both versions: > - Apache CXF 1.2: pax-logging does not export package "org.apache.log4j.jmx". > So as long as this package is needed by CXF, this would be an issue of > pax-logging > - Apache CXF 1.3: Dependencies could all be resolved and pax-logging > integrates fine with my own code (which uses Log4j as the API), but the > logging messages from CXF still appear on the console and not where I > configured it. I also tried to switch CXF to use Log4j instead of SLF4J, but > it seems that the system property "org.apache.cxf.Logger" is not respected. > Please see the users mailing list with the topic "Configure logging in CXF + > pax-web + Jetty" > ([http://mail-archives.apache.org/mod_mbox/cxf-users/201202.mbox/%3c4f3b8181.9080...@gmail.com%3E]) > for more 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
[jira] [Created] (DOSGI-138) Refactoring of discovery distributed
Christian Schneider created DOSGI-138: - Summary: Refactoring of discovery distributed Key: DOSGI-138 URL: https://issues.apache.org/jira/browse/DOSGI-138 Project: CXF Distributed OSGi Issue Type: Improvement Components: Discovery Affects Versions: 1.3.1 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 1.4 The discovery impl currently has a lot of dependency cycles and is quite difficult to understand. I prepared a refactoring that removes the cycles and should make the code a lot more readable. -- 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
[jira] [Updated] (DOSGI-138) Refactoring of discovery distributed
[ https://issues.apache.org/jira/browse/DOSGI-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated DOSGI-138: -- Attachment: org.apache.cxf.dosgi.topologymanager-after.png org.apache.cxf.dosgi.discovery.zookeeper-1.3.1.png Added structure 101 diagrams of the code dependencies before and after the change > Refactoring of discovery distributed > > > Key: DOSGI-138 > URL: https://issues.apache.org/jira/browse/DOSGI-138 > Project: CXF Distributed OSGi > Issue Type: Improvement > Components: Discovery >Affects Versions: 1.3.1 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 1.4 > > Attachments: org.apache.cxf.dosgi.discovery.zookeeper-1.3.1.png, > org.apache.cxf.dosgi.discovery.zookeeper_after.png > > > The discovery impl currently has a lot of dependency cycles and is quite > difficult to understand. > I prepared a refactoring that removes the cycles and should make the code a > lot more readable. -- 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
[jira] [Updated] (DOSGI-138) Refactoring of discovery distributed
[ https://issues.apache.org/jira/browse/DOSGI-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated DOSGI-138: -- Attachment: org.apache.cxf.dosgi.discovery.zookeeper_after.png > Refactoring of discovery distributed > > > Key: DOSGI-138 > URL: https://issues.apache.org/jira/browse/DOSGI-138 > Project: CXF Distributed OSGi > Issue Type: Improvement > Components: Discovery >Affects Versions: 1.3.1 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 1.4 > > Attachments: org.apache.cxf.dosgi.discovery.zookeeper-1.3.1.png, > org.apache.cxf.dosgi.discovery.zookeeper_after.png > > > The discovery impl currently has a lot of dependency cycles and is quite > difficult to understand. > I prepared a refactoring that removes the cycles and should make the code a > lot more readable. -- 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
[jira] [Updated] (DOSGI-138) Refactoring of discovery distributed
[ https://issues.apache.org/jira/browse/DOSGI-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated DOSGI-138: -- Attachment: (was: org.apache.cxf.dosgi.topologymanager-after.png) > Refactoring of discovery distributed > > > Key: DOSGI-138 > URL: https://issues.apache.org/jira/browse/DOSGI-138 > Project: CXF Distributed OSGi > Issue Type: Improvement > Components: Discovery >Affects Versions: 1.3.1 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 1.4 > > Attachments: org.apache.cxf.dosgi.discovery.zookeeper-1.3.1.png, > org.apache.cxf.dosgi.discovery.zookeeper_after.png > > > The discovery impl currently has a lot of dependency cycles and is quite > difficult to understand. > I prepared a refactoring that removes the cycles and should make the code a > lot more readable. -- 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
[jira] [Resolved] (DOSGI-70) Reconnect automatically to Zookeeper after a connection loss / timeout
[ https://issues.apache.org/jira/browse/DOSGI-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-70. -- Resolution: Fixed I have not exactly applied the patch from Julien but used the idea of reacting in the expired event. I also removed the code that waits for the connect with a timeout. Instead I use the syncconnect event to fully start the discovery. Both seem to work really well. 1404989 02.11.2012 16:02:01, by cschneider DOSGI-138 DOSGI-123 DOSGI-70 Refactoring of discovery, added reconnect and republishing after connection loss to zookeeper M /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/Activator.java D /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/DataMonitorListener.java D /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/EndpointListenerFactory.java D /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/EndpointListenerImpl.java M /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/EndpointListenerTrackerCustomizer.java D /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/InterfaceDataMonitorListenerImpl.java M /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/InterfaceMonitor.java A /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/InterfaceMonitorManager.java A /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/PublishingEndpointListener.java A /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/PublishingEndpointListenerFactory.java And 9 more > Reconnect automatically to Zookeeper after a connection loss / timeout > -- > > Key: DOSGI-70 > URL: https://issues.apache.org/jira/browse/DOSGI-70 > Project: CXF Distributed OSGi > Issue Type: Improvement > Components: Discovery >Affects Versions: 1.0, 1.1, 1.2 >Reporter: Julien Vey >Assignee: Christian Schneider > Fix For: 1.4 > > Attachments: cxf-dosgi-ri-discovery-distributed.patch > > > When a remote service is disconnected from the ZooKeeper Server and when the > session is expired, it should be able to try to reconnect automatically. > Here the discussion on the mailing list : > http://old.nabble.com/DOSGI-Discovery-with-Zookeeper%2C-re-establish-session-after-a-timeout-tt28305408.html > > Some links to zookeeper about this matter > http://wiki.apache.org/hadoop/ZooKeeper/FAQ#A3 > http://hadoop.apache.org/zookeeper/docs/current/zookeeperProgrammers.html#ch_zkSessions -- 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
[jira] [Resolved] (DOSGI-138) Refactoring of discovery distributed
[ https://issues.apache.org/jira/browse/DOSGI-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-138. --- Resolution: Fixed Also fixed the two other issues named in the commit. 1404989 02.11.2012 16:02:01, by cschneider DOSGI-138 DOSGI-123 DOSGI-70 Refactoring of discovery, added reconnect and republishing after connection loss to zookeeper M /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/Activator.java D /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/DataMonitorListener.java D /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/EndpointListenerFactory.java D /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/EndpointListenerImpl.java M /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/EndpointListenerTrackerCustomizer.java D /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/InterfaceDataMonitorListenerImpl.java M /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/InterfaceMonitor.java A /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/InterfaceMonitorManager.java A /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/PublishingEndpointListener.java A /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/PublishingEndpointListenerFactory.java And 9 more > Refactoring of discovery distributed > > > Key: DOSGI-138 > URL: https://issues.apache.org/jira/browse/DOSGI-138 > Project: CXF Distributed OSGi > Issue Type: Improvement > Components: Discovery >Affects Versions: 1.3.1 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 1.4 > > Attachments: org.apache.cxf.dosgi.discovery.zookeeper-1.3.1.png, > org.apache.cxf.dosgi.discovery.zookeeper_after.png > > > The discovery impl currently has a lot of dependency cycles and is quite > difficult to understand. > I prepared a refactoring that removes the cycles and should make the code a > lot more readable. -- 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
[jira] [Resolved] (DOSGI-123) ZooKeeper registrations are not recreated on ZooKeeper server restart
[ https://issues.apache.org/jira/browse/DOSGI-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-123. --- Resolution: Fixed After my refactoring of discovery I found that restarting discovery or zookeeper was not really handled well. So I also fixed this issue in the refactoring issue. Can you retest your scenario? Zookeeper restarts should be handled fine now. 1404989 02.11.2012 16:02:01, by cschneider DOSGI-138 DOSGI-123 DOSGI-70 Refactoring of discovery, added reconnect and republishing after connection loss to zookeeper M /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/Activator.java D /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/DataMonitorListener.java D /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/EndpointListenerFactory.java D /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/EndpointListenerImpl.java M /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/EndpointListenerTrackerCustomizer.java D /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/InterfaceDataMonitorListenerImpl.java M /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/InterfaceMonitor.java A /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/InterfaceMonitorManager.java A /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/PublishingEndpointListener.java A /cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/PublishingEndpointListenerFactory.java And 9 more > ZooKeeper registrations are not recreated on ZooKeeper server restart > - > > Key: DOSGI-123 > URL: https://issues.apache.org/jira/browse/DOSGI-123 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: Discovery >Affects Versions: 1.3.1 >Reporter: David Bosschaert >Assignee: Christian Schneider > Fix For: 1.4 > > > Remote service registrations with ZooKeeper are lost when the ZooKeeper > server dies. If the ZooKeeper server is restarted these registrations should > be recreated. > To reproduce: > 1. Start the zookeeper server > 2. Register a remote client > 3. Run a client to verify that it works > 4. Stop the zookeeper server > 5. Start the remote client again > 6. Start the zookeeper server > At this point the client is not notified of the remote service. Steps 5 and 6 > can also be reversed. -- 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
[jira] [Commented] (DOSGI-123) ZooKeeper registrations are not recreated on ZooKeeper server restart
[ https://issues.apache.org/jira/browse/DOSGI-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489476#comment-13489476 ] David Bosschaert commented on DOSGI-123: Excellent! > ZooKeeper registrations are not recreated on ZooKeeper server restart > - > > Key: DOSGI-123 > URL: https://issues.apache.org/jira/browse/DOSGI-123 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: Discovery >Affects Versions: 1.3.1 >Reporter: David Bosschaert >Assignee: Christian Schneider > Fix For: 1.4 > > > Remote service registrations with ZooKeeper are lost when the ZooKeeper > server dies. If the ZooKeeper server is restarted these registrations should > be recreated. > To reproduce: > 1. Start the zookeeper server > 2. Register a remote client > 3. Run a client to verify that it works > 4. Stop the zookeeper server > 5. Start the remote client again > 6. Start the zookeeper server > At this point the client is not notified of the remote service. Steps 5 and 6 > can also be reversed. -- 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
[jira] [Updated] (DOSGI-114) RemoteServiceAdmin is not available warnings in DOSGi 1.3
[ https://issues.apache.org/jira/browse/DOSGI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated DOSGI-114: -- Fix Version/s: 1.4 > RemoteServiceAdmin is not available warnings in DOSGi 1.3 > - > > Key: DOSGI-114 > URL: https://issues.apache.org/jira/browse/DOSGI-114 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: DSW >Affects Versions: 1.3 >Reporter: Sergey Beryozkin >Assignee: Christian Schneider > Fix For: 1.4, 1.3.2 > > > Some users have reported that the RemoteServiceAdmin is not available in 1.3, > example: > "SEVERE: No RemoteServiceAdmin available! Unable to export service from > bundle cxf-dosgi-ri-samples-greeter-rest-impl" > Needs to be confirmed with the existing demos -- 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
[jira] [Commented] (DOSGI-114) RemoteServiceAdmin is not available warnings in DOSGi 1.3
[ https://issues.apache.org/jira/browse/DOSGI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489489#comment-13489489 ] Christian Schneider commented on DOSGI-114: --- Can you retest with trunk. I think I have removed the warning as it is absolutely fine that the RSA is installed after the TopologyManager. When it is installed later the endpoints should be exported. > RemoteServiceAdmin is not available warnings in DOSGi 1.3 > - > > Key: DOSGI-114 > URL: https://issues.apache.org/jira/browse/DOSGI-114 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: DSW >Affects Versions: 1.3 >Reporter: Sergey Beryozkin > Fix For: 1.4, 1.3.2 > > > Some users have reported that the RemoteServiceAdmin is not available in 1.3, > example: > "SEVERE: No RemoteServiceAdmin available! Unable to export service from > bundle cxf-dosgi-ri-samples-greeter-rest-impl" > Needs to be confirmed with the existing demos -- 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
[jira] [Assigned] (DOSGI-114) RemoteServiceAdmin is not available warnings in DOSGi 1.3
[ https://issues.apache.org/jira/browse/DOSGI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned DOSGI-114: - Assignee: Christian Schneider > RemoteServiceAdmin is not available warnings in DOSGi 1.3 > - > > Key: DOSGI-114 > URL: https://issues.apache.org/jira/browse/DOSGI-114 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: DSW >Affects Versions: 1.3 >Reporter: Sergey Beryozkin >Assignee: Christian Schneider > Fix For: 1.4, 1.3.2 > > > Some users have reported that the RemoteServiceAdmin is not available in 1.3, > example: > "SEVERE: No RemoteServiceAdmin available! Unable to export service from > bundle cxf-dosgi-ri-samples-greeter-rest-impl" > Needs to be confirmed with the existing demos -- 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
[jira] [Commented] (FEDIZ-2) Support encrypted tokens in plugin
[ https://issues.apache.org/jira/browse/FEDIZ-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489509#comment-13489509 ] Colm O hEigeartaigh commented on FEDIZ-2: - Hi Oli, Could you update the description with a bit more information on this task? Colm. > Support encrypted tokens in plugin > -- > > Key: FEDIZ-2 > URL: https://issues.apache.org/jira/browse/FEDIZ-2 > Project: CXF-Fediz > Issue Type: New Feature > Components: IDP, Plugin >Reporter: Oliver Wulff >Assignee: Colm O hEigeartaigh > -- 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
[jira] [Assigned] (FEDIZ-2) Support encrypted tokens in plugin
[ https://issues.apache.org/jira/browse/FEDIZ-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned FEDIZ-2: --- Assignee: Colm O hEigeartaigh > Support encrypted tokens in plugin > -- > > Key: FEDIZ-2 > URL: https://issues.apache.org/jira/browse/FEDIZ-2 > Project: CXF-Fediz > Issue Type: New Feature > Components: IDP, Plugin >Reporter: Oliver Wulff >Assignee: Colm O hEigeartaigh > -- 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
[jira] [Assigned] (FEDIZ-14) Make the TokenReplayCache implementation configurable in the Fediz configuration
[ https://issues.apache.org/jira/browse/FEDIZ-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned FEDIZ-14: Assignee: Colm O hEigeartaigh > Make the TokenReplayCache implementation configurable in the Fediz > configuration > > > Key: FEDIZ-14 > URL: https://issues.apache.org/jira/browse/FEDIZ-14 > Project: CXF-Fediz > Issue Type: Improvement > Components: Plugin >Affects Versions: 1.0.0 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > > This task is to make the TokenReplayCache implementation configurable in the > Fediz configuration. Currently the EhCacheTokenReplayCache implementation is > used by default. -- 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
[jira] [Assigned] (FEDIZ-4) Support SAML token with Holder-Of-Key SubjectConfirmationMethod
[ https://issues.apache.org/jira/browse/FEDIZ-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned FEDIZ-4: --- Assignee: Colm O hEigeartaigh > Support SAML token with Holder-Of-Key SubjectConfirmationMethod > --- > > Key: FEDIZ-4 > URL: https://issues.apache.org/jira/browse/FEDIZ-4 > Project: CXF-Fediz > Issue Type: New Feature > Components: IDP, Plugin >Reporter: Oliver Wulff >Assignee: Colm O hEigeartaigh > -- 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
[jira] [Assigned] (FEDIZ-7) Add support for SAML-P
[ https://issues.apache.org/jira/browse/FEDIZ-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned FEDIZ-7: --- Assignee: Colm O hEigeartaigh > Add support for SAML-P > -- > > Key: FEDIZ-7 > URL: https://issues.apache.org/jira/browse/FEDIZ-7 > Project: CXF-Fediz > Issue Type: New Feature >Reporter: Oliver Wulff >Assignee: Colm O hEigeartaigh > -- 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
[jira] [Created] (FEDIZ-31) Fix example package structure
Colm O hEigeartaigh created FEDIZ-31: Summary: Fix example package structure Key: FEDIZ-31 URL: https://issues.apache.org/jira/browse/FEDIZ-31 Project: CXF-Fediz Issue Type: Improvement Affects Versions: 1.0.1 Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Priority: Trivial Fix For: 1.1.0 This task is to fix the example package structure. For example, the groupId of "org.apache.cxf.fediz.examples.wsclientWebapp" should not have the name of the example there. This creates a "org/apache/cxf/fediz/examples/wsclientWebapp/wsclientWebapp/1.0.2/" module. -- 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
[jira] [Updated] (FEDIZ-7) Add support for SAML-P in the plugin
[ https://issues.apache.org/jira/browse/FEDIZ-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated FEDIZ-7: Component/s: Plugin Description: This task is to add support for SAML-P in the plugin. The user should be able to configure either WS-Federation or SAML-P. Fix Version/s: 1.1.0 Summary: Add support for SAML-P in the plugin (was: Add support for SAML-P) > Add support for SAML-P in the plugin > > > Key: FEDIZ-7 > URL: https://issues.apache.org/jira/browse/FEDIZ-7 > Project: CXF-Fediz > Issue Type: New Feature > Components: Plugin >Reporter: Oliver Wulff >Assignee: Colm O hEigeartaigh > Fix For: 1.1.0 > > > This task is to add support for SAML-P in the plugin. The user should be able > to configure either WS-Federation or SAML-P. -- 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
[jira] [Commented] (CXF-4552) typical HTML form payload does not seem to work when HTML form is used
[
https://issues.apache.org/jira/browse/CXF-4552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489533#comment-13489533
]
Miten Mehta commented on CXF-4552:
--
Hi Sergey,
Thanks for patch. Please update documentation with two liner example !
Regards,
Miten.
> typical HTML form payload does not seem to work when HTML form is used
> --
>
> Key: CXF-4552
> URL: https://issues.apache.org/jira/browse/CXF-4552
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.5.2
> Environment: mitenm@pinkydebian:~$ uname -a; java -version
> Linux pinkydebian 2.6.32-5-686 #1 SMP Sun May 6 04:01:19 UTC 2012 i686
> GNU/Linux
> java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) Client VM (build 23.0-b21, mixed mode)
> mitenm@pinkydebian:~$
>Reporter: Miten Mehta
>Assignee: Sergey Beryozkin
> Fix For: 2.5.6, 2.6.3, 2.7.1
>
>
> I am using HTML form below to upload files using jax-rs but the attachments
> parameter is null.
> The code and error are shown:
> form:
>
>
>
>
>
> enctype="multipart/form-data"
>method="post">
>
>What is your name?
>What files are you sending?
>
>
>
>
>
> code:
> package demo.jaxrs.server;
> import java.io.BufferedReader;
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.InputStreamReader;
> import java.util.List;
> import javax.ws.rs.Consumes;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
> import javax.ws.rs.core.Response;
> import org.apache.cxf.jaxrs.ext.multipart.Multipart;
> import org.apache.cxf.message.Attachment;
> @Path("/files/")
> public class MultipartService {
>
> @Path("/upload")
> @Consumes("multipart/form-data")
> @Produces("text/html")
> @POST
> public Response addAttachments(@Multipart("submit-name") String
> submitName,
> @Multipart("files") List files) {
>
> System.out.println(submitName);
> System.out.println(files);
> for(Attachment a:files) {
> System.out.println(a.getId());
> InputStream is;
> try {
> is = a.getDataHandler().getInputStream();
> BufferedReader r = new BufferedReader(new
> InputStreamReader(is));
> System.out.println(r.readLine());
> } catch (IOException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> }
>
> return Response.ok("Files
> Saved").type("text/html").build();
> }
> }
> beans.xml:
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:jaxrs="http://cxf.apache.org/jaxrs";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/jaxrs.xsd";>
>
>
>
>class="org.apache.cxf.interceptor.LoggingInInterceptor"/>
>
>
>
>
>
>
>
>
>
>
>
> error log:
> 17:10:58 INFO context.ContextLoader - Root WebApplicationContext:
> initialization completed in 1422 ms
> 17:10:58 DEBUG support.DefaultListableBeanFactory - Returning cached instance
> of singleton bean 'cxf'
> Oct 09, 2012 5:02:09 PM org.apache.cxf.interceptor.LoggingInInterceptor
> INFO: Inbound Message
>
> ID: 1
> Address: http://pinkydebian:8080/jax_rs_basic/cxf/files/upload
> Encoding: ISO-8859-1
> Http-Method: POST
> Content-Type: multipart/form-data;
> boundary=---222852432428027
> Headers:
> {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8],
> accept-encoding=[gzip, deflate], accept-language=[en-us,en;q=0.5],
> connection=[keep-alive], Content-Length=[469],
> content-type=[multipart/form-data;
> boundary=---222852432428027],
> host=[pinkydebian:8080],
> referer=[http://pinkydebian:8080/jax_rs_basic/multipart.html],
> user-agent=[Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101
> Firefox/15.0.1]}
> Payload: -222852432428027
> Content-Disposition: form-data; name="submit-name"
> Miten
> -222852432428027
> Content-Disposition: form-data; name="files"; filename="kingfisher.txt"
> Content-Type: text/plain
> Service Temporarily Unavailable
> The server
[jira] [Commented] (CXF-4552) typical HTML form payload does not seem to work when HTML form is used
[
https://issues.apache.org/jira/browse/CXF-4552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489565#comment-13489565
]
Sergey Beryozkin commented on CXF-4552:
---
Nothing changes at the code level, what will happen now that is irrespectively
of how multipart/form-data payload containing multiple files is structured
(exactly as in HTMLForm document or with every file part having the same name
such as "files"), this code which is already on the wiki will work:
{code:java}
POST
public void upload(@Multipart("name") String name, @Multipart("files")
List files) {...}
{code}
As a side note, please review
http://cxf.apache.org/docs/jax-rs-redirection.html#JAX-RSRedirection-WithRequestDispatcherProvider
(check the info re enums)
> typical HTML form payload does not seem to work when HTML form is used
> --
>
> Key: CXF-4552
> URL: https://issues.apache.org/jira/browse/CXF-4552
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.5.2
> Environment: mitenm@pinkydebian:~$ uname -a; java -version
> Linux pinkydebian 2.6.32-5-686 #1 SMP Sun May 6 04:01:19 UTC 2012 i686
> GNU/Linux
> java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) Client VM (build 23.0-b21, mixed mode)
> mitenm@pinkydebian:~$
>Reporter: Miten Mehta
>Assignee: Sergey Beryozkin
> Fix For: 2.5.6, 2.6.3, 2.7.1
>
>
> I am using HTML form below to upload files using jax-rs but the attachments
> parameter is null.
> The code and error are shown:
> form:
>
>
>
>
>
> enctype="multipart/form-data"
>method="post">
>
>What is your name?
>What files are you sending?
>
>
>
>
>
> code:
> package demo.jaxrs.server;
> import java.io.BufferedReader;
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.InputStreamReader;
> import java.util.List;
> import javax.ws.rs.Consumes;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
> import javax.ws.rs.core.Response;
> import org.apache.cxf.jaxrs.ext.multipart.Multipart;
> import org.apache.cxf.message.Attachment;
> @Path("/files/")
> public class MultipartService {
>
> @Path("/upload")
> @Consumes("multipart/form-data")
> @Produces("text/html")
> @POST
> public Response addAttachments(@Multipart("submit-name") String
> submitName,
> @Multipart("files") List files) {
>
> System.out.println(submitName);
> System.out.println(files);
> for(Attachment a:files) {
> System.out.println(a.getId());
> InputStream is;
> try {
> is = a.getDataHandler().getInputStream();
> BufferedReader r = new BufferedReader(new
> InputStreamReader(is));
> System.out.println(r.readLine());
> } catch (IOException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> }
>
> return Response.ok("Files
> Saved").type("text/html").build();
> }
> }
> beans.xml:
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:jaxrs="http://cxf.apache.org/jaxrs";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/jaxrs.xsd";>
>
>
>
>class="org.apache.cxf.interceptor.LoggingInInterceptor"/>
>
>
>
>
>
>
>
>
>
>
>
> error log:
> 17:10:58 INFO context.ContextLoader - Root WebApplicationContext:
> initialization completed in 1422 ms
> 17:10:58 DEBUG support.DefaultListableBeanFactory - Returning cached instance
> of singleton bean 'cxf'
> Oct 09, 2012 5:02:09 PM org.apache.cxf.interceptor.LoggingInInterceptor
> INFO: Inbound Message
>
> ID: 1
> Address: http://pinkydebian:8080/jax_rs_basic/cxf/files/upload
> Encoding: ISO-8859-1
> Http-Method: POST
> Content-Type: multipart/form-data;
> boundary=---222852432428027
> Headers:
> {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8],
> accept-encoding=[gzip, deflate], accept-language=[en-us,en;q=0.5],
> connection=[keep-alive], Content-Length=[469],
> content-type=[multipart/form-data;
> boundary=---222852432428027],
> host=
[jira] [Created] (CXF-4609) Comparison problem in ImplicitGrantService.java
Steven Tippetts created CXF-4609:
Summary: Comparison problem in ImplicitGrantService.java
Key: CXF-4609
URL: https://issues.apache.org/jira/browse/CXF-4609
Project: CXF
Issue Type: Bug
Components: JAX-RS Security
Affects Versions: 2.6.2
Reporter: Steven Tippetts
Priority: Critical
On line 59 of ImplicitGrantService.java the following:
if (preAuthorizedToken != null) {
needs to be changed to:
if (preAuthorizedToken == null) {
--
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
[jira] [Updated] (CXF-4609) Comparison problem in ImplicitGrantService.java
[
https://issues.apache.org/jira/browse/CXF-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Tippetts updated CXF-4609:
-
Affects Version/s: 2.7.0
> Comparison problem in ImplicitGrantService.java
> ---
>
> Key: CXF-4609
> URL: https://issues.apache.org/jira/browse/CXF-4609
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS Security
>Affects Versions: 2.6.2, 2.7.0
>Reporter: Steven Tippetts
>Priority: Critical
>
> On line 59 of ImplicitGrantService.java the following:
> if (preAuthorizedToken != null) {
> needs to be changed to:
> if (preAuthorizedToken == null) {
--
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
[jira] [Resolved] (CXF-4605) SortedMap is not returned when another unrelated method exists in the interface
[
https://issues.apache.org/jira/browse/CXF-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-4605.
--
Resolution: Fixed
Fix Version/s: 2.7.1
Assignee: Daniel Kulp
This changes the generated schema a bit so likely not going to merge back
> SortedMap is not returned when another unrelated method exists in the
> interface
> ---
>
> Key: CXF-4605
> URL: https://issues.apache.org/jira/browse/CXF-4605
> Project: CXF
> Issue Type: Bug
> Components: Aegis Databinding
>Affects Versions: 2.7.0
> Environment: Debian unstable / tomcat7 / opennjdk7
>Reporter: Vassilis Virvilis
>Assignee: Daniel Kulp
> Fix For: 2.7.1
>
> Attachments: ws-test-issue-4605.tgz
>
>
> During testing of bug 4534 I stumbled upon the following behavior. Subsets
> of tests were passing when run standalone but failing when run in the full
> test suite.
> So I have narrowed it down to one method that fails when another is
> uncommented in the interface.
> Interface:
> // uncomment this for the next method to fail
> // public Map> testDirectComplexMapResult();
> // fail -- puts data into a hashmap instead of a SortedMap if the above
> is uncommented
> public Map>
> testDirectComplexTreeMapResult();
> Implementation:
> //@Override
> public Map> testDirectComplexMapResult() {
> final Map> result = new HashMap Map>();
> final TreeMap map1 = new TreeMap Integer>();
> map1.put(1, 3);
> result.put("key1", map1);
> return result;
> }
> @Override
> public Map>
> testDirectComplexTreeMapResult() {
> final Map> result = new
> HashMap>();
> final TreeMap map1 = new TreeMap Integer>();
> map1.put(1, 3);
> map1.put(0, 2);
> result.put("key1", map1);
> return result;
> }
> Client:
> @Test
> public void testDirectComplexTreeMapResult() {
> final Map map = TestServiceFactory.getService()
> .testDirectComplexTreeMapResult();
> log.info(map);
> for (final Object vmap : map.values()) {
> Assert.assertTrue(vmap instanceof SortedMap);
> }
> }
--
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
