Re: Javascript generation
On Friday 19 March 2010 2:57:49 pm Demetris wrote: > Nice - thanks Dan. Do you know of any plans for CXF to support WSDL 2.0 > soon? Forgot to answer this one Not really unless someone steps up to do it. Really not much demand and very poor interopability with it since few toolkits support it. Dan > So in the CXF design, the client requests a javascript script through a > URL-based > command and then that script is used for the invocation of the remote > (REST) service. > Is the script on the server side generated at runtime based on the > implementation of the > service or is it pre-defined before the service is launched? > > Daniel Kulp wrote: > > On Thursday 18 March 2010 1:44:08 am Demetris wrote: > >> Hi all, > >> > >> where would the server-side javascript code generotion be located in > >> > >> the baseline? > > > > Should be in: > > http://svn.apache.org/repos/asf/cxf/trunk/rt/javascript > > > > and the command line tool that would wrapper it: > > http://svn.apache.org/repos/asf/cxf/trunk/tools/wsdlto/frontend/javascrip > > t/ > > > >> I don't seem to be able to locate it. Is there documentation as to who > >> this generation > >> works? Is it derived from the service's WSDL file or does the user > >> navigate how this > >> generation should work? > > > > It's based on the WSDL I believe. Or, more approriately, our service > > model that would hold onto the wsdl information. > > > >> One of the responses I got from Benson as while ago read: > >> "you can create a 'dynamic client' that can talk to moderately > >> complex services. This requires the entire CXF stack on the client" > >> > >> Are there any examples I can look at of such a 'dynamic client'. And > >> to what capacity is it 'dynamic'? > >> > >> I have http servers that return WSDL 2.0 files (either REST or SOAP > >> sevices) and I would like to utilize them to generate javascript > >> clients for those services. From what I gathered so far, CXF and > >> WSO2 are the only mature projects doing this. If you do know of any > >> other ones please let me know. It seems to me that CXF can offer > >> such tools for me to build these clients so I wanted to find a bit > >> more about them. I have already started going over the online info. > > > > Well, CXF doesn't support WSDL 2.0. Thus, that could be an issue. > > > > Dan > > > >> Thanks very much in advace -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
Re: Javascript generation
On Friday 19 March 2010 2:57:49 pm Demetris wrote: > Nice - thanks Dan. Do you know of any plans for CXF to support WSDL 2.0 > soon? > > So in the CXF design, the client requests a javascript script through a > URL-based > command and then that script is used for the invocation of the remote > (REST) service. As Benson mentioned, it's just for the SOAP services right now. > Is the script on the server side generated at runtime based on the > implementation of the > service or is it pre-defined before the service is launched? It is generated at runtime based on our internal service model. However, there is a command line tool that you can use to pre-generate it from the WSDL if you prefer to do that. Dan > > Daniel Kulp wrote: > > On Thursday 18 March 2010 1:44:08 am Demetris wrote: > >> Hi all, > >> > >> where would the server-side javascript code generotion be located in > >> > >> the baseline? > > > > Should be in: > > http://svn.apache.org/repos/asf/cxf/trunk/rt/javascript > > > > and the command line tool that would wrapper it: > > http://svn.apache.org/repos/asf/cxf/trunk/tools/wsdlto/frontend/javascrip > > t/ > > > >> I don't seem to be able to locate it. Is there documentation as to who > >> this generation > >> works? Is it derived from the service's WSDL file or does the user > >> navigate how this > >> generation should work? > > > > It's based on the WSDL I believe. Or, more approriately, our service > > model that would hold onto the wsdl information. > > > >> One of the responses I got from Benson as while ago read: > >> "you can create a 'dynamic client' that can talk to moderately > >> complex services. This requires the entire CXF stack on the client" > >> > >> Are there any examples I can look at of such a 'dynamic client'. And > >> to what capacity is it 'dynamic'? > >> > >> I have http servers that return WSDL 2.0 files (either REST or SOAP > >> sevices) and I would like to utilize them to generate javascript > >> clients for those services. From what I gathered so far, CXF and > >> WSO2 are the only mature projects doing this. If you do know of any > >> other ones please let me know. It seems to me that CXF can offer > >> such tools for me to build these clients so I wanted to find a bit > >> more about them. I have already started going over the online info. > > > > Well, CXF doesn't support WSDL 2.0. Thus, that could be an issue. > > > > Dan > > > >> Thanks very much in advace -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
Re: Javascript generation
Uh, no. The generated Javascript talks SOAP, not REST. We don't have a generator for REST clients. On Fri, Mar 19, 2010 at 2:57 PM, Demetris wrote: > > Nice - thanks Dan. Do you know of any plans for CXF to support WSDL 2.0 > soon? > > So in the CXF design, the client requests a javascript script through a > URL-based > command and then that script is used for the invocation of the remote (REST) > service. > Is the script on the server side generated at runtime based on the > implementation of the > service or is it pre-defined before the service is launched? > > Daniel Kulp wrote: >> >> On Thursday 18 March 2010 1:44:08 am Demetris wrote: >> >>> >>> Hi all, >>> >>> where would the server-side javascript code generotion be located in >>> the baseline? >>> >> >> Should be in: >> http://svn.apache.org/repos/asf/cxf/trunk/rt/javascript >> >> and the command line tool that would wrapper it: >> >> http://svn.apache.org/repos/asf/cxf/trunk/tools/wsdlto/frontend/javascript/ >> >> >>> >>> I don't seem to be able to locate it. Is there documentation as to who >>> this generation >>> works? Is it derived from the service's WSDL file or does the user >>> navigate how this >>> generation should work? >>> >> >> It's based on the WSDL I believe. Or, more approriately, our service >> model that would hold onto the wsdl information. >> >> >>> >>> One of the responses I got from Benson as while ago read: >>> >>> "you can create a 'dynamic client' that can talk to moderately >>> complex services. This requires the entire CXF stack on the client" >>> >>> Are there any examples I can look at of such a 'dynamic client'. And >>> to what capacity is it 'dynamic'? >>> >>> I have http servers that return WSDL 2.0 files (either REST or SOAP >>> sevices) and I would like to utilize them to generate javascript >>> clients for those services. From what I gathered so far, CXF and >>> WSO2 are the only mature projects doing this. If you do know of any >>> other ones please let me know. It seems to me that CXF can offer >>> such tools for me to build these clients so I wanted to find a bit >>> more about them. I have already started going over the online info. >>> >> >> Well, CXF doesn't support WSDL 2.0. Thus, that could be an issue. >> >> Dan >> >> >> >>> >>> Thanks very much in advace >>> >> >> >
Re: Javascript generation
Nice - thanks Dan. Do you know of any plans for CXF to support WSDL 2.0 soon? So in the CXF design, the client requests a javascript script through a URL-based command and then that script is used for the invocation of the remote (REST) service. Is the script on the server side generated at runtime based on the implementation of the service or is it pre-defined before the service is launched? Daniel Kulp wrote: On Thursday 18 March 2010 1:44:08 am Demetris wrote: Hi all, where would the server-side javascript code generotion be located in the baseline? Should be in: http://svn.apache.org/repos/asf/cxf/trunk/rt/javascript and the command line tool that would wrapper it: http://svn.apache.org/repos/asf/cxf/trunk/tools/wsdlto/frontend/javascript/ I don't seem to be able to locate it. Is there documentation as to who this generation works? Is it derived from the service's WSDL file or does the user navigate how this generation should work? It's based on the WSDL I believe. Or, more approriately, our service model that would hold onto the wsdl information. One of the responses I got from Benson as while ago read: "you can create a 'dynamic client' that can talk to moderately complex services. This requires the entire CXF stack on the client" Are there any examples I can look at of such a 'dynamic client'. And to what capacity is it 'dynamic'? I have http servers that return WSDL 2.0 files (either REST or SOAP sevices) and I would like to utilize them to generate javascript clients for those services. From what I gathered so far, CXF and WSO2 are the only mature projects doing this. If you do know of any other ones please let me know. It seems to me that CXF can offer such tools for me to build these clients so I wanted to find a bit more about them. I have already started going over the online info. Well, CXF doesn't support WSDL 2.0. Thus, that could be an issue. Dan Thanks very much in advace
Re: Google Summer of Code ideas.....
How about doing an integration with ZooKeeper that would allow web/rest service instances to automatically register their existence with a run-time registry: at run-time, clients could then mint a reference to any one of the backend services. This would start as a mechanism to provide true location transparency for services, and would end up in a nice mechanism for server-side clustering, high-availability and failover! Other thing that would be great (although perhaps not very sexy) is to build out the samples around WS-Trust, in particular, the policy-driven aspects. Cheers, Ade. On 19/03/2010 11:40, Sergey Beryozkin wrote: - Simple and lightweight Atom HTML-based browser supporting feed links (next/previous/first/last) based on the existing CXF JAXRS WebClient API to be added to a rt/management-web component and which will be used for browsing the CXF logs. This browser will let users see the contents of the current page plus provided an option to follow the links to the next/prev/etc pages - Simple HTML based console for displaying the exchange data (jaxws/jaxrs) persisted by PersistIn/Out interceptors; this console will communicate with a CXF JAXRS endpoint, all to be added to the rt/management-web; I'll be willing to act as a mentor cheers, Sergey On Fri, Mar 19, 2010 at 2:24 AM, Daniel Kulp wrote: The Google Summer of Code program is starting up. Last year, we had a very good project completed (SOAP/JMS Spec) and significant work started toward the SOAP/TCP stuff. At this point, it would be good to start collecting ideas that students may be interested in tackling. So, what really cool ideas do people have? :-) -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
Re: Moving org.apache.cxf.jaxb.attachment from cxf-rt-databinding-jaxb to cxf-common-utilities
Hmm...Those classes depend on the CXF Attachment class which lives in the api module built after the common-utilities. Moving it into rt/core, org.apache.cxf.attachment.jaxb, may not be the best idea. I'll probably just add copies to a rt/frontend/jaxrs, given that there won't be a need to override addSwaRefAttachment()... It is strange indeed addSwaRefAttachment() is available at the JAXB level... And then I'll refactor some code into AttachmentUtil in the core cheers, Sergey On Fri, Mar 19, 2010 at 3:26 PM, Sergey Beryozkin wrote: > Hi > > I need to update a JAXRS JAXBElementProvider to create attachment > marshallers/unmarshallers for a xop packaging format be supported. > > cxf-rt-databinding-jaxb/org.apache.cxf.jaxb.attachment has all the classes > I need but I'm not sure I should add a strong dependency on > cxf-rt-databinding-jaxb at this moment of time, instead I suggest moving the > package to a common-utilities component, which already has an > org.apache.cxf.jaxb package. > > Any objections ? > > cheers, Sergey > >
Re: [VOTE] Release CXF 2.2.7
+1 Jeff On Mar 18, 2010, at 6:21 PM, Daniel Kulp wrote: > > Once again, there have been a bunch of bug fixes and enhancements that > have been done compared to the 2.2.6 release. Over 55 JIRA issues > are resolved for 2.2.7. > > List of issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12314534&styleName=Html&projectId=12310511&Create=Create > > The Maven staging area is at: > https://repository.apache.org/content/repositories/orgapachecxf-006/ > > The distributions are in: > https://repository.apache.org/content/repositories/orgapachecxf-006/org/apache/cxf/apache-cxf/2.2.7/ > > This release is tagged at: > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.7 > > > The vote will be open for 72 hours. > > Here is my +1. > > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog
Moving org.apache.cxf.jaxb.attachment from cxf-rt-databinding-jaxb to cxf-common-utilities
Hi I need to update a JAXRS JAXBElementProvider to create attachment marshallers/unmarshallers for a xop packaging format be supported. cxf-rt-databinding-jaxb/org.apache.cxf.jaxb.attachment has all the classes I need but I'm not sure I should add a strong dependency on cxf-rt-databinding-jaxb at this moment of time, instead I suggest moving the package to a common-utilities component, which already has an org.apache.cxf.jaxb package. Any objections ? cheers, Sergey
Re: Google Summer of Code ideas.....
- Simple and lightweight Atom HTML-based browser supporting feed links (next/previous/first/last) based on the existing CXF JAXRS WebClient API to be added to a rt/management-web component and which will be used for browsing the CXF logs. This browser will let users see the contents of the current page plus provided an option to follow the links to the next/prev/etc pages - Simple HTML based console for displaying the exchange data (jaxws/jaxrs) persisted by PersistIn/Out interceptors; this console will communicate with a CXF JAXRS endpoint, all to be added to the rt/management-web; I'll be willing to act as a mentor cheers, Sergey On Fri, Mar 19, 2010 at 2:24 AM, Daniel Kulp wrote: > > The Google Summer of Code program is starting up. Last year, we had a > very > good project completed (SOAP/JMS Spec) and significant work started toward > the > SOAP/TCP stuff. > > At this point, it would be good to start collecting ideas that students may > be > interested in tackling. So, what really cool ideas do people have? :-) > > > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog >
Re: [VOTE] Release CXF 2.2.7
+1 /Eoghan On 19 March 2010 01:21, Daniel Kulp wrote: > > Once again, there have been a bunch of bug fixes and enhancements that > have been done compared to the 2.2.6 release. Over 55 JIRA issues > are resolved for 2.2.7. > > List of issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12314534&styleName=Html&projectId=12310511&Create=Create > > The Maven staging area is at: > https://repository.apache.org/content/repositories/orgapachecxf-006/ > > The distributions are in: > > https://repository.apache.org/content/repositories/orgapachecxf-006/org/apache/cxf/apache-cxf/2.2.7/ > > This release is tagged at: > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.7 > > > The vote will be open for 72 hours. > > Here is my +1. > > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog >
Re: JMX enabling in CXF 2.2.6
A-ha, my bad, I assumed you were using the remote process option ... so you just can't see the CXF MBeans when you connect via the jconsole local process option? That's easy, just ensure your injected InstrumentationManager bean picks up the *platform* MBeanServer as opposed to creating a fresh one. Its the platform MBeanServer that the local process option will go for by default. Simply modify your config as follows to set the usePlatformMBeanServer property: BTW in the remote case, you don't even need to specify the cxf/cxf as remote user/pass as this is not authenticated (unlike SMX/karaf). /Eoghan On 19 March 2010 10:29, Ulhas Bhole wrote: > Hi Eoghan, > > I did a few tests and it looks like if I try to connect to the process from > JConsole it doesn't show CXF JMX stats. If I create a new connection using > JMX URL and username/password (cxf/cxf) I do see the CXF MBean appearing. > > Thanks for the help. > > Regards, > > Ulhas Bhole > > I just did a few tests > > I just tried it on 2 different machines (Linux and Mac) using JDK 1.5 > On Fri, Mar 19, 2010 at 10:05 AM, Ulhas Bhole > wrote: > > > Thanks Eoghan for quick reply. I will try to update build.xml target and > > check. I was putting cxf.xml in $CXF_HOME/samples/wsdl_first_rpclit > > directory and I think it was picked up because when I ran client it did > got > > AddressAlreadyInUse for JMX port and also I could connect to the server > > using JConsole. > > > > I will try your route. > > > > Regards, > > > > Ulhas Bhole > > > > > > On Thu, Mar 18, 2010 at 10:05 PM, Eoghan Glynn > wrote: > > > >> Ulhas, > >> > >> How are you picking up the config file? > >> > >> For example, if you're running the server via ant, you'd need to change > >> the > >> server target defined in $CXF_HOME/samples/wsdl_first_rpclit/build.xml > >> from: > >> > >> > >> >>param1="${basedir}/wsdl/hello_world_RPCLit.wsdl"/> > >> > >> > >> to: > >> > >> > >> >>jvmarg1="-Dcxf.config.file=cxf.xml" > >>param1="${basedir}/wsdl/hello_world_RPCLit.wsdl"/> > >> > >> > >> Alternatively, you could change the > >> $CXF_HOME/samples/wsdl_first_rpclit/src/demo/hwRPCLit/server/Server.java > >> to > >> use the SpringBusFactory to explicit identify the config file when > >> creating > >> the Bus. > >> > >> But obviously you must make the connection to the config in *some* way, > >> otherwise the intrumentation config will have no effect. BTW I just > >> confirmed that the CXF MBeans appear as expected with this demo using > your > >> config file and the first approach described. > >> > >> Cheers, > >> Eoghan > >> > >> > >> On 18 March 2010 17:24, Ulhas Bhole wrote: > >> > >> > Hi, > >> > I am trying to enable JMX instrumentation in CXF 2.2.6 sample > >> > (wsdl_first_rpclit) but when I try to connect to server using JConsole > I > >> > don't see any CXF MBeans. Do I need to do anything in addition to > >> > configuring Instrumentation manager? > >> > > >> > Here is my cxf.xml that I am using to enable instrumentation. I am not > >> > updating any implementation to collect endpoint statistics just want > to > >> see > >> > cxf stats first like Bus. > >> > > >> > http://www.springframework.org/schema/beans"; > >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > >> > xmlns:jaxws="http://cxf.apache.org/jaxws"; > >> > xmlns:cxf="http://cxf.apache.org/core"; > >> > > >> > xsi:schemaLocation=" > >> > http://www.springframework.org/schema/beans > >> > http://www.springframework.org/schema/beans/spring-beans.xsd > >> > http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd > >> > http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";> > >> > > >> > > >> > >> > class="org.apache.cxf.management.jmx.InstrumentationManagerImpl"> > >> > > >> > > >> > > >> > > >> > >> > value="service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" /> > >> > > >> > > >> > > >> > > >> > >> > class="org.apache.cxf.management.counters.CounterRepository"> > >> > > >> > > >> > > >> > > >> > > >> > Regards, > >> > > >> > Ulhas Bhole > >> > > >> > > > > >
Re: Google Summer of Code ideas.....
Javascript attribute support, he writes lamely. On Thu, Mar 18, 2010 at 10:24 PM, Daniel Kulp wrote: > > The Google Summer of Code program is starting up. Last year, we had a very > good project completed (SOAP/JMS Spec) and significant work started toward the > SOAP/TCP stuff. > > At this point, it would be good to start collecting ideas that students may be > interested in tackling. So, what really cool ideas do people have? :-) > > > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog >
Re: [VOTE] Release CXF 2.2.7
+1 ! Sergey On Fri, Mar 19, 2010 at 1:21 AM, Daniel Kulp wrote: > > Once again, there have been a bunch of bug fixes and enhancements that > have been done compared to the 2.2.6 release. Over 55 JIRA issues > are resolved for 2.2.7. > > List of issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12314534&styleName=Html&projectId=12310511&Create=Create > > The Maven staging area is at: > https://repository.apache.org/content/repositories/orgapachecxf-006/ > > The distributions are in: > > https://repository.apache.org/content/repositories/orgapachecxf-006/org/apache/cxf/apache-cxf/2.2.7/ > > This release is tagged at: > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.7 > > > The vote will be open for 72 hours. > > Here is my +1. > > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog >
Re: JMX enabling in CXF 2.2.6
Hi Eoghan, I did a few tests and it looks like if I try to connect to the process from JConsole it doesn't show CXF JMX stats. If I create a new connection using JMX URL and username/password (cxf/cxf) I do see the CXF MBean appearing. Thanks for the help. Regards, Ulhas Bhole I just did a few tests I just tried it on 2 different machines (Linux and Mac) using JDK 1.5 On Fri, Mar 19, 2010 at 10:05 AM, Ulhas Bhole wrote: > Thanks Eoghan for quick reply. I will try to update build.xml target and > check. I was putting cxf.xml in $CXF_HOME/samples/wsdl_first_rpclit > directory and I think it was picked up because when I ran client it did got > AddressAlreadyInUse for JMX port and also I could connect to the server > using JConsole. > > I will try your route. > > Regards, > > Ulhas Bhole > > > On Thu, Mar 18, 2010 at 10:05 PM, Eoghan Glynn wrote: > >> Ulhas, >> >> How are you picking up the config file? >> >> For example, if you're running the server via ant, you'd need to change >> the >> server target defined in $CXF_HOME/samples/wsdl_first_rpclit/build.xml >> from: >> >> >>>param1="${basedir}/wsdl/hello_world_RPCLit.wsdl"/> >> >> >> to: >> >> >>>jvmarg1="-Dcxf.config.file=cxf.xml" >>param1="${basedir}/wsdl/hello_world_RPCLit.wsdl"/> >> >> >> Alternatively, you could change the >> $CXF_HOME/samples/wsdl_first_rpclit/src/demo/hwRPCLit/server/Server.java >> to >> use the SpringBusFactory to explicit identify the config file when >> creating >> the Bus. >> >> But obviously you must make the connection to the config in *some* way, >> otherwise the intrumentation config will have no effect. BTW I just >> confirmed that the CXF MBeans appear as expected with this demo using your >> config file and the first approach described. >> >> Cheers, >> Eoghan >> >> >> On 18 March 2010 17:24, Ulhas Bhole wrote: >> >> > Hi, >> > I am trying to enable JMX instrumentation in CXF 2.2.6 sample >> > (wsdl_first_rpclit) but when I try to connect to server using JConsole I >> > don't see any CXF MBeans. Do I need to do anything in addition to >> > configuring Instrumentation manager? >> > >> > Here is my cxf.xml that I am using to enable instrumentation. I am not >> > updating any implementation to collect endpoint statistics just want to >> see >> > cxf stats first like Bus. >> > >> > http://www.springframework.org/schema/beans"; >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> > xmlns:jaxws="http://cxf.apache.org/jaxws"; >> > xmlns:cxf="http://cxf.apache.org/core"; >> > >> > xsi:schemaLocation=" >> > http://www.springframework.org/schema/beans >> > http://www.springframework.org/schema/beans/spring-beans.xsd >> > http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd >> > http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";> >> > >> > >> > > > class="org.apache.cxf.management.jmx.InstrumentationManagerImpl"> >> > >> > >> > >> > >> > > > value="service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" /> >> > >> > >> > >> > >> >> > class="org.apache.cxf.management.counters.CounterRepository"> >> > >> > >> > >> > >> > >> > Regards, >> > >> > Ulhas Bhole >> > >> > >
Re: JMX enabling in CXF 2.2.6
Thanks Eoghan for quick reply. I will try to update build.xml target and check. I was putting cxf.xml in $CXF_HOME/samples/wsdl_first_rpclit directory and I think it was picked up because when I ran client it did got AddressAlreadyInUse for JMX port and also I could connect to the server using JConsole. I will try your route. Regards, Ulhas Bhole On Thu, Mar 18, 2010 at 10:05 PM, Eoghan Glynn wrote: > Ulhas, > > How are you picking up the config file? > > For example, if you're running the server via ant, you'd need to change the > server target defined in $CXF_HOME/samples/wsdl_first_rpclit/build.xml > from: > > >param1="${basedir}/wsdl/hello_world_RPCLit.wsdl"/> > > > to: > > >jvmarg1="-Dcxf.config.file=cxf.xml" >param1="${basedir}/wsdl/hello_world_RPCLit.wsdl"/> > > > Alternatively, you could change the > $CXF_HOME/samples/wsdl_first_rpclit/src/demo/hwRPCLit/server/Server.java to > use the SpringBusFactory to explicit identify the config file when creating > the Bus. > > But obviously you must make the connection to the config in *some* way, > otherwise the intrumentation config will have no effect. BTW I just > confirmed that the CXF MBeans appear as expected with this demo using your > config file and the first approach described. > > Cheers, > Eoghan > > > On 18 March 2010 17:24, Ulhas Bhole wrote: > > > Hi, > > I am trying to enable JMX instrumentation in CXF 2.2.6 sample > > (wsdl_first_rpclit) but when I try to connect to server using JConsole I > > don't see any CXF MBeans. Do I need to do anything in addition to > > configuring Instrumentation manager? > > > > Here is my cxf.xml that I am using to enable instrumentation. I am not > > updating any implementation to collect endpoint statistics just want to > see > > cxf stats first like Bus. > > > > http://www.springframework.org/schema/beans"; > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > xmlns:jaxws="http://cxf.apache.org/jaxws"; > > xmlns:cxf="http://cxf.apache.org/core"; > > > > xsi:schemaLocation=" > > http://www.springframework.org/schema/beans > > http://www.springframework.org/schema/beans/spring-beans.xsd > > http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd > > http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";> > > > > > > > class="org.apache.cxf.management.jmx.InstrumentationManagerImpl"> > > > > > > > > > > > value="service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" /> > > > > > > > > > > > class="org.apache.cxf.management.counters.CounterRepository"> > > > > > > > > > > > > Regards, > > > > Ulhas Bhole > > >
Re: [VOTE] Release CXF 2.2.7
+1, -- Ulhas Bhole On Fri, Mar 19, 2010 at 1:21 AM, Daniel Kulp wrote: > > Once again, there have been a bunch of bug fixes and enhancements that > have been done compared to the 2.2.6 release. Over 55 JIRA issues > are resolved for 2.2.7. > > List of issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12314534&styleName=Html&projectId=12310511&Create=Create > > The Maven staging area is at: > https://repository.apache.org/content/repositories/orgapachecxf-006/ > > The distributions are in: > > https://repository.apache.org/content/repositories/orgapachecxf-006/org/apache/cxf/apache-cxf/2.2.7/ > > This release is tagged at: > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.7 > > > The vote will be open for 72 hours. > > Here is my +1. > > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog >