Re: [VOTE] Release ServiceMix 3.1
Guillaume Nodet wrote: Just a note: *everyone* is encouraged to download, try and vote, not only developers or PPMCers (thought their vote would be non-binding). I see that AMQ 4.1 is not final (and therefore a snapshot is included in SM 3.1) - do you have a timeline on a 4.1 release? - Renaud
[jira] Commented: (SM-722) ExtendedXMLStreamReader strips whitespaces, which breaks servicemix-http when a SOAP invocation contains whitespace nodes
[
https://issues.apache.org/activemq/browse/SM-722?page=comments#action_37286 ]
Renaud Bruyeron commented on SM-722:
Sorry about this mess, I think jira saw something special in the code :)
Here's the code again:
{code:title=org.apache.servicemix.jbi.jaxp.ExtendedXMLStreamReader}
public int nextTag() throws XMLStreamException {
int eventType = next();
while((eventType == XMLStreamConstants.CHARACTERS && isWhiteSpace())
// skip whitespace
|| (eventType == XMLStreamConstants.CDATA && isWhiteSpace())
// skip whitespace
|| eventType == XMLStreamConstants.SPACE
|| eventType == XMLStreamConstants.PROCESSING_INSTRUCTION
|| eventType == XMLStreamConstants.COMMENT
) {
eventType = next();
}
if (eventType != XMLStreamConstants.START_ELEMENT && eventType !=
XMLStreamConstants.END_ELEMENT) {
throw new XMLStreamException("expected start or end tag",
getLocation());
}
return eventType;
}
{code}
> ExtendedXMLStreamReader strips whitespaces, which breaks servicemix-http when
> a SOAP invocation contains whitespace nodes
> -
>
> Key: SM-722
> URL: https://issues.apache.org/activemq/browse/SM-722
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-core
>Affects Versions: 3.0
>Reporter: Renaud Bruyeron
> Fix For: 3.0.1
>
>
> The problem is in the code below in ExtendedXMLStreamReader, which is used by
> SoapMarshaler to extract the SOAP message from a http invocation, and put it
> in a NormalizedMessage.
> I have a SOAP message that has things like this: . The
> whitespace is significant, and should not be trimmed, yet the message comes
> out as .
> Is there a reason for explicitely doing this?
> public int nextTag() throws XMLStreamException {
> int eventType = next();
>while((eventType == XMLStreamConstants.CHARACTERS && isWhiteSpace())
> // skip whitespace
>|| (eventType == XMLStreamConstants.CDATA && isWhiteSpace())
>// skip whitespace
>|| eventType == XMLStreamConstants.SPACE
>|| eventType == XMLStreamConstants.PROCESSING_INSTRUCTION
>|| eventType == XMLStreamConstants.COMMENT
>) {
>eventType = next();
>}
>if (eventType != XMLStreamConstants.START_ELEMENT && eventType !=
> XMLStreamConstants.END_ELEMENT) {
> throw new XMLStreamException("expected start or end tag",
> getLocation());
>}
>return eventType;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-722) ExtendedXMLStreamReader strips whitespaces, which breaks servicemix-http when a SOAP invocation contains whitespace nodes
ExtendedXMLStreamReader strips whitespaces, which breaks servicemix-http when a
SOAP invocation contains whitespace nodes
-
Key: SM-722
URL: https://issues.apache.org/activemq/browse/SM-722
Project: ServiceMix
Issue Type: Bug
Components: servicemix-core
Affects Versions: 3.0
Reporter: Renaud Bruyeron
Fix For: 3.0.1
The problem is in the code below in ExtendedXMLStreamReader, which is used by
SoapMarshaler to extract the SOAP message from a http invocation, and put it in
a NormalizedMessage.
I have a SOAP message that has things like this: . The
whitespace is significant, and should not be trimmed, yet the message comes out
as .
Is there a reason for explicitely doing this?
public int nextTag() throws XMLStreamException {
int eventType = next();
while((eventType == XMLStreamConstants.CHARACTERS && isWhiteSpace())
// skip whitespace
|| (eventType == XMLStreamConstants.CDATA && isWhiteSpace())
// skip whitespace
|| eventType == XMLStreamConstants.SPACE
|| eventType == XMLStreamConstants.PROCESSING_INSTRUCTION
|| eventType == XMLStreamConstants.COMMENT
) {
eventType = next();
}
if (eventType != XMLStreamConstants.START_ELEMENT && eventType !=
XMLStreamConstants.END_ELEMENT) {
throw new XMLStreamException("expected start or end tag",
getLocation());
}
return eventType;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-984) make the "slave" status of a broker available through JMX (in jdbc-master-slave mode)
make the "slave" status of a broker available through JMX (in jdbc-master-slave mode) - Key: AMQ-984 URL: https://issues.apache.org/activemq/browse/AMQ-984 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 4.1 Reporter: Renaud Bruyeron Priority: Minor Fix For: 4.1 Right now, it is not possible to know that a broker is in "Attempting to acquire the exclusive lock to become the Master broker" mode via JMX, even though this would be a natural place to find out. Do you think it would be possible to expose the DatabaseLocker or the JDBCPersistenceAdapter over JMX so that a simple boolean isMaster() can be queried? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-967) setting maximumRedeliveries to -1 is equivalent to maximumRedeliveries=0, but doc says otherwise
setting maximumRedeliveries to -1 is equivalent to maximumRedeliveries=0, but doc says otherwise Key: AMQ-967 URL: https://issues.apache.org/activemq/browse/AMQ-967 Project: ActiveMQ Issue Type: Bug Components: Connector Affects Versions: 4.0.2, 4.1 Reporter: Renaud Bruyeron Fix For: 4.0.3, 4.1 Attachments: patch.txt The documentation (http://incubator.apache.org/activemq/resource-adapter-properties.html) suggests that setting maximumRedeliveries to -1 means "no maximum", i.e. infinite retries. However, my tests (and the code) show that -1 is equivalent to 0 (i.e. no redelivery). The patch attempts to fix this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-950) createConnector="false" has no effect on Tiger
[
https://issues.apache.org/activemq/browse/AMQ-950?page=comments#action_37078 ]
Renaud Bruyeron commented on AMQ-950:
-
me again,
sorry, I meant to say that I plan to look into this issue with the latest
snapshots - I don't have time right now but it is on my todo to provide more
info on the problem I am seeing ;-)
> createConnector="false" has no effect on Tiger
> --
>
> Key: AMQ-950
> URL: https://issues.apache.org/activemq/browse/AMQ-950
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 4.1
> Environment: JDK 1.5.0_08
>Reporter: Renaud Bruyeron
>Priority: Minor
> Fix For: 4.1
>
>
> On Tiger, activemq always creates a rmi connector on port 1099 no matter what
> I do with -Djavax.management... and
> In particular, setting createConnector="false" should prevent AMQ from
> setting up its own connector, but it does not.
> The problem is in the findMBeanServer() method:
> if (result == null && createMBeanServer) {
> result = createMBeanServer();
> }
> else {
> createConnector(result);
> }
> result is not null on Tiger with useJmx="true", and createConnector is not
> protected by if(createConnector) like it is on the non-Tiger flow.
> The fix (I think) is simply to do this:
> if (result == null && createMBeanServer) {
> result = createMBeanServer();
> }
> else {
> if(createConnector){
> createConnector(result);
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-950) createConnector="false" has no effect on Tiger
[
https://issues.apache.org/activemq/browse/AMQ-950?page=comments#action_37077 ]
Renaud Bruyeron commented on AMQ-950:
-
Hi James,
this looks correct to me, however I can't play with the latest 4.1 snapshots
because they break with servicemix-3.0 final
(something wrong with jencks and the RA). It broke in the last 3 weeks
(snapshot from 20060830 works).
> createConnector="false" has no effect on Tiger
> --
>
> Key: AMQ-950
> URL: https://issues.apache.org/activemq/browse/AMQ-950
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 4.1
> Environment: JDK 1.5.0_08
>Reporter: Renaud Bruyeron
>Priority: Minor
> Fix For: 4.1
>
>
> On Tiger, activemq always creates a rmi connector on port 1099 no matter what
> I do with -Djavax.management... and
> In particular, setting createConnector="false" should prevent AMQ from
> setting up its own connector, but it does not.
> The problem is in the findMBeanServer() method:
> if (result == null && createMBeanServer) {
> result = createMBeanServer();
> }
> else {
> createConnector(result);
> }
> result is not null on Tiger with useJmx="true", and createConnector is not
> protected by if(createConnector) like it is on the non-Tiger flow.
> The fix (I think) is simply to do this:
> if (result == null && createMBeanServer) {
> result = createMBeanServer();
> }
> else {
> if(createConnector){
> createConnector(result);
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-477) servicemix-http does not reply with HTTP 202 when processing "oneway" SOAP messages
[ https://issues.apache.org/activemq/browse/SM-477?page=all ] Renaud Bruyeron updated SM-477: --- Attachment: patch.txt this patch fixes the issue above: when the exchange is Done (i.e. in-only or robust-in-only) we send a HTTP 202 instead of the default HTTP 200. > servicemix-http does not reply with HTTP 202 when processing "oneway" SOAP > messages > --- > > Key: SM-477 > URL: https://issues.apache.org/activemq/browse/SM-477 > Project: ServiceMix > Type: Bug > Components: servicemix-http > Versions: 3.0-M2 > Environment: See > http://www.nabble.com/support-for-oneway-MEP-in-servicemix-http---tf1871975.html > When using Axis 1.4 to post a oneway SOAP message, servicemix-http replies > with a HTTP 200, which the client interprets as a response. It should reply > with 202 which is the right reply for async oneway processing. > I am not sure on the fix though: on what criteria should sm-http decide what > http code to return? is it on the MEP declared on the endpoint, or on the > wsdl, or both? > Reporter: Renaud Bruyeron > Fix For: 3.0 > Attachments: patch.txt > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: support for oneway MEP in servicemix-http ?
ok I've hacked up something, but I can't test it because I can't build trunk. Any idea ? (why is it so friggin' hard to build this thing btw?) Missing: -- 1) org.apache.servicemix.samples.wsdl-first:http-su:jar:3.0-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.samples.wsdl-first -DartifactId=http-su \ -Dversion=3.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.servicemix.samples.wsdl-first:sa:jbi-service-assembly:3.0-incubating-SNAPSHOT 2) org.apache.servicemix.samples.wsdl-first:http-su:jar:3.0-incubating-SNAPSHOT 2) org.apache.servicemix.samples.wsdl-first:jsr181-su:jar:3.0-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.samples.wsdl-first -DartifactId=jsr181-su \ -Dversion=3.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.servicemix.samples.wsdl-first:sa:jbi-service-assembly:3.0-incubating-SNAPSHOT 2) org.apache.servicemix.samples.wsdl-first:jsr181-su:jar:3.0-incubating-SNAPSHOT -- 2 required artifacts are missing. for artifact: org.apache.servicemix.samples.wsdl-first:sa:jbi-service-assembly:3.0-incubating-SNAPSHOT from the specified remote repositories: central (http://ibiblio.org/maven2/), servicemix-m2-repo (http://servicemix.org/m2-repo), codehaus (http://repository.codehaus.org), apache.snapshots (http://people.apache.org/maven-snapshot-repository), codehaus.m1 (http://dist.codehaus.org), activemq-tmp-repo (http://people.apache.org/~chirino/incubator-activemq-4.0/maven2) Guillaume Nodet wrote: I do not really know which http code should be returned. I would have thought a 204 (NO_CONTENT) would be fine. Everything is handled in the o.a.s.http.processors.ConsumerProcessor class. I guess that just returning the 202 when there is no out message in the jbi exchange line 210 (either in-only, robust-in-only, or in-optional-out without response). Cheers, Guillaume Nodet On 6/30/06, Renaud Bruyeron <[EMAIL PROTECTED]> wrote: I could try to fix it, but I am not sure on the best way to do this... I am not even sure on the semantics here: in which case should we return a 202 ? Is it when the MEP is in-only, or when the WSDL says 'oneway', or both? I am willing to look into this, but I am not too sure on the "correct" fix. If you have any pointers/ideas, let me know. In the mean time, I'll create a jira for this. - Renaud Guillaume Nodet wrote: > I think you are right. A 202 code should be returned. > Could you raise a JIRA for that please ? > If you can provide a patch, that would be cool :) > > Cheers, > Guillaume Nodet > > On 6/30/06, Renaud Bruyeron <[EMAIL PROTECTED]> wrote: >> >> >> I am trying to send a oneway message into a http endpoint, but I am >> having trouble doing this. Here's the endpoint declaration: >> >> > endpoint="mms-service" >> role="consumer" >> soap="true" >> locationURI="http://localhost/mm7"; >> defaultMep="http://www.w3.org/2004/08/wsdl/in-only"; >> wsdlResource="classpath:wsdl/gwxms.wsdl"/> >> >> >> Notice the MEP is in-only. >> >> The proxied endpoint is actually a JMS queue: >> >> >endpoint="mms-service" >>role="provider" >>destinationStyle="queue" >>soap="true" >>jmsProviderDestinationName="queue.mms" >> jndiConnectionFactoryName="java:comp/env/jms/ConnectionFactory"/> >> >> I am using a Axis 1.4 client to send the message in (I must use Axis >> because I need proper SAAJ support). Because it is a oneway message, the >> client expects a HTTP 202 response. However servicemix-http only replies >> with HTTP 200, which means "synchronous" in HTTP/SOAP. >> The exchange is working ok (I see the mime message on the JMS queue), >> the trouble is with the http endpoint. >> >> Am I correct in setting up the MEP as in-only on the http:endpoint? Any >> idea on what the problem could be? (I suspect that http:endpoint should >> figure out from the WSDL that the message is oneway and return HTTP 202 >> accordingly, but I could be wrong). >> >> - Renaud >> >> >
Re: [HeadsUp] changes to the ServiceMixClient API to support simpler access via URIs
James Strachan wrote: The ServiceMixClient - if its dependency injected with a JBI container instance - The doco does not explain how to do this: "inject the JBI container". Most of the time I want to use the client I am inside a service unit deployed to a component like lwcontainer or http - I do not know how to get the reference to the container in the xbean.xml. I can do something like ((ComponentContextImpl) getContext()).getContainer() but this is ugly and wrong. What's the best way to go about this? - Renaud
[jira] Created: (SM-396) classloading issue in servicemix-jsr181 - thread context classloader not set to serviceunit classloader
classloading issue in servicemix-jsr181 - thread context classloader not set to serviceunit classloader --- Key: SM-396 URL: https://issues.apache.org/activemq/browse/SM-396 Project: ServiceMix Type: Bug Components: servicemix-jsr181 Versions: incubation Reporter: Renaud Bruyeron Attachments: patch.txt the registerService() method in Jsr181Endpoint is running with the servicemix classloader as the thread context loader, instead of the serviceunit classloader. This creates problems when xfire tries to load interface classes referred to by the @WebService(endpointInterface="...") annotation on the implementation class. These classes are loadable via the serviceunit classloader, but not via the main classloader. This is what I see during deployment of the soap-binding example: Couldn't find endpoint interface soap.AnnotatedSimpleService. Nested exception is java.lang.ClassNotFoundException: soap.AnnotatedSimpleService If I replace the TCL with ((XBeanServiceUnit) getServiceUnit()).getConfigurationClassLoader() right before the call to factory.create(serviceClass, ...) then all is well. The patch attached modifies the soap-binding example to deploy a jsr181-annotated service as well. This triggers the bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
