You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Scott Kurz (JIRA)" <de...@tuscany.apache.org> on 2009/03/10 14:14:50 UTC
[jira] Created: (TUSCANY-2914) issues w/ StAX processing in
JMSBindingProcessor
issues w/ StAX processing in JMSBindingProcessor
------------------------------------------------
Key: TUSCANY-2914
URL: https://issues.apache.org/jira/browse/TUSCANY-2914
Project: Tuscany
Issue Type: Bug
Components: Java SCA JMS Binding Extension
Reporter: Scott Kurz
Priority: Minor
I'm looking at JMSBindingProcessor.read(), and the way the read() method relies on itself to advance the cursor past its children's END_ELEMENT seems to be a problem.
The code is:
while (!endFound) {
int fg = reader.next();
switch (fg) {
case START_ELEMENT:
String elementName = reader.getName().getLocalPart();
if ("destination".equals(elementName)) {
parseDestination(reader, jmsBinding);
} else if ("connectionFactory".equals(elementName)) {
parseConnectionFactory(reader, jmsBinding);
....
} else {
....
}
reader.next(); // PROBLEM!
break;
For child element 'SubscriptionHeaders', I could write that as either:
<SubscriptionHeaders.../>
OR
<SubscriptionHeaders...>....</SubscriptionHeaders>
OR
<SubscriptionHeaders..... >
</SubscriptionHeaders>
The first two shouldn't be a problem, I start with a START_ELEMENT and then the next() back in read() advances me over the END_ELEMENT event. However, the third is a problem, since there is a CHARACTERS event in the middle, in which case the next() back in read() only takes me to the SubscriptionHeaders END_ELEMENT, though the code at this point can only deal with 'binding.jms' END_ELEMENT, (and since it doesn't get this, we get an error).
In general, it seems that to deal with this kind of thing, helper methods that parse a child element should be responsible for themselves advancing the cursor to their own child element's END_ELEMENT.
For what it's worth, I'm not sure how parseDestination() works either, it seems like parseDestinationProperties() is going to advance the cursor too far, but maybe I don't fully understand this scenario.
If I can get my build working, I'll post a recreate test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TUSCANY-2914) issues w/ StAX processing in
JMSBindingProcessor
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ramkumar Ramalingam resolved TUSCANY-2914.
------------------------------------------
Resolution: Fixed
Committed revision 755887 for 1.x
> issues w/ StAX processing in JMSBindingProcessor
> ------------------------------------------------
>
> Key: TUSCANY-2914
> URL: https://issues.apache.org/jira/browse/TUSCANY-2914
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA JMS Binding Extension
> Reporter: Scott Kurz
> Assignee: Ramkumar Ramalingam
> Priority: Minor
> Attachments: TUSCANY-2914.patch
>
>
> I'm looking at JMSBindingProcessor.read(), and the way the read() method relies on itself to advance the cursor past its children's END_ELEMENT seems to be a problem.
> The code is:
> while (!endFound) {
> int fg = reader.next();
> switch (fg) {
> case START_ELEMENT:
> String elementName = reader.getName().getLocalPart();
> if ("destination".equals(elementName)) {
> parseDestination(reader, jmsBinding);
> } else if ("connectionFactory".equals(elementName)) {
> parseConnectionFactory(reader, jmsBinding);
> ....
> } else {
> ....
> }
> reader.next(); // PROBLEM!
> break;
> For child element 'SubscriptionHeaders', I could write that as either:
> <SubscriptionHeaders.../>
> OR
> <SubscriptionHeaders...>....</SubscriptionHeaders>
> OR
> <SubscriptionHeaders..... >
> </SubscriptionHeaders>
> The first two shouldn't be a problem, I start with a START_ELEMENT and then the next() back in read() advances me over the END_ELEMENT event. However, the third is a problem, since there is a CHARACTERS event in the middle, in which case the next() back in read() only takes me to the SubscriptionHeaders END_ELEMENT, though the code at this point can only deal with 'binding.jms' END_ELEMENT, (and since it doesn't get this, we get an error).
> In general, it seems that to deal with this kind of thing, helper methods that parse a child element should be responsible for themselves advancing the cursor to their own child element's END_ELEMENT.
> For what it's worth, I'm not sure how parseDestination() works either, it seems like parseDestinationProperties() is going to advance the cursor too far, but maybe I don't fully understand this scenario.
> If I can get my build working, I'll post a recreate test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TUSCANY-2914) issues w/ StAX processing in
JMSBindingProcessor
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ramkumar Ramalingam reassigned TUSCANY-2914:
--------------------------------------------
Assignee: Ramkumar Ramalingam
> issues w/ StAX processing in JMSBindingProcessor
> ------------------------------------------------
>
> Key: TUSCANY-2914
> URL: https://issues.apache.org/jira/browse/TUSCANY-2914
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA JMS Binding Extension
> Reporter: Scott Kurz
> Assignee: Ramkumar Ramalingam
> Priority: Minor
>
> I'm looking at JMSBindingProcessor.read(), and the way the read() method relies on itself to advance the cursor past its children's END_ELEMENT seems to be a problem.
> The code is:
> while (!endFound) {
> int fg = reader.next();
> switch (fg) {
> case START_ELEMENT:
> String elementName = reader.getName().getLocalPart();
> if ("destination".equals(elementName)) {
> parseDestination(reader, jmsBinding);
> } else if ("connectionFactory".equals(elementName)) {
> parseConnectionFactory(reader, jmsBinding);
> ....
> } else {
> ....
> }
> reader.next(); // PROBLEM!
> break;
> For child element 'SubscriptionHeaders', I could write that as either:
> <SubscriptionHeaders.../>
> OR
> <SubscriptionHeaders...>....</SubscriptionHeaders>
> OR
> <SubscriptionHeaders..... >
> </SubscriptionHeaders>
> The first two shouldn't be a problem, I start with a START_ELEMENT and then the next() back in read() advances me over the END_ELEMENT event. However, the third is a problem, since there is a CHARACTERS event in the middle, in which case the next() back in read() only takes me to the SubscriptionHeaders END_ELEMENT, though the code at this point can only deal with 'binding.jms' END_ELEMENT, (and since it doesn't get this, we get an error).
> In general, it seems that to deal with this kind of thing, helper methods that parse a child element should be responsible for themselves advancing the cursor to their own child element's END_ELEMENT.
> For what it's worth, I'm not sure how parseDestination() works either, it seems like parseDestinationProperties() is going to advance the cursor too far, but maybe I don't fully understand this scenario.
> If I can get my build working, I'll post a recreate test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2914) issues w/ StAX processing in
JMSBindingProcessor
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ramkumar Ramalingam updated TUSCANY-2914:
-----------------------------------------
Attachment: TUSCANY-2914.patch
> issues w/ StAX processing in JMSBindingProcessor
> ------------------------------------------------
>
> Key: TUSCANY-2914
> URL: https://issues.apache.org/jira/browse/TUSCANY-2914
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA JMS Binding Extension
> Reporter: Scott Kurz
> Assignee: Ramkumar Ramalingam
> Priority: Minor
> Attachments: TUSCANY-2914.patch
>
>
> I'm looking at JMSBindingProcessor.read(), and the way the read() method relies on itself to advance the cursor past its children's END_ELEMENT seems to be a problem.
> The code is:
> while (!endFound) {
> int fg = reader.next();
> switch (fg) {
> case START_ELEMENT:
> String elementName = reader.getName().getLocalPart();
> if ("destination".equals(elementName)) {
> parseDestination(reader, jmsBinding);
> } else if ("connectionFactory".equals(elementName)) {
> parseConnectionFactory(reader, jmsBinding);
> ....
> } else {
> ....
> }
> reader.next(); // PROBLEM!
> break;
> For child element 'SubscriptionHeaders', I could write that as either:
> <SubscriptionHeaders.../>
> OR
> <SubscriptionHeaders...>....</SubscriptionHeaders>
> OR
> <SubscriptionHeaders..... >
> </SubscriptionHeaders>
> The first two shouldn't be a problem, I start with a START_ELEMENT and then the next() back in read() advances me over the END_ELEMENT event. However, the third is a problem, since there is a CHARACTERS event in the middle, in which case the next() back in read() only takes me to the SubscriptionHeaders END_ELEMENT, though the code at this point can only deal with 'binding.jms' END_ELEMENT, (and since it doesn't get this, we get an error).
> In general, it seems that to deal with this kind of thing, helper methods that parse a child element should be responsible for themselves advancing the cursor to their own child element's END_ELEMENT.
> For what it's worth, I'm not sure how parseDestination() works either, it seems like parseDestinationProperties() is going to advance the cursor too far, but maybe I don't fully understand this scenario.
> If I can get my build working, I'll post a recreate test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2914) issues w/ StAX processing in
JMSBindingProcessor
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ramkumar Ramalingam updated TUSCANY-2914:
-----------------------------------------
Attachment: (was: TUSCANY-2914.patch)
> issues w/ StAX processing in JMSBindingProcessor
> ------------------------------------------------
>
> Key: TUSCANY-2914
> URL: https://issues.apache.org/jira/browse/TUSCANY-2914
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA JMS Binding Extension
> Reporter: Scott Kurz
> Assignee: Ramkumar Ramalingam
> Priority: Minor
>
> I'm looking at JMSBindingProcessor.read(), and the way the read() method relies on itself to advance the cursor past its children's END_ELEMENT seems to be a problem.
> The code is:
> while (!endFound) {
> int fg = reader.next();
> switch (fg) {
> case START_ELEMENT:
> String elementName = reader.getName().getLocalPart();
> if ("destination".equals(elementName)) {
> parseDestination(reader, jmsBinding);
> } else if ("connectionFactory".equals(elementName)) {
> parseConnectionFactory(reader, jmsBinding);
> ....
> } else {
> ....
> }
> reader.next(); // PROBLEM!
> break;
> For child element 'SubscriptionHeaders', I could write that as either:
> <SubscriptionHeaders.../>
> OR
> <SubscriptionHeaders...>....</SubscriptionHeaders>
> OR
> <SubscriptionHeaders..... >
> </SubscriptionHeaders>
> The first two shouldn't be a problem, I start with a START_ELEMENT and then the next() back in read() advances me over the END_ELEMENT event. However, the third is a problem, since there is a CHARACTERS event in the middle, in which case the next() back in read() only takes me to the SubscriptionHeaders END_ELEMENT, though the code at this point can only deal with 'binding.jms' END_ELEMENT, (and since it doesn't get this, we get an error).
> In general, it seems that to deal with this kind of thing, helper methods that parse a child element should be responsible for themselves advancing the cursor to their own child element's END_ELEMENT.
> For what it's worth, I'm not sure how parseDestination() works either, it seems like parseDestinationProperties() is going to advance the cursor too far, but maybe I don't fully understand this scenario.
> If I can get my build working, I'll post a recreate test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2914) issues w/ StAX processing in
JMSBindingProcessor
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683059#action_12683059 ]
Ramkumar Ramalingam commented on TUSCANY-2914:
----------------------------------------------
Hi Scott,
This patch works well for most of the binding.jms elements. Looks like I have missed to handle the following elements...
<tuscany:wireFormat.jmsBytes/>
<tuscany:wireFormat.jmsText/>
<tuscany:wireFormat.jmsObject/>
<tuscany:wireFormat.jmsTextXML/>
within JMSBindingProcessor code. Will update the patch accordingly once I have a fix to handle these elements.
> issues w/ StAX processing in JMSBindingProcessor
> ------------------------------------------------
>
> Key: TUSCANY-2914
> URL: https://issues.apache.org/jira/browse/TUSCANY-2914
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA JMS Binding Extension
> Reporter: Scott Kurz
> Assignee: Ramkumar Ramalingam
> Priority: Minor
> Attachments: TUSCANY-2914.patch
>
>
> I'm looking at JMSBindingProcessor.read(), and the way the read() method relies on itself to advance the cursor past its children's END_ELEMENT seems to be a problem.
> The code is:
> while (!endFound) {
> int fg = reader.next();
> switch (fg) {
> case START_ELEMENT:
> String elementName = reader.getName().getLocalPart();
> if ("destination".equals(elementName)) {
> parseDestination(reader, jmsBinding);
> } else if ("connectionFactory".equals(elementName)) {
> parseConnectionFactory(reader, jmsBinding);
> ....
> } else {
> ....
> }
> reader.next(); // PROBLEM!
> break;
> For child element 'SubscriptionHeaders', I could write that as either:
> <SubscriptionHeaders.../>
> OR
> <SubscriptionHeaders...>....</SubscriptionHeaders>
> OR
> <SubscriptionHeaders..... >
> </SubscriptionHeaders>
> The first two shouldn't be a problem, I start with a START_ELEMENT and then the next() back in read() advances me over the END_ELEMENT event. However, the third is a problem, since there is a CHARACTERS event in the middle, in which case the next() back in read() only takes me to the SubscriptionHeaders END_ELEMENT, though the code at this point can only deal with 'binding.jms' END_ELEMENT, (and since it doesn't get this, we get an error).
> In general, it seems that to deal with this kind of thing, helper methods that parse a child element should be responsible for themselves advancing the cursor to their own child element's END_ELEMENT.
> For what it's worth, I'm not sure how parseDestination() works either, it seems like parseDestinationProperties() is going to advance the cursor too far, but maybe I don't fully understand this scenario.
> If I can get my build working, I'll post a recreate test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2914) issues w/ StAX processing in
JMSBindingProcessor
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ramkumar Ramalingam updated TUSCANY-2914:
-----------------------------------------
Attachment: TUSCANY-2914.patch
> issues w/ StAX processing in JMSBindingProcessor
> ------------------------------------------------
>
> Key: TUSCANY-2914
> URL: https://issues.apache.org/jira/browse/TUSCANY-2914
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA JMS Binding Extension
> Reporter: Scott Kurz
> Assignee: Ramkumar Ramalingam
> Priority: Minor
> Attachments: TUSCANY-2914.patch
>
>
> I'm looking at JMSBindingProcessor.read(), and the way the read() method relies on itself to advance the cursor past its children's END_ELEMENT seems to be a problem.
> The code is:
> while (!endFound) {
> int fg = reader.next();
> switch (fg) {
> case START_ELEMENT:
> String elementName = reader.getName().getLocalPart();
> if ("destination".equals(elementName)) {
> parseDestination(reader, jmsBinding);
> } else if ("connectionFactory".equals(elementName)) {
> parseConnectionFactory(reader, jmsBinding);
> ....
> } else {
> ....
> }
> reader.next(); // PROBLEM!
> break;
> For child element 'SubscriptionHeaders', I could write that as either:
> <SubscriptionHeaders.../>
> OR
> <SubscriptionHeaders...>....</SubscriptionHeaders>
> OR
> <SubscriptionHeaders..... >
> </SubscriptionHeaders>
> The first two shouldn't be a problem, I start with a START_ELEMENT and then the next() back in read() advances me over the END_ELEMENT event. However, the third is a problem, since there is a CHARACTERS event in the middle, in which case the next() back in read() only takes me to the SubscriptionHeaders END_ELEMENT, though the code at this point can only deal with 'binding.jms' END_ELEMENT, (and since it doesn't get this, we get an error).
> In general, it seems that to deal with this kind of thing, helper methods that parse a child element should be responsible for themselves advancing the cursor to their own child element's END_ELEMENT.
> For what it's worth, I'm not sure how parseDestination() works either, it seems like parseDestinationProperties() is going to advance the cursor too far, but maybe I don't fully understand this scenario.
> If I can get my build working, I'll post a recreate test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2914) issues w/ StAX processing in
JMSBindingProcessor
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682594#action_12682594 ]
Ramkumar Ramalingam commented on TUSCANY-2914:
----------------------------------------------
Hi Scott,
You are right, for this scenario its ideal to advance the cursor to their corresponding END_ELEMENT in the parser methods... like
parseDestination, parseConnectionFactory, parseActivationSpec, parseResponse ....... etc., Let me try to make local changes and see how it goes.
> issues w/ StAX processing in JMSBindingProcessor
> ------------------------------------------------
>
> Key: TUSCANY-2914
> URL: https://issues.apache.org/jira/browse/TUSCANY-2914
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA JMS Binding Extension
> Reporter: Scott Kurz
> Assignee: Ramkumar Ramalingam
> Priority: Minor
>
> I'm looking at JMSBindingProcessor.read(), and the way the read() method relies on itself to advance the cursor past its children's END_ELEMENT seems to be a problem.
> The code is:
> while (!endFound) {
> int fg = reader.next();
> switch (fg) {
> case START_ELEMENT:
> String elementName = reader.getName().getLocalPart();
> if ("destination".equals(elementName)) {
> parseDestination(reader, jmsBinding);
> } else if ("connectionFactory".equals(elementName)) {
> parseConnectionFactory(reader, jmsBinding);
> ....
> } else {
> ....
> }
> reader.next(); // PROBLEM!
> break;
> For child element 'SubscriptionHeaders', I could write that as either:
> <SubscriptionHeaders.../>
> OR
> <SubscriptionHeaders...>....</SubscriptionHeaders>
> OR
> <SubscriptionHeaders..... >
> </SubscriptionHeaders>
> The first two shouldn't be a problem, I start with a START_ELEMENT and then the next() back in read() advances me over the END_ELEMENT event. However, the third is a problem, since there is a CHARACTERS event in the middle, in which case the next() back in read() only takes me to the SubscriptionHeaders END_ELEMENT, though the code at this point can only deal with 'binding.jms' END_ELEMENT, (and since it doesn't get this, we get an error).
> In general, it seems that to deal with this kind of thing, helper methods that parse a child element should be responsible for themselves advancing the cursor to their own child element's END_ELEMENT.
> For what it's worth, I'm not sure how parseDestination() works either, it seems like parseDestinationProperties() is going to advance the cursor too far, but maybe I don't fully understand this scenario.
> If I can get my build working, I'll post a recreate test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2914) issues w/ StAX processing in
JMSBindingProcessor
Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683042#action_12683042 ]
Scott Kurz commented on TUSCANY-2914:
-------------------------------------
Hi Ram
Can't say I tested your patch, but I did look it over quick and it looks like a good way to do it. Advancing in parseBindingProperties(), to the parent's END_ELEMENT solves the problem for every element with a nested call to parseBindingProperties().
> issues w/ StAX processing in JMSBindingProcessor
> ------------------------------------------------
>
> Key: TUSCANY-2914
> URL: https://issues.apache.org/jira/browse/TUSCANY-2914
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA JMS Binding Extension
> Reporter: Scott Kurz
> Assignee: Ramkumar Ramalingam
> Priority: Minor
> Attachments: TUSCANY-2914.patch
>
>
> I'm looking at JMSBindingProcessor.read(), and the way the read() method relies on itself to advance the cursor past its children's END_ELEMENT seems to be a problem.
> The code is:
> while (!endFound) {
> int fg = reader.next();
> switch (fg) {
> case START_ELEMENT:
> String elementName = reader.getName().getLocalPart();
> if ("destination".equals(elementName)) {
> parseDestination(reader, jmsBinding);
> } else if ("connectionFactory".equals(elementName)) {
> parseConnectionFactory(reader, jmsBinding);
> ....
> } else {
> ....
> }
> reader.next(); // PROBLEM!
> break;
> For child element 'SubscriptionHeaders', I could write that as either:
> <SubscriptionHeaders.../>
> OR
> <SubscriptionHeaders...>....</SubscriptionHeaders>
> OR
> <SubscriptionHeaders..... >
> </SubscriptionHeaders>
> The first two shouldn't be a problem, I start with a START_ELEMENT and then the next() back in read() advances me over the END_ELEMENT event. However, the third is a problem, since there is a CHARACTERS event in the middle, in which case the next() back in read() only takes me to the SubscriptionHeaders END_ELEMENT, though the code at this point can only deal with 'binding.jms' END_ELEMENT, (and since it doesn't get this, we get an error).
> In general, it seems that to deal with this kind of thing, helper methods that parse a child element should be responsible for themselves advancing the cursor to their own child element's END_ELEMENT.
> For what it's worth, I'm not sure how parseDestination() works either, it seems like parseDestinationProperties() is going to advance the cursor too far, but maybe I don't fully understand this scenario.
> If I can get my build working, I'll post a recreate test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.