Re: ServiceMix 4.0
Fanastic. Once we get consensus on the direction (your first few points), I wonder if we shouldn't break this email out to discuss the specifics. On 8/22/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote: > As I explained in the other thread, I've been working on a new API > for ServiceMix 4.0. > Hopefully this will serve as an input for JBI 2.0. > This API is available at https://svn.apache.org/repos/asf/incubator/ > servicemix/branches/servicemix-4.0/api > > So here a few key changes: >* clean integration with OSGi >* the NormalizedMessage can contain not only XML >* no more components >* no more JBI packaging (just use OSGi bundles) >* move the Channel to the Endpoint >* use push delivery instead of pulling exchanges >* introduce a single interface for identifying the Target of an > Exchange Excellent! Spot on. > As we remove components, everything goes down to the endpoint which > become a key feature. > > The endpoint must implement the Endpoint interface. In OSGi, the NMR > would listen to endpoints > registered in the OSGi registry and call the registry to register / > unregister the endpoints. > As part of the endpoint registration, the NMR would inject a Channel > into them, thus actually activating the > endpoint. I guess I could write a sequence diagram for that (anybody > knows a good tool for uml ?). > In a non OSGI environment, the Endpoint will be registered in the > Registry by calling the register method > somehow. RE: uml tool Bruce, I've struggled with the same. I actually run Parallels/VMWare+Visio, just to keep compatibility with others I have to interact with. FLOSS community desperately needs a architecture tool. > The Endpoint receives Exchange to be processed on the process method. > I think we should keep the JBI 1.0 semantics and the endpoint use the > same process as for JBI 1.0, which is > send the exchange back using the Channel (with the response / fault / > error / done). This will put the threading, > transactions and security burden on the container itself. Which > means it is easier to write JBI apps :-) +1 > Exchanges can be created using the Channel#createExchange method. > The only change I'd like to > integrate in the messaging API is to allow for non xml payloads and > maybe untyped attachments. The body > could be converted automatically to a given type if supported (I > think Camel does it nicely, so I'm thinking of > shamelessly copying the converter layer). I have added a few helper > methods on the exchanges and > messages (copy, copyFrom, ensureReReadable, display) to ease message > management. > I haven't looked at Camel converters, but would you consider adding a contentType and contentEncoding mimicing the headers of HTTP & SIP. The endpoint can then use the type and encoding to determine how to handle the content. > For the deployment part, there is no packaging anymore. One would > deploy an OSGi bundle that would > register the needed endpoints in the OSGi registry. For certain > types of endpoints, we may need an external > activation process (such as creating a server socket for listening to > HTTP requests) that may need to be shared > across endpoints of a given type. In such a case, you would deploy a > "component" that listens to new > endpoints implementing HttpEndpoint for example. When a new endpoint > is registered, the listener would > activate a server socket that could be shared across all http > endpoints. In a different way, if we have a BPEL > engine, the bpel "component" would listen for new bundles and look > for a specific file containing deployment > information. The component would register new endpoints in the OSGi > registry as needed (we could do that > for jaxws pojos using cxf for example). > So I said there is no more components, because this feature is not in > the api anymore, but we will certainly need > these components for some use cases. For simple endpoints, you > would not need any component at all. > Another benefit is that you can easily deploy a whole application > inside a single OSGi bundle. Using spring-osgi, > the bundle would just consist in a spring configuration file > containing the endpoints declaration and expose them > as OSGi services. sweet. > Of course, we need to write a JBI 1.0 compatibility layer, and we > could have an intermediate layer where SAs and > JBI components could be OSGi bundles directly, thus leveraging the > OSGi classloading mechanism. > > The thing I'm not completely sure about if the Target interface which > aims to identify the target of an exchange. > I'm thinking that some metadata are associated with endpoints (like > service name, interface name, wsdl > location, etc..). These metadatas could be used to retrieve targets > using the Registry. We could plug in different > mechanisms to query the metadata (simple lookup per id, policy based, > etc...). And the result itself could be > not only a single Endpoint, but could
Re: ServiceMix 4.0
On 8/22/07, Terry Cox <[EMAIL PROTECTED]> wrote: > > Interesting. > > We need to have a very serious chat about application lifecycles and > governance... > > Terry > And Federating...distribution of the NMR across n-platforms! -- Kit Plummer Nobody-in-Charge @ Black:Hole:Logic http://www.blackholelogic.com
Re: ServiceMix 4.0
On 8/22/07, Terry Cox <[EMAIL PROTECTED]> wrote:
> Interesting.
>
> We need to have a very serious chat about application lifecycles and
> governance...
Now is the time.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
Re: ServiceMix 4.0
Interesting. We need to have a very serious chat about application lifecycles and governance... Terry
Re: ServiceMix 4.0
On Aug 22, 2007, at 11:43 PM, Bruce Snyder wrote: On 8/22/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote: As I explained in the other thread, I've been working on a new API for ServiceMix 4.0. Hopefully this will serve as an input for JBI 2.0. This API is available at https://svn.apache.org/repos/asf/incubator/ servicemix/branches/servicemix-4.0/api So here a few key changes: * clean integration with OSGi * the NormalizedMessage can contain not only XML Nice! * no more components * no more JBI packaging (just use OSGi bundles) * move the Channel to the Endpoint * use push delivery instead of pulling exchanges This is an interesting change for sure. * introduce a single interface for identifying the Target of an Exchange How will this work? Can you explain this one a bit more? Basically, instead of having different ways to express how the exchange will be routed by the NMR (using the endpoint, the service name or the interface name), there would be only a single way to express the destination using a Reference object (not Target, sorry). These objects would represent either a specific endpoint, or a service by its name or interface name, or more complex policies that could be built. These objects would be looked up in the Registry using a single method. Depending on the metadata passed to this method, you would retrieve an object that you can use as the target. Btw, for simple use cases, we should avoid needing a service QName + endpoint name to uniquely identify an endpoint. An unique ID should be sufficient. Everything else should be optional. Hopefuly you would not have to deal with that the lookup directly and you would use spring beans factories for that, so that you can easily inject References and use them as target in your endpoints. As we remove components, everything goes down to the endpoint which become a key feature. The endpoint must implement the Endpoint interface. In OSGi, the NMR would listen to endpoints registered in the OSGi registry and call the registry to register / unregister the endpoints. As part of the endpoint registration, the NMR would inject a Channel into them, thus actually activating the endpoint. I guess I could write a sequence diagram for that (anybody knows a good tool for uml ?). I've been trying to find some good UML software for a while - something that doesn't cost an arm and a leg, that generates sequence diagrams (IMO, these are invaluable!) from code and that runs on MacOS X. Anyone know of something that meets this criteria? In a non OSGI environment, the Endpoint will be registered in the Registry by calling the register method somehow. Is there any interoperability between the OSGi registry and a UDDI registry? Not really. But i'm sure we could add that as an optional feature if needed (but does anyone really need to use a UDDI registry?) OSGi registry contains services implementing a java interface with some associated metadata, while UDDI contains xml document (and mainly WSDL in our use case). They can complement together, but I'd really want to keep WSDL as completely optional. The Endpoint receives Exchange to be processed on the process method. I think we should keep the JBI 1.0 semantics and the endpoint use the same process as for JBI 1.0, which is send the exchange back using the Channel (with the response / fault / error / done). This will put the threading, transactions and security burden on the container itself. Which means it is easier to write JBI apps :-) This is exactly the architecture we need - a much cleaner separation. Exchanges can be created using the Channel#createExchange method. The only change I'd like to integrate in the messaging API is to allow for non xml payloads and maybe untyped attachments. The body could be converted automatically to a given type if supported (I think Camel does it nicely, so I'm thinking of shamelessly copying the converter layer). I have added a few helper methods on the exchanges and messages (copy, copyFrom, ensureReReadable, display) to ease message management. Very nice, sounds similar to Spring convenience classes. For the deployment part, there is no packaging anymore. One would deploy an OSGi bundle that would register the needed endpoints in the OSGi registry. For certain types of endpoints, we may need an external activation process (such as creating a server socket for listening to HTTP requests) that may need to be shared across endpoints of a given type. In such a case, you would deploy a "component" that listens to new endpoints implementing HttpEndpoint for example. When a new endpoint is registered, the listener would activate a server socket that could be shared across all http endpoints. In a different way, if we have a BPEL engine, the bpel "component" would listen for new bundles and look for a specific file containing deployment information. The component would registe
Re: ServiceMix 4.0
On 8/22/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote: > As I explained in the other thread, I've been working on a new API > for ServiceMix 4.0. > Hopefully this will serve as an input for JBI 2.0. > This API is available at https://svn.apache.org/repos/asf/incubator/ > servicemix/branches/servicemix-4.0/api > > So here a few key changes: >* clean integration with OSGi >* the NormalizedMessage can contain not only XML Nice! >* no more components >* no more JBI packaging (just use OSGi bundles) >* move the Channel to the Endpoint >* use push delivery instead of pulling exchanges This is an interesting change for sure. >* introduce a single interface for identifying the Target of an > Exchange How will this work? Can you explain this one a bit more? > As we remove components, everything goes down to the endpoint which > become a key feature. > > The endpoint must implement the Endpoint interface. In OSGi, the NMR > would listen to endpoints > registered in the OSGi registry and call the registry to register / > unregister the endpoints. > As part of the endpoint registration, the NMR would inject a Channel > into them, thus actually activating the > endpoint. I guess I could write a sequence diagram for that (anybody > knows a good tool for uml ?). I've been trying to find some good UML software for a while - something that doesn't cost an arm and a leg, that generates sequence diagrams (IMO, these are invaluable!) from code and that runs on MacOS X. Anyone know of something that meets this criteria? > In a non OSGI environment, the Endpoint will be registered in the > Registry by calling the register method > somehow. Is there any interoperability between the OSGi registry and a UDDI registry? > The Endpoint receives Exchange to be processed on the process method. > I think we should keep the JBI 1.0 semantics and the endpoint use the > same process as for JBI 1.0, which is > send the exchange back using the Channel (with the response / fault / > error / done). This will put the threading, > transactions and security burden on the container itself. Which > means it is easier to write JBI apps :-) This is exactly the architecture we need - a much cleaner separation. > Exchanges can be created using the Channel#createExchange method. > The only change I'd like to > integrate in the messaging API is to allow for non xml payloads and > maybe untyped attachments. The body > could be converted automatically to a given type if supported (I > think Camel does it nicely, so I'm thinking of > shamelessly copying the converter layer). I have added a few helper > methods on the exchanges and > messages (copy, copyFrom, ensureReReadable, display) to ease message > management. Very nice, sounds similar to Spring convenience classes. > For the deployment part, there is no packaging anymore. One would > deploy an OSGi bundle that would > register the needed endpoints in the OSGi registry. For certain > types of endpoints, we may need an external > activation process (such as creating a server socket for listening to > HTTP requests) that may need to be shared > across endpoints of a given type. In such a case, you would deploy a > "component" that listens to new > endpoints implementing HttpEndpoint for example. When a new endpoint > is registered, the listener would > activate a server socket that could be shared across all http > endpoints. In a different way, if we have a BPEL > engine, the bpel "component" would listen for new bundles and look > for a specific file containing deployment > information. The component would register new endpoints in the OSGi > registry as needed (we could do that > for jaxws pojos using cxf for example). > So I said there is no more components, because this feature is not in > the api anymore, but we will certainly need > these components for some use cases. For simple endpoints, you > would not need any component at all. > Another benefit is that you can easily deploy a whole application > inside a single OSGi bundle. Using spring-osgi, > the bundle would just consist in a spring configuration file > containing the endpoints declaration and expose them > as OSGi services. I'm not sure I understand this completely. Is this a type of interceptor or am I misunderstanding you? > Of course, we need to write a JBI 1.0 compatibility layer, and we > could have an intermediate layer where SAs and > JBI components could be OSGi bundles directly, thus leveraging the > OSGi classloading mechanism. Yep. > The thing I'm not completely sure about if the Target interface which > aims to identify the target of an exchange. > I'm thinking that some metadata are associated with endpoints (like > service name, interface name, wsdl > location, etc..). These metadatas could be used to retrieve targets > using the Registry. We could plug in different > mechanisms to query the metadata (simple lookup per id, policy based, > etc...). And the re
Re: Roadmap
On Aug 22, 2007, at 11:26 PM, Bruce Snyder wrote:
On 8/22/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote:
I'd like to start a discussion on ServiceMix roadmap.
Yay!
On the short term, hopefully the Apache Board will approve ServiceMix
gradation as a TLP at the end of the month (the board meeting is on
28th of August). Once done, we should start moving the resources to
their new locations (servicemix.apache.org). At the same time, we
may want to release a 3.1.2 (removing the incubator disclaimers) and
a 3.2. I think we can plan on 17/09 for 3.1.2 and 01/10 for 3.2.
I agree that released 3.1.2 as the first release as a TLP is a good
plan. Looks like we've got some work to do to get 3.2 out the door by
October (http://tinyurl.com/2cbduz) and I've got some additional
issues that I need to file and work to do for the archetypes. There
seem to be a handful of smallish bugs there.
On the middle term, I'd like to start working on ServiceMix 4.0. We
already discussed that a bit and the key points is OSGi. I have been
experimenting a bit in some branches on svn and I really think OSGi
will provide the needed platform to base ServiceMix 4.0 on. At the
same time, I have been working on a new API for ServiceMix 4.0 which
is available at https://svn.apache.org/repos/asf/incubator/
servicemix/branches/servicemix-4.0/api. This is work in progress and
I'd like feedback on it as much as possible. I will start a separate
thread about ServiceMix 4.0.
I haven't had the time to look at your OSGi work since back in May
when we were at JavaOne so I'll take a look at this. I'd also like to
make sure that we document the new APIs much better than the existing
stuff. One of the biggest shortcomings currently is Javadoc and
comments to provide others an understanding of the code.
I know. I really plan on documenting the 4.0 API as much as possible.
But we need to flesh out the ideas first ;-)
On the long term, I'd like ServiceMix to support JBI 2.0 and SCA.
It will obviously depend on when JBI 2.0 spec is released...
In addition, I'd like to create more formal thread pooling support
package for SMX and I think that the 4.0 branch is the best place to
do this work.
What do you have in mind more precisely? In the 4.0 related thread,
I explain that I'd like to get rid of components (at least, they
would not be
a mandatory part anymore in some cases). This implies that all the
thread
pool support will be managed by the container on a per endpoint basis.
But I won't be starting work on this until we have a
good handle on the 3.1.2 and 3.2 releases.
I have also begun work on providing better Javadocs and comments in
the new servicemix-jms consumer and provider endpoints. Once this is
complete I will begin to doc the new servicemix-http consumer and
provider endpoints. This is all a work in progress that I will just
continually check in as I go. I suppose I should file an issue to
track this work as it is committed.
I was also digging around today in the activemq-web-console wondering
about getting it running in SMX for monitoring destinations.
There is the servicemix-web-console which should do something like that.
We also have some hyperic plugins somewhere in JIRA...
On a
related note, when are we planning on upgrading ActiveMQ? Are we
waiting for SMX 4.0?
Well, as soon as AMQ 5.0 is released we should upgrade. I'm also
thinking about
upgrading to geronimo 2.0 and the new transaction manager / connector
(this would
need a Jencks 2.1 release too).
Guillaume
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61EG;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
Re: Servicemix ILog JRules
I have never used JRules, so I can't really help on this part. I guess you should try to understand how the drools component work (or try the hello world se tutorial). It should be a good basis for building a SE. Cheers, Guillaume Nodet On Aug 22, 2007, at 9:44 PM, Manjunath ShankaraReddy wrote: I am Using ILog Jrules( Rules Engine) and Servicemix ESB. I want to integrate ILOG JRules with servicemix. I am planning to create Component in Servicemix similar to Servicemix-Drools that can integrate with Jrules. Can anyone please suggest how to approach this problem?. Your help is appreciated.
ServiceMix 4.0
As I explained in the other thread, I've been working on a new API for ServiceMix 4.0. Hopefully this will serve as an input for JBI 2.0. This API is available at https://svn.apache.org/repos/asf/incubator/ servicemix/branches/servicemix-4.0/api So here a few key changes: * clean integration with OSGi * the NormalizedMessage can contain not only XML * no more components * no more JBI packaging (just use OSGi bundles) * move the Channel to the Endpoint * use push delivery instead of pulling exchanges * introduce a single interface for identifying the Target of an Exchange As we remove components, everything goes down to the endpoint which become a key feature. The endpoint must implement the Endpoint interface. In OSGi, the NMR would listen to endpoints registered in the OSGi registry and call the registry to register / unregister the endpoints. As part of the endpoint registration, the NMR would inject a Channel into them, thus actually activating the endpoint. I guess I could write a sequence diagram for that (anybody knows a good tool for uml ?). In a non OSGI environment, the Endpoint will be registered in the Registry by calling the register method somehow. The Endpoint receives Exchange to be processed on the process method. I think we should keep the JBI 1.0 semantics and the endpoint use the same process as for JBI 1.0, which is send the exchange back using the Channel (with the response / fault / error / done). This will put the threading, transactions and security burden on the container itself. Which means it is easier to write JBI apps :-) Exchanges can be created using the Channel#createExchange method. The only change I'd like to integrate in the messaging API is to allow for non xml payloads and maybe untyped attachments. The body could be converted automatically to a given type if supported (I think Camel does it nicely, so I'm thinking of shamelessly copying the converter layer). I have added a few helper methods on the exchanges and messages (copy, copyFrom, ensureReReadable, display) to ease message management. For the deployment part, there is no packaging anymore. One would deploy an OSGi bundle that would register the needed endpoints in the OSGi registry. For certain types of endpoints, we may need an external activation process (such as creating a server socket for listening to HTTP requests) that may need to be shared across endpoints of a given type. In such a case, you would deploy a "component" that listens to new endpoints implementing HttpEndpoint for example. When a new endpoint is registered, the listener would activate a server socket that could be shared across all http endpoints. In a different way, if we have a BPEL engine, the bpel "component" would listen for new bundles and look for a specific file containing deployment information. The component would register new endpoints in the OSGi registry as needed (we could do that for jaxws pojos using cxf for example). So I said there is no more components, because this feature is not in the api anymore, but we will certainly need these components for some use cases. For simple endpoints, you would not need any component at all. Another benefit is that you can easily deploy a whole application inside a single OSGi bundle. Using spring-osgi, the bundle would just consist in a spring configuration file containing the endpoints declaration and expose them as OSGi services. Of course, we need to write a JBI 1.0 compatibility layer, and we could have an intermediate layer where SAs and JBI components could be OSGi bundles directly, thus leveraging the OSGi classloading mechanism. The thing I'm not completely sure about if the Target interface which aims to identify the target of an exchange. I'm thinking that some metadata are associated with endpoints (like service name, interface name, wsdl location, etc..). These metadatas could be used to retrieve targets using the Registry. We could plug in different mechanisms to query the metadata (simple lookup per id, policy based, etc...). And the result itself could be not only a single Endpoint, but could include some policies like: load balance between all the endpoint implementing the given interface, etc Also, I think Target should be injected on Endpoints using spring, so you would look up a targe using a spring bean factory (or multiple ones): or The API is quite open right now, so any ideas welcome. I think i covered the main areas of the API. The main goal is OSGi and leveraging it as much as possible. There are still some gray areas: what about the start/stop/shutdown lifecycle which may be needed in some cases as I discovered recently (when you want to gracefully shutdown a jms consumer without loosing the ongoing messages for example). I also want to give due credits to James, which has been working with me on that. Remember
Roadmap
I'd like to start a discussion on ServiceMix roadmap. On the short term, hopefully the Apache Board will approve ServiceMix gradation as a TLP at the end of the month (the board meeting is on 28th of August). Once done, we should start moving the resources to their new locations (servicemix.apache.org). At the same time, we may want to release a 3.1.2 (removing the incubator disclaimers) and a 3.2. I think we can plan on 17/09 for 3.1.2 and 01/10 for 3.2. On the middle term, I'd like to start working on ServiceMix 4.0. We already discussed that a bit and the key points is OSGi. I have been experimenting a bit in some branches on svn and I really think OSGi will provide the needed platform to base ServiceMix 4.0 on. At the same time, I have been working on a new API for ServiceMix 4.0 which is available at https://svn.apache.org/repos/asf/incubator/ servicemix/branches/servicemix-4.0/api. This is work in progress and I'd like feedback on it as much as possible. I will start a separate thread about ServiceMix 4.0. On the long term, I'd like ServiceMix to support JBI 2.0 and SCA. It will obviously depend on when JBI 2.0 spec is released... Ideas, opinions? Cheers, Guillaume Nodet
[jira] Commented: (SM-1039) Publication of a consumer HTTP endpoint with classpath-provided WSDL file doesn't publish WSDL file
[
https://issues.apache.org/activemq/browse/SM-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39992
]
Philipp Rossmanith commented on SM-1039:
Workaround: Give the publishing endpoint the same service and endpoint name as
specified for servicemix-http service unit and WSDL file.
> Publication of a consumer HTTP endpoint with classpath-provided WSDL file
> doesn't publish WSDL file
> ---
>
> Key: SM-1039
> URL: https://issues.apache.org/activemq/browse/SM-1039
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-http
> Environment: ServiceMix 3.1.1, Windows
>Reporter: Philipp Rossmanith
>Priority: Minor
>
> Trying to publish an HTTP consumer endpoint with a classpath-supplied WSDL
> connecting to a servicemix.xml-configured publisher, the WSDL file doesn't
> show at the corresponding URL
> http://localhost:8192/IMMessageNotificationService/main.wsdl.
> Proposed solution:
>
> It seems the problem comes from the HttpEndpoint#getTargetPortType method.
> This method tries to find the *target* PortType. And the problem is that the
> target PortType (or interface QName) is not the same as the one exposed by
> servicemix-http. Somehow, they need to be matched.
> Maybe the getTargetPortType should be a series of
>if (portType == null && xxx) {
> ...
>}
> rather than if / else if.
> See also:
>
> Thread
> http://www.nabble.com/servicemix-http---classpath-supplied-WSDL-file-not-visible-tf4286826s12049.html
> (subject: servicemix-http - classpath-supplied WSDL file not visible)
> Additional information:
> ==
> The setup is:
> HTTP consumer EP --> publisher EP
> Deployment units have been created with Maven. Service and endpoint supplied
> in the servicemix-http xbean.xml*) match the ones supplied in the WSDL
> file**), setting the service name to :
> and setting the endpoint name to the value of the port's name. The WSDL file
> is present at the top-level in the ZIP-file for the SU.
> *)
>
> http://servicemix.apache.org/http/1.0";
> xmlns:mag="http://mag.icing.eu/notification/1.0";
>
> xmlns:csapi="http://www.csapi.org/wsdl/parlayx/multimedia_messaging/noti
> fication/v2_0/service"
> xmlns:pub="http://iisys.icing.eu/publisher/1.0";
>
> xmlns:impl="http://www.csapi.org/wsdl/parlayx/multimedia_messaging/notif
> ication/v2_0/service">
>
> .
>
> endpoint="IMMessageNotification" role="consumer"
>
> locationURI="http://0.0.0.0:8192/IMMessageNotificationService/";
> soap="true"
> wsdlResource="classpath:IMMessageNotification.wsdl"
> targetService="pub:IMMessagePublisher"
> targetEndpoint="ep" />
>
> **)
>
> targetNamespace="http://www.csapi.org/wsdl/parlayx/multimedia_messaging/
> notification/v2_0/service" ...>
> ...
>
>binding="impl:IMMessageNotificationSoapBinding"
> name="IMMessageNotification">
>location="http://0.0.0.0:8192/IMMessageNotificationService/"; />
>
>
> ...
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-1039) Publication of a consumer HTTP endpoint with classpath-provided WSDL file doesn't publish WSDL file
Publication of a consumer HTTP endpoint with classpath-provided WSDL file
doesn't publish WSDL file
---
Key: SM-1039
URL: https://issues.apache.org/activemq/browse/SM-1039
Project: ServiceMix
Issue Type: Bug
Components: servicemix-http
Environment: ServiceMix 3.1.1, Windows
Reporter: Philipp Rossmanith
Priority: Minor
Trying to publish an HTTP consumer endpoint with a classpath-supplied WSDL
connecting to a servicemix.xml-configured publisher, the WSDL file doesn't show
at the corresponding URL
http://localhost:8192/IMMessageNotificationService/main.wsdl.
Proposed solution:
It seems the problem comes from the HttpEndpoint#getTargetPortType method.
This method tries to find the *target* PortType. And the problem is that the
target PortType (or interface QName) is not the same as the one exposed by
servicemix-http. Somehow, they need to be matched.
Maybe the getTargetPortType should be a series of
if (portType == null && xxx) {
...
}
rather than if / else if.
See also:
Thread
http://www.nabble.com/servicemix-http---classpath-supplied-WSDL-file-not-visible-tf4286826s12049.html
(subject: servicemix-http - classpath-supplied WSDL file not visible)
Additional information:
==
The setup is:
HTTP consumer EP --> publisher EP
Deployment units have been created with Maven. Service and endpoint supplied in
the servicemix-http xbean.xml*) match the ones supplied in the WSDL file**),
setting the service name to : and setting
the endpoint name to the value of the port's name. The WSDL file is present at
the top-level in the ZIP-file for the SU.
*)
http://servicemix.apache.org/http/1.0";
xmlns:mag="http://mag.icing.eu/notification/1.0";
xmlns:csapi="http://www.csapi.org/wsdl/parlayx/multimedia_messaging/noti
fication/v2_0/service"
xmlns:pub="http://iisys.icing.eu/publisher/1.0";
xmlns:impl="http://www.csapi.org/wsdl/parlayx/multimedia_messaging/notif
ication/v2_0/service">
.
http://0.0.0.0:8192/IMMessageNotificationService/";
soap="true"
wsdlResource="classpath:IMMessageNotification.wsdl"
targetService="pub:IMMessagePublisher"
targetEndpoint="ep" />
**)
http://www.csapi.org/wsdl/parlayx/multimedia_messaging/
notification/v2_0/service" ...>
...
http://0.0.0.0:8192/IMMessageNotificationService/"; />
...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: CXF Build Error
Thanks Guillaume. Best Regards Freeman Guillaume Nodet wrote: I thought they were already included in the build and I have added them to the distribution some time ago. As this was causing the build to break, I have added these two components to the build. On 8/22/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote: Btw, what about adding them to the build now ? Cheers, Guillaume Nodet On Aug 22, 2007, at 4:25 AM, Freeman Fang wrote: Hi Gordon, The cxf-bc and cxf-se is in progress now, so these two modules are not added in serviceengines and bindingcomponents modules list, so you cann't download org.apache.servicemix:servicemix-cxf-se from website now. The work around is go into trunk/deployables/serviceengines/ servicemix-cxf-se and run "mvn install" to build org.apache.servicemix:servicemix-cxf-se yourself. Btw, you should be able to download it from website very soon. Best Regards Freeman Gordon Dickens wrote: Hello, I am getting a build error today from the latest code from SVN: [ERROR] BUILD ERROR [INFO] - --- [INFO] Failed to resolve artifact. GroupId: org.apache.servicemix ArtifactId: servicemix-cxf-se Version: 3.2-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix - DartifactId=servicemix-cxf-se \ -Dversion=3.2-incubating-SNAPSHOT -Dclassifier=installer - Dpackaging=zip -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.servic emix -DartifactId=servicemix-cxf-se \ -Dversion=3.2-incubating-SNAPSHOT -Dclassifier=installer - Dpackaging=zip -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] org.apache.servicemix:servicemix-cxf-se:zip:3.2-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), servicemix-m2-repo (http://svn.apache.org/repos/asf/incubator/ servicemix/m2-repo), apache.snapshots (http://svn.apache.org/maven-snapshot-repository), codehaus (http://repository.codehaus.org), apache-incubating (http://people.apache.org/repo/m2-incubating- repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot- repository) Any thoughts? Thanks, Gordon Dickens
Re: CXF Build Error
I thought they were already included in the build and I have added them to the distribution some time ago. As this was causing the build to break, I have added these two components to the build. On 8/22/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote: > Btw, what about adding them to the build now ? > > Cheers, > Guillaume Nodet > > On Aug 22, 2007, at 4:25 AM, Freeman Fang wrote: > > > Hi Gordon, > > > > The cxf-bc and cxf-se is in progress now, so these two modules are > > not added in serviceengines and bindingcomponents modules list, so > > you cann't download org.apache.servicemix:servicemix-cxf-se from > > website now. > > The work around is go into trunk/deployables/serviceengines/ > > servicemix-cxf-se and run "mvn install" to build > > org.apache.servicemix:servicemix-cxf-se yourself. > > Btw, you should be able to download it from website very soon. > > > > Best Regards > > Freeman > > > > Gordon Dickens wrote: > >> Hello, > >> > >> I am getting a build error today from the latest code from SVN: > >> > >> [ERROR] BUILD ERROR > >> [INFO] > >> - > >> --- > >> [INFO] Failed to resolve artifact. > >> > >> GroupId: org.apache.servicemix > >> ArtifactId: servicemix-cxf-se > >> Version: 3.2-incubating-SNAPSHOT > >> > >> Reason: Unable to download the artifact from any repository > >> > >> Try downloading the file manually from the project website. > >> > >> Then, install it using the command: > >>mvn install:install-file -DgroupId=org.apache.servicemix - > >> DartifactId=servicemix-cxf-se \ > >>-Dversion=3.2-incubating-SNAPSHOT -Dclassifier=installer - > >> Dpackaging=zip -Dfile=/path/to/file > >> Alternatively, if you host your own repository you can deploy the > >> file there: mvn deploy:deploy-file -DgroupId=org.apache.servic > >> emix -DartifactId=servicemix-cxf-se \ > >>-Dversion=3.2-incubating-SNAPSHOT -Dclassifier=installer - > >> Dpackaging=zip -Dfile=/path/to/file \ > >> -Durl=[url] -DrepositoryId=[id] > >> > >> > >> org.apache.servicemix:servicemix-cxf-se:zip:3.2-incubating-SNAPSHOT > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> servicemix-m2-repo (http://svn.apache.org/repos/asf/incubator/ > >> servicemix/m2-repo), > >> apache.snapshots (http://svn.apache.org/maven-snapshot-repository), > >> codehaus (http://repository.codehaus.org), > >> apache-incubating (http://people.apache.org/repo/m2-incubating- > >> repository), > >> apache-snapshots (http://people.apache.org/repo/m2-snapshot- > >> repository) > >> > >> > >> > >> Any thoughts? > >> > >> Thanks, > >> Gordon Dickens > >> > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Created: (SM-1038) http provider endpoint sends wrong Host header
http provider endpoint sends wrong Host header -- Key: SM-1038 URL: https://issues.apache.org/activemq/browse/SM-1038 Project: ServiceMix Issue Type: Bug Components: servicemix-http Affects Versions: 3.1.1 Environment: JDK 5.0 Reporter: Torsten Mielke Attachments: http-marshaler.patch The current ServiceMix http:provider endpoint uses jetty-client-6.1.5 library, which contains a bug fixed in their trunk. More infomation on http://fisheye.codehaus.org/browse/jetty-contrib/jetty/trunk/contrib/client/src/main/java/org/mortbay/jetty/client/HttpConnection.java?r1=374&r2=378. This causes wrong Host header in HTTP request. Actual Host header looks like this: Host: [EMAIL PROTECTED]//host.com:8080(1,0,0) Of course such header causes HTTP 400 response and endpoint cannot be used at all. To work around this bug deployables/bindingcomponents/servicemix-http/src/main/java/org/apache/servicemix/http/endpoints/DefaultHttpProviderMarshaler.java needs to get the attached patch applied. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CXF Build Error
Btw, what about adding them to the build now ? Cheers, Guillaume Nodet On Aug 22, 2007, at 4:25 AM, Freeman Fang wrote: Hi Gordon, The cxf-bc and cxf-se is in progress now, so these two modules are not added in serviceengines and bindingcomponents modules list, so you cann't download org.apache.servicemix:servicemix-cxf-se from website now. The work around is go into trunk/deployables/serviceengines/ servicemix-cxf-se and run "mvn install" to build org.apache.servicemix:servicemix-cxf-se yourself. Btw, you should be able to download it from website very soon. Best Regards Freeman Gordon Dickens wrote: Hello, I am getting a build error today from the latest code from SVN: [ERROR] BUILD ERROR [INFO] - --- [INFO] Failed to resolve artifact. GroupId: org.apache.servicemix ArtifactId: servicemix-cxf-se Version: 3.2-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix - DartifactId=servicemix-cxf-se \ -Dversion=3.2-incubating-SNAPSHOT -Dclassifier=installer - Dpackaging=zip -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.servic emix -DartifactId=servicemix-cxf-se \ -Dversion=3.2-incubating-SNAPSHOT -Dclassifier=installer - Dpackaging=zip -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] org.apache.servicemix:servicemix-cxf-se:zip:3.2-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), servicemix-m2-repo (http://svn.apache.org/repos/asf/incubator/ servicemix/m2-repo), apache.snapshots (http://svn.apache.org/maven-snapshot-repository), codehaus (http://repository.codehaus.org), apache-incubating (http://people.apache.org/repo/m2-incubating- repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot- repository) Any thoughts? Thanks, Gordon Dickens
