Re: SeachConditionBuilder for CXF JAX-RS clients
Removing Nabble links... On Wed, Mar 9, 2011 at 10:40 AM, Sergey Beryozkin sberyoz...@gmail.comwrote: Hi Andy On Tue, Mar 8, 2011 at 9:58 PM, Andrzej Michalec andrzej.micha...@gmail.com wrote: sorry, I'm not following :-) We have PrimitiveSearchCondition which wraps an expression like a==2. [...] I spent an hour trying to recreate that problem and actually I confused myself because I am not able to do so :) When I started working on search condition builder I did a little play with FiqlParser and SimpleSearchCondition and found problems I described. I was sure I did update to head revision. Anyway, then I trashed these files as irrelevant to our fluent interface case, but I remembered in back of my head troubles I reached and tested. Now I have neither idea nor time to figure that out especially that it is really working! I think it is your refactoring to PrimitiveSearchCondition that get rid of problem I faced. Well... feeling shamed a bit I am happy at the same time that the code is really stable. Not a problem at all and the really good thing is that you've looked again through the code you wrote awhile back and thus enhancing it can be a walk in the park for you in the future :-). Thanks for taking care of this issue - you may've spotted something after all and if yes then the issue will be back on the agenda soon :-) I am going to revert these changes in minutes and then tune up SearchConditionBuilder as we agreed. cool, thanks Sergey cheers, -andy.
Re: CXF OSGI application and HTTP transport
Hi David On Wed, Mar 9, 2011 at 11:53 AM, David Bosschaert david.bosscha...@gmail.com wrote: Hi Sergey, Not sure I understand your email 100% (maybe I should spend more time reading it ;) but just to make sure, the component you're proposing to remove is not related to DOSGi, correct? DOSGi als uses a HTTP transport, but that's is not the one you're suggesting to remove... No, DOSGi RI does not use it and I basically propose (though I didn't get to that in detail) for the CXF HttpTransport to do what DOSGi RI does with respect to creating contexts, per-endpoint, dynamically...At the moment I'm not sure how viable this approach is in the context of the CXF bundle being loaded outside of DOSGIi but at least we can discuss it a bit and may be something will come out of it... Actually this reminded me of the fact I had to exclude the HTTP Osgi transport from the CXF JAX-RS bundle because it was causing problems for users loading the bundle in the SpringDM server... Cheers, Sergey Cheers, David On 9 March 2011 11:26, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi I'd like to discuss a bit the possibility of making the CXF HTTP-OSGI transport redundant. Not sure if it's a good idea but I'd like to give it a chance :-) by discussing it on this list. The reason I'm concerned about CXF HTTP-OSGI transport is that it effectively takes the role of the CXF OSGI application. At the moment it's a Spring DM application and may get updated to become a Blueprint one. CXF is bigger than its HTTP transport but we're limited only to its HTTP transport registering itself as the Servlet. The other thing which concerns me is its static nature to do with hard-coding the context name and the names of the properties it may support. Having a single context within a given container instance is a limitation, not a big one, but it is nonetheless. And hardcoding the names of the properties is not good at all because OSGI gives us a ManagedService interface. Finally we are just totally out of control here and just depend on the external injection. I hope we can find a way to break this dependency. It was really needed at a time but IMHO it limits the way CXF as a whole can play in OSGI. If we look at DOSGi, one of the reasons it is interesting to developers is that it effectively makes CXF JAX-WS and JAX-RS runtimes taking more active roles in the process. DOSGi provides callbacks for these components to wrap the registered/looked-up interfaces. Yet alternative way is to have individual Activators check a given bundle for the presence of say JAX-RS Application or may be JAX-WS @WebService interface and react. I'm wondering if the idea of introducing a top-level Activator (at the distribution level) delegating to module-specific Activators works or not. At the moment it seems like it can. HTTP, JAX-WS, JAX-RS/etc Activators can do whatever they need to and also expose the properties which can be dynamically updated... My only concern is how to synchronize the whole process and the idea of say HTTP Transport registering itself as some OSGI service (discussed in the other thread) can be a perfect solution. If it all can work then we will end up having a real CXF OSGI application, very flexible and advanced, it will be a different level really... Of course that could be a bad idea - there could be constraints there which basically make it not-workable... Cheers, Sergey
Re: CXF OSGI application and HTTP transport
Hi Sergey, I am currently starting to work on https://issues.apache.org/jira/browse/CXF-3384 which also depends on unifying the servlet an osgi http transports. Currently the code has some subtle differences mostly in the servletcontroller. I am trying to use the same code and see if the tests still work. Then we could try to remove any special osgi code for http. The only thing that would remain are the two spring contexts. As I am also not sure if these contexts are a good way to setup CXF in OSGi I would be very interested in your thoughts about this. Perhaps we can work on a better design. I am sure David could help a lot as he did a quite different aproach in DOSGi. Christian Am 09.03.2011 12:26, schrieb Sergey Beryozkin: Hi I'd like to discuss a bit the possibility of making the CXF HTTP-OSGI transport redundant. Not sure if it's a good idea but I'd like to give it a chance :-) by discussing it on this list. The reason I'm concerned about CXF HTTP-OSGI transport is that it effectively takes the role of the CXF OSGI application. At the moment it's a Spring DM application and may get updated to become a Blueprint one. CXF is bigger than its HTTP transport but we're limited only to its HTTP transport registering itself as the Servlet. The other thing which concerns me is its static nature to do with hard-coding the context name and the names of the properties it may support. Having a single context within a given container instance is a limitation, not a big one, but it is nonetheless. And hardcoding the names of the properties is not good at all because OSGI gives us a ManagedService interface. Finally we are just totally out of control here and just depend on the external injection. I hope we can find a way to break this dependency. It was really needed at a time but IMHO it limits the way CXF as a whole can play in OSGI. If we look at DOSGi, one of the reasons it is interesting to developers is that it effectively makes CXF JAX-WS and JAX-RS runtimes taking more active roles in the process. DOSGi provides callbacks for these components to wrap the registered/looked-up interfaces. Yet alternative way is to have individual Activators check a given bundle for the presence of say JAX-RS Application or may be JAX-WS @WebService interface and react. I'm wondering if the idea of introducing a top-level Activator (at the distribution level) delegating to module-specific Activators works or not. At the moment it seems like it can. HTTP, JAX-WS, JAX-RS/etc Activators can do whatever they need to and also expose the properties which can be dynamically updated... My only concern is how to synchronize the whole process and the idea of say HTTP Transport registering itself as some OSGI service (discussed in the other thread) can be a perfect solution. If it all can work then we will end up having a real CXF OSGI application, very flexible and advanced, it will be a different level really... Of course that could be a bad idea - there could be constraints there which basically make it not-workable... Cheers, Sergey -- http://www.liquid-reality.de
Re: LogBrowser project is on the trunk
Hi Tomasz I'm finishing some work for AtomPullServer be able to connect to the existing file logs, I saw you committing some relevant updates to the LogBrowser code too, thanks. I'll will experiment with the Filter dialog shortly. What I'd really appreciate if you could help me with the following, hope it will take just a fraction of your time: - Remove the Authentication/SignIn/SignOut related code/resources. We just don't have time now to deal with the authentication/security issues and we'd need to have another discussion later on about it. I believe you agreed to it too. - Explain a bit which code/script deals with processing the dates. I know you spent a lot of time on trying to reproduce the application exception, including testing it on Ubuntu, but I'd like to give it a try and see if I can spot something that causes the issue on my particular OS - if I can trace it to some bad Java or Firefox installation then I'll get relaxed :-)... Thanks, Sergey On Sun, Feb 27, 2011 at 6:20 PM, Sergey Beryozkin sberyoz...@gmail.comwrote: String text = columnDefinition.getContent(entry); in SelectableTable.setData is causing it, and it's only happening when the Date column is filled in, the Level and Message are fine. Looks like the code co0nverting the Atom/http-format date is brittle a bit cheers, Sergey On Sun, Feb 27, 2011 at 5:10 PM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi Tomasz I've spent some time and it is some sort of the asynchronous exception which when captured shows the Date of the log entry. It is thrown when the ViewerViewImpl.setEntries(ListEntry entries) is called. We'll track it down soon :-) Sergey On Sat, Feb 26, 2011 at 1:23 PM, Tomasz Oponowicz tomasz.oponow...@gmail.com wrote: Hi Sergey, On Fri, Feb 25, 2011 at 1:19 PM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi Tomasz I've rerun the demo. First of all, the changes you've made recently have definitely made it look much better, thanks. Unfortunately, I'm still hitting this GWT ApplicationException when refreshing the endpoint : Application Error Class$jcb 2011-02-25T11:46:55.078Z Can this message, particularly Class$jcb, help somehow to identify the problem ? It does look like it's a platform/browser specific issue, I'm on Ubuntu 9, Firefox 3.6.13, but it would be good to get rid of it somehow. Just tried Chrome and it showed the same error but with the Class$kbc - it's probably the some gwt proxy... Can you please point to the code in the logbrowser project where the response from the remote endpoint is processed ? I will investigate... I will install similar environment as a virtual machine - I hope I will reproduce this issue... Few more comments. I agree, the way Tasks and Endpoints are currently shown is nice. - Can you please consider having both ManageEndpoints and Filter links located under the Tasks ? And have Endpoints shown first, with the Tasks in the bottom of the pane ? Ultimately, the user just wants to see the list of endpoints. Creating/deleting the endpoints and applying filters is critical but I'd just prefer the Tasks not to feature as the main activity of the LogBrowser users... - Filter dialog can not be closed at the moment, after it has been opened... - Probably makes sense to rename Explore to Explorer given that the ManageEndpoints panel has the Back to Explorer link... More comments inline... - Authentication: I've noticed there's AuthenticationRequired annotation attached to some of the BootstrapStorage methods - we really need to remove this annotation and for now just pop-up a login window on the browser start-up. Users will be configuring the LogBrowser application as part of the real deployments. So what would be good is to write the GWT client code such that it only pops up a window when the initial GET returns 401 - can you use CXF WebClient there and do 'Response r = webClient.get()' and if r.getStatus() == 401 then pop-up a login dialog ? We can deal with this issue later, when we have more time, and then we'll also decide whether to support https in cases when the authentication is needed or may be do the UT profile, we'll see... According to your list of tasks please consider also fallowing tasks: Thanks for this analysis... - Removing Sign in feature; - Pros: - Simplify implementation; - Easy configuration for end user; - Every company has got their own internal user authentication system (LDAP, OpenID, internal SSO etc.); - Even if LogBrowser doesn't contain any user authentication system, it's still very easy to add integration with some authentication system: - Simply interceptor before request rich controller; - Apache directives (of course if user use Apache before Tomcat); - Cons: - I understand that feeds
Re: LogBrowser project is on the trunk
Forgot one thing, the GWT compiler generates this warning: [INFO][WARN] g:DecoratedTabPanel is deprecated. Use the g:TabLayoutPanel instead. this is just FYI, not critical at all, for now those 2 issues I described below are a priority... thanks, Sergey On Wed, Mar 9, 2011 at 1:28 PM, Sergey Beryozkin sberyoz...@gmail.comwrote: Hi Tomasz I'm finishing some work for AtomPullServer be able to connect to the existing file logs, I saw you committing some relevant updates to the LogBrowser code too, thanks. I'll will experiment with the Filter dialog shortly. What I'd really appreciate if you could help me with the following, hope it will take just a fraction of your time: - Remove the Authentication/SignIn/SignOut related code/resources. We just don't have time now to deal with the authentication/security issues and we'd need to have another discussion later on about it. I believe you agreed to it too. - Explain a bit which code/script deals with processing the dates. I know you spent a lot of time on trying to reproduce the application exception, including testing it on Ubuntu, but I'd like to give it a try and see if I can spot something that causes the issue on my particular OS - if I can trace it to some bad Java or Firefox installation then I'll get relaxed :-)... Thanks, Sergey On Sun, Feb 27, 2011 at 6:20 PM, Sergey Beryozkin sberyoz...@gmail.comwrote: String text = columnDefinition.getContent(entry); in SelectableTable.setData is causing it, and it's only happening when the Date column is filled in, the Level and Message are fine. Looks like the code co0nverting the Atom/http-format date is brittle a bit cheers, Sergey On Sun, Feb 27, 2011 at 5:10 PM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi Tomasz I've spent some time and it is some sort of the asynchronous exception which when captured shows the Date of the log entry. It is thrown when the ViewerViewImpl.setEntries(ListEntry entries) is called. We'll track it down soon :-) Sergey On Sat, Feb 26, 2011 at 1:23 PM, Tomasz Oponowicz tomasz.oponow...@gmail.com wrote: Hi Sergey, On Fri, Feb 25, 2011 at 1:19 PM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi Tomasz I've rerun the demo. First of all, the changes you've made recently have definitely made it look much better, thanks. Unfortunately, I'm still hitting this GWT ApplicationException when refreshing the endpoint : Application Error Class$jcb 2011-02-25T11:46:55.078Z Can this message, particularly Class$jcb, help somehow to identify the problem ? It does look like it's a platform/browser specific issue, I'm on Ubuntu 9, Firefox 3.6.13, but it would be good to get rid of it somehow. Just tried Chrome and it showed the same error but with the Class$kbc - it's probably the some gwt proxy... Can you please point to the code in the logbrowser project where the response from the remote endpoint is processed ? I will investigate... I will install similar environment as a virtual machine - I hope I will reproduce this issue... Few more comments. I agree, the way Tasks and Endpoints are currently shown is nice. - Can you please consider having both ManageEndpoints and Filter links located under the Tasks ? And have Endpoints shown first, with the Tasks in the bottom of the pane ? Ultimately, the user just wants to see the list of endpoints. Creating/deleting the endpoints and applying filters is critical but I'd just prefer the Tasks not to feature as the main activity of the LogBrowser users... - Filter dialog can not be closed at the moment, after it has been opened... - Probably makes sense to rename Explore to Explorer given that the ManageEndpoints panel has the Back to Explorer link... More comments inline... - Authentication: I've noticed there's AuthenticationRequired annotation attached to some of the BootstrapStorage methods - we really need to remove this annotation and for now just pop-up a login window on the browser start-up. Users will be configuring the LogBrowser application as part of the real deployments. So what would be good is to write the GWT client code such that it only pops up a window when the initial GET returns 401 - can you use CXF WebClient there and do 'Response r = webClient.get()' and if r.getStatus() == 401 then pop-up a login dialog ? We can deal with this issue later, when we have more time, and then we'll also decide whether to support https in cases when the authentication is needed or may be do the UT profile, we'll see... According to your list of tasks please consider also fallowing tasks: Thanks for this analysis... - Removing Sign in feature; - Pros: - Simplify implementation; - Easy configuration for end user; - Every company has got their own internal user authentication system (LDAP, OpenID,
Re: svn commit: r1079780 - in /cxf/trunk: api/src/main/java/org/apache/cxf/tools/common/ maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/ tools/wsdlto/core/src/main/java/org/apa
I think for a boolean argument like this, it would make a lot more sense to
not have it be a parameter thing. I personally think the ONLY time anyone
would use this would be with the false parameter, like -gt false. No one
would ever really use -gt true as that's the default.
Thus, my suggestion would be to change it to just:
option id=notypes maxOccurs=1
annotationTurns off generating types/annotation
switchnotypes/switch
/option
You can then just use the context.optionSet(...) method to see if the user
specified it or not.
Dan
On Wednesday 09 March 2011 7:54:16 AM ningji...@apache.org wrote:
Author: ningjiang
Date: Wed Mar 9 12:54:15 2011
New Revision: 1079780
URL: http://svn.apache.org/viewvc?rev=1079780view=rev
Log:
CXF-3385 Add a new option in WSD2Java to skip the generate the type classes
from schema
Modified:
cxf/trunk/api/src/main/java/org/apache/cxf/tools/common/ToolConstants.java
cxf/trunk/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_
plugin/Option.java
cxf/trunk/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_
plugin/WsdlOption.java
cxf/trunk/tools/wsdlto/core/src/main/java/org/apache/cxf/tools/wsdlto/WSDL
ToJavaContainer.java
cxf/trunk/tools/wsdlto/core/src/main/java/org/apache/cxf/tools/wsdlto/wsdl
to.xml
cxf/trunk/tools/wsdlto/frontend/jaxws/src/main/java/org/apache/cxf/tools/w
sdlto/frontend/jaxws/jaxws-toolspec.xml
cxf/trunk/tools/wsdlto/test/src/test/java/org/apache/cxf/tools/wsdlto/jaxw
s/CodeGenTest.java
Modified:
cxf/trunk/api/src/main/java/org/apache/cxf/tools/common/ToolConstants.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/api/src/main/java/org/apache/cxf/to
ols/common/ToolConstants.java?rev=1079780r1=1079779r2=1079780view=diff
==
---
cxf/trunk/api/src/main/java/org/apache/cxf/tools/common/ToolConstants.java
(original) +++
cxf/trunk/api/src/main/java/org/apache/cxf/tools/common/ToolConstants.java
Wed Mar 9 12:54:15 2011 @@ -63,6 +63,7 @@ public final class
ToolConstants {
public static final String CFG_EXTRA_SOAPHEADER = exsoapheader;
public static final String CFG_DEFAULT_NS = defaultns;
public static final String CFG_DEFAULT_EX = defaultex;
+public static final String CXF_GENERATE_TYPES = generatetypes;
public static final String CFG_XJC_ARGS = xjc;
public static final String CFG_CATALOG = catalog;
public static final String CFG_DEFAULT_VALUES = defaultValues;
Modified:
cxf/trunk/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_
plugin/Option.java URL:
http://svn.apache.org/viewvc/cxf/trunk/maven-plugins/codegen-plugin/src/ma
in/java/org/apache/cxf/maven_plugin/Option.java?rev=1079780r1=1079779r2=1
079780view=diff
==
---
cxf/trunk/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_
plugin/Option.java (original) +++
cxf/trunk/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_
plugin/Option.java Wed Mar 9 12:54:15 2011 @@ -134,6 +134,12 @@ public
class Option {
* Enables validating the WSDL before generating the code.
*/
Boolean validateWsdl;
+
+
+/**
+ * Enables or disables generation of the type classes. Default value
is true. + */
+Boolean generateTypes;
/**
* Enables generation of fault Exception's SUID based on hash of
classname. @@ -314,6 +320,14 @@ public class Option {
public void setValidateWsdl(boolean validateWsdl) {
this.validateWsdl = validateWsdl;
}
+
+public boolean isGenerateTypes() {
+return generateTypes == null ? true : generateTypes;
+}
+
+public void setGenerateTypes(boolean generateTypes) {
+this.generateTypes = generateTypes;
+}
public boolean isUseFQCNForFaultSerialVersionUID() {
return useFQCNForFaultSerialVersionUID == null ? false :
useFQCNForFaultSerialVersionUID; @@ -398,6 +412,7 @@ public class Option {
destination.setPackagenames(getPackagenames());
destination.setServiceName(getServiceName());
destination.setValidateWsdl(isValidateWsdl());
+destination.setGenerateTypes(isGenerateTypes());
destination.setUseFQCNForFaultSerialVersionUID(isUseFQCNForFaultSerialVers
ionUID()); destination.setMarkGenerated(isMarkGenerated());
destination.setAllowElementRefs(isAllowElementRefs());
@@ -417,6 +432,7 @@ public class Option {
public void merge(Option defaultOptions) {
wsdlList = setIfNull(wsdlList, defaultOptions.wsdlList);
extendedSoapHeaders = setIfNull(extendedSoapHeaders,
defaultOptions.extendedSoapHeaders); +generateTypes =
setIfNull(generateTypes, defaultOptions.generateTypes); validateWsdl =
setIfNull(validateWsdl, defaultOptions.validateWsdl);
Re: LogBrowser project is on the trunk
Hi Tomasz On Wed, Mar 9, 2011 at 3:00 PM, Tomasz Oponowicz tomasz.oponow...@gmail.com wrote: Hi Sergey, On Wed, Mar 9, 2011 at 2:28 PM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi Tomasz I'm finishing some work for AtomPullServer be able to connect to the existing file logs, I saw you committing some relevant updates to the LogBrowser code too, thanks. I'll will experiment with the Filter dialog shortly. I've just added logic to Filter dialog box. It doesn't work because we have to talk about how should I pass attributes to AtomPullServer. At the moment I'm building URL: endpoint_url?_s=date=ge=129966840;date=lt=130027320;level==DEBUG;level==WARN How should I pass an array of levels? ';' means 'and' while ',' means 'or' so in this case we have to use ',' : endpoint_url?_s=level==WARN,level==DEBUG Dates need to be passed differently, you can probably use the following code: String format = -MM-dd; String date = new SimpleDateFormat(format).format(date); and add it to the query. I'll need to write a test involving dates as well. I've made assumption that feed's links (i.e. next, previous etc) will contain filtering attributes. Yes, exactly, I've already written few tests confirming it. What I'd really appreciate if you could help me with the following, hope it will take just a fraction of your time: - Remove the Authentication/SignIn/SignOut related code/resources. We just don't have time now to deal with the authentication/security issues and we'd need to have another discussion later on about it. I believe you agreed to it too. I'm working on it right now. I almost finished. - Explain a bit which code/script deals with processing the dates. I know you spent a lot of time on trying to reproduce the application exception, including testing it on Ubuntu, but I'd like to give it a try and see if I can spot something that causes the issue on my particular OS - if I can trace it to some bad Java or Firefox installation then I'll get relaxed :-)... I will give more details at this afternoon. thanks again :-) Thanks, Sergey On Sun, Feb 27, 2011 at 6:20 PM, Sergey Beryozkin sberyoz...@gmail.com wrote: String text = columnDefinition.getContent(entry); in SelectableTable.setData is causing it, and it's only happening when the Date column is filled in, the Level and Message are fine. Looks like the code co0nverting the Atom/http-format date is brittle a bit cheers, Sergey On Sun, Feb 27, 2011 at 5:10 PM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi Tomasz I've spent some time and it is some sort of the asynchronous exception which when captured shows the Date of the log entry. It is thrown when the ViewerViewImpl.setEntries(ListEntry entries) is called. We'll track it down soon :-) Sergey On Sat, Feb 26, 2011 at 1:23 PM, Tomasz Oponowicz tomasz.oponow...@gmail.com wrote: Hi Sergey, On Fri, Feb 25, 2011 at 1:19 PM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi Tomasz I've rerun the demo. First of all, the changes you've made recently have definitely made it look much better, thanks. Unfortunately, I'm still hitting this GWT ApplicationException when refreshing the endpoint : Application Error Class$jcb 2011-02-25T11:46:55.078Z Can this message, particularly Class$jcb, help somehow to identify the problem ? It does look like it's a platform/browser specific issue, I'm on Ubuntu 9, Firefox 3.6.13, but it would be good to get rid of it somehow. Just tried Chrome and it showed the same error but with the Class$kbc - it's probably the some gwt proxy... Can you please point to the code in the logbrowser project where the response from the remote endpoint is processed ? I will investigate... I will install similar environment as a virtual machine - I hope I will reproduce this issue... Few more comments. I agree, the way Tasks and Endpoints are currently shown is nice. - Can you please consider having both ManageEndpoints and Filter links located under the Tasks ? And have Endpoints shown first, with the Tasks in the bottom of the pane ? Ultimately, the user just wants to see the list of endpoints. Creating/deleting the endpoints and applying filters is critical but I'd just prefer the Tasks not to feature as the main activity of the LogBrowser users... - Filter dialog can not be closed at the moment, after it has been opened... - Probably makes sense to rename Explore to Explorer given that the ManageEndpoints panel has the Back to Explorer link... More comments inline... - Authentication: I've noticed there's AuthenticationRequired annotation attached to some of the BootstrapStorage methods - we really need to remove this annotation and for now just pop-up a login window on the
Google Summer of Code ideas....
I know it's still winter and some of us still have a lot of snow on the ground so summer seems very far off, but Google Summer of Code is beginning to startup for this year. Last year, we had 3 projects the have produced excellent results for CXF. I'm definitely hoping we can have another successful summer of coding. However, to achieve that, we need ideas. :-) If you have any ideas, please feel free to propose them on this list. However, we'll also need to get them into JIRA and have a gsoc2011 label added to them.I'm going to go through some of the JIRA's and add the label, particularly for some of the ideas we had for last year. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: CXF OSGI application and HTTP transport
Hi Christian On Wed, Mar 9, 2011 at 1:06 PM, Christian Schneider ch...@die-schneider.net wrote: Hi Sergey, I am currently starting to work on https://issues.apache.org/jira/browse/CXF-3384 which also depends on unifying the servlet an osgi http transports. Currently the code has some subtle differences mostly in the servletcontroller. I am trying to use the same code and see if the tests still work. Then we could try to remove any special osgi code for http. The only thing that would remain are the two spring contexts. As I am also not sure if these contexts are a good way to setup CXF in OSGi I would be very interested in your thoughts about this. Perhaps we can work on a better design. I am sure David could help a lot as he did a quite different aproach in DOSGi. Perhaps it might make sense to try and experiment with replacing the existing http-osgi spring-dm configuration with the equivalent implementation. This even can be tried in the http-osgi. For the sake of the experiment only... So we can start with removing that spring context and adding an Activator implementation in the .osgi sub-package. This Activator uses ServiceTracker to catch the HttpService and then immediately uses it to register the servlet using the required context name - it can find about the custom name from the ConfigAdmin. The activator also registers itself as the ManagedService and exposes properties (those in the spring-dm context and more as needed). This is really what Spring DM/Blueprint does under the hood...DOSGi also interacts directly with the HTTP service. So having this Activator can meet your requirement of detecting the OSGI env. This Activator would need to be referenced from the cxf-bundle manifest which is a bit strange but it is exactly what we have at the moment with the http-osgi transport being the 'CXF OSGI Application'. May be it is too simplistic but may be it can work :-) Cheers, Sergey Christian Am 09.03.2011 12:26, schrieb Sergey Beryozkin: Hi I'd like to discuss a bit the possibility of making the CXF HTTP-OSGI transport redundant. Not sure if it's a good idea but I'd like to give it a chance :-) by discussing it on this list. The reason I'm concerned about CXF HTTP-OSGI transport is that it effectively takes the role of the CXF OSGI application. At the moment it's a Spring DM application and may get updated to become a Blueprint one. CXF is bigger than its HTTP transport but we're limited only to its HTTP transport registering itself as the Servlet. The other thing which concerns me is its static nature to do with hard-coding the context name and the names of the properties it may support. Having a single context within a given container instance is a limitation, not a big one, but it is nonetheless. And hardcoding the names of the properties is not good at all because OSGI gives us a ManagedService interface. Finally we are just totally out of control here and just depend on the external injection. I hope we can find a way to break this dependency. It was really needed at a time but IMHO it limits the way CXF as a whole can play in OSGI. If we look at DOSGi, one of the reasons it is interesting to developers is that it effectively makes CXF JAX-WS and JAX-RS runtimes taking more active roles in the process. DOSGi provides callbacks for these components to wrap the registered/looked-up interfaces. Yet alternative way is to have individual Activators check a given bundle for the presence of say JAX-RS Application or may be JAX-WS @WebService interface and react. I'm wondering if the idea of introducing a top-level Activator (at the distribution level) delegating to module-specific Activators works or not. At the moment it seems like it can. HTTP, JAX-WS, JAX-RS/etc Activators can do whatever they need to and also expose the properties which can be dynamically updated... My only concern is how to synchronize the whole process and the idea of say HTTP Transport registering itself as some OSGI service (discussed in the other thread) can be a perfect solution. If it all can work then we will end up having a real CXF OSGI application, very flexible and advanced, it will be a different level really... Of course that could be a bad idea - there could be constraints there which basically make it not-workable... Cheers, Sergey -- http://www.liquid-reality.de -- Sergey Beryozkin Application Integration Division of Talend http://www.talend.com http://sberyozkin.blogspot.com
Re: Google Summer of Code ideas....
Hi On Wed, Mar 9, 2011 at 4:39 PM, Daniel Kulp dk...@apache.org wrote: I know it's still winter and some of us still have a lot of snow on the ground so summer seems very far off, but Google Summer of Code is beginning to startup for this year. Last year, we had 3 projects the have produced excellent results for CXF. I'm definitely hoping we can have another successful summer of coding. However, to achieve that, we need ideas. :-) If you have any ideas, please feel free to propose them on this list. However, we'll also need to get them into JIRA and have a gsoc2011 label added to them.I'm going to go through some of the JIRA's and add the label, particularly for some of the ideas we had for last year. I've created two JIRAs: https://issues.apache.org/jira/browse/CXF-3388 https://issues.apache.org/jira/browse/CXF-3389 Thanks, Sergey -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
GSoC project idea :Implement specification WS-RM 1.1 or 1.2
Hi devs, I am Eranda Sooriyabandara from University of Moratuwa, Sri Lanka. I am interested in the project, Implement specification WS-RM 1.1 or 1.2. I have some background knowledge on web services and mediation, SOAP etc... and I like to learn more. As a newbie can you send me some docs to read about CXF so I can start on it. thanks Eranda
Re: GSoC project idea :Implement specification WS-RM 1.1 or 1.2
Hi Eranda, I'm actually in the process of doing the WS-RM 1.1 and 1.2 implementations now. The first step has been cleaning up the current implementation to make it fully functional, which is mostly done at this point (I've got it interoperating with Metro on a hacked up build, just need to get the code cleaned up to go into trunk). I've been off on some other things for the last few couple of weeks, but plan to have the implementations completed within the next month. So probably not a great choice... - Dennis On 03/10/2011 02:44 PM, Eranda Sooriyabandara wrote: Hi devs, I am Eranda Sooriyabandara from University of Moratuwa, Sri Lanka. I am interested in the project, Implement specification WS-RM 1.1 or 1.2. I have some background knowledge on web services and mediation, SOAP etc... and I like to learn more. As a newbie can you send me some docs to read about CXF so I can start on it. thanks Eranda
