Re: [castor-dev] Possible problem in Castor XML
That one certainly looks like a bug to me.
I believe that should read if (!result) { ... }
--Keith
[EMAIL PROTECTED] wrote:
Here is the first example from org.exolab.castor.xml.schema.Schema.java,
lines 1807 - 1822
public boolean removeElement(ElementDecl element) {
boolean result = false;
if (_elements.contains(element)) {
_elements.remove(element.getName());
result = true;
}
if (result = false) {
//--check the cached included schemas
Enumeration cacheIncluded =
_cachedincludedSchemas.elements();
while (cacheIncluded.hasMoreElements() &&!result) {
Schema temp =
(Schema)cacheIncluded.nextElement();
result = temp.removeElement(element);
}
}
return result;
} //-- removeElement
Does this one look intentional?
The other 3 examples in Schema.java are virtually the same pattern for
methods removeAttribute, removeAttributeGroup, removeSimpleType.
They all have the same pattern of
if (result = false) {
The other files I have not personally checked.
Thanks,
DaVe.
.-.
/v\
// \\
/( )\
^^-^^
LAMP Rules David Buschman, SCJP
Web Developer
LEOPARD
Marketing. Communications. In that order.
http://www.leopard.com
303.527.5143 tel 303.530.3480 fax
*Henk van Voorthuijsen <[EMAIL PROTECTED]>*
04/07/2006 05:42 AM
Please respond to
[email protected]
To
[email protected]
cc
Subject
Re: [castor-dev] Possible problem in Castor XML
Yep, that seems intentional. Perhaps just breaking out the
assignments would make the code clearer?
Henk
On 07/04/2006, at 06:28, Keith Visco wrote:
>
> If you're refering to the following from XMLClassDescriptorImpl:
>
> if (added = _elements.add(descriptor)) {
>
> It looks intentional to me, and not a typo.
>
> --Keith
-
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-
_
Scanned by IBM Email Security Management Services powered by
MessageLabs. For more information please visit http://www.ers.ibm.com
_
-
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-
Re: [castor-dev] Possible problem in Castor XML
Here is the first example from org.exolab.castor.xml.schema.Schema.java,
lines 1807 - 1822
public boolean removeElement(ElementDecl
element) {
boolean
result = false;
if (_elements.contains(element)) {
_elements.remove(element.getName());
result = true;
}
if (result = false) {
//--check the cached included
schemas
Enumeration cacheIncluded =
_cachedincludedSchemas.elements();
while (cacheIncluded.hasMoreElements()
&&!result) {
Schema temp = (Schema)cacheIncluded.nextElement();
result = temp.removeElement(element);
}
}
return result;
} //-- removeElement
Does this one look intentional?
The other 3 examples in Schema.java are virtually the
same pattern for methods removeAttribute, removeAttributeGroup, removeSimpleType.
They all have the same pattern of
if (result = false) {
The other files I have not personally checked.
Thanks,
DaVe.
.-.
/v\
// \\
/( )\
^^-^^
LAMP Rules
David Buschman, SCJP
Web Developer
LEOPARD
Marketing. Communications. In that order.
http://www.leopard.com
303.527.5143 tel 303.530.3480 fax
Henk van Voorthuijsen <[EMAIL PROTECTED]>
04/07/2006 05:42 AM
Please respond to
[email protected]
To
[email protected]
cc
Subject
Re: [castor-dev] Possible problem in
Castor XML
Yep, that seems intentional. Perhaps just breaking
out the
assignments would make the code clearer?
Henk
On 07/04/2006, at 06:28, Keith Visco wrote:
>
> If you're refering to the following from XMLClassDescriptorImpl:
>
> if (added = _elements.add(descriptor)) {
>
> It looks intentional to me, and not a typo.
>
> --Keith
-
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-
_
Scanned by IBM Email Security Management Services powered by MessageLabs.
For more information please visit http://www.ers.ibm.com
_
Re: [castor-dev] Possible problem in Castor XML
Yep, that seems intentional. Perhaps just breaking out the
assignments would make the code clearer?
Henk
On 07/04/2006, at 06:28, Keith Visco wrote:
If you're refering to the following from XMLClassDescriptorImpl:
if (added = _elements.add(descriptor)) {
It looks intentional to me, and not a typo.
--Keith
-
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-
Re: [castor-dev] Possible problem in Castor XML
Henk van Voorthuijsen wrote:
On 05/04/2006, at 21:16, [EMAIL PROTECTED] wrote:
I was looking through the source for castor-0.9.9.1-xml.jar
I found 4 places in org.exolab.castor.xml.schema.Schema.java where
the following pattern exists
...
if ( result = false ) {
...
}
...
NOTE: The single equals(=) assignment operator instead on the
comparsion(==) operator.
Eclipse also reports this for
- org.exolab.castor.dsml.Consumer.java:125
- org.exolab.castor.xml.util:XMLClassDescriptorImpl.java:1240
- org.exolab.castor.xml.util:XMLClassDescriptorImpl.java:1249
If you're refering to the following from XMLClassDescriptorImpl:
if (added = _elements.add(descriptor)) {
It looks intentional to me, and not a typo.
--Keith
-
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-
RE: [castor-dev] Possible problem in Castor XML
Henk, I'd appreciate any patch that increases the code quality of Castor. In my view, a patch per 'smell' would be easier to handle. Bare in mind that it does not pay off to fix smelles within the gererated classes (from e.g. The mapping.xsd file), as they can be (re)generated at any time. And yes, individual issues would be appreciated, possible maybe created as sub-tasks off an initial issue that described the context. Just dreaming .. ;-). Werner > -Original Message- > From: Henk van Voorthuijsen [mailto:[EMAIL PROTECTED] > Sent: Donnerstag, 06. April 2006 17:25 > To: [email protected] > Subject: Re: [castor-dev] Possible problem in Castor XML > > Werner, since I'm not the OP, I think I will wait for Dave to > create the issue... :) > > On a similar not though, I got curious and took a long hard > look at the code with almost all warning flags on. > Eclipse reported about 1800 warnings, most of which are a > no-brainer to fix. > I'm currently thinking of submitting a series of patches, and > I want to know what is easier to handle: > Fix the more obvious warnings one package at a time, or > submit one patch per warning type? > I also wonder whether this should go into its own issue... > > Henk > > On 06/04/2006, at 15:17, Werner Guttmann wrote: > > > Can you please add this findings to the issue you created. > > > > Werner > > > >> -Original Message- > >> From: Henk van Voorthuijsen [mailto:[EMAIL PROTECTED] > >> Sent: Donnerstag, 06. April 2006 13:59 > >> To: [email protected] > >> Subject: Re: [castor-dev] Possible problem in Castor XML > >> > >> > >> On 05/04/2006, at 21:16, [EMAIL PROTECTED] wrote: > >> > >> Eclipse also reports this for > >> - org.exolab.castor.dsml.Consumer.java:125 > >> - org.exolab.castor.xml.util:XMLClassDescriptorImpl.java:1240 > >> - org.exolab.castor.xml.util:XMLClassDescriptorImpl.java:1249 > >> > > - > If you wish to unsubscribe from this list, please send an > empty message to the following address: > > [EMAIL PROTECTED] > - > > > - If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -
Re: [castor-dev] Possible problem in Castor XML
Werner, since I'm not the OP, I think I will wait for Dave to create the issue... :) On a similar not though, I got curious and took a long hard look at the code with almost all warning flags on. Eclipse reported about 1800 warnings, most of which are a no-brainer to fix. I'm currently thinking of submitting a series of patches, and I want to know what is easier to handle: Fix the more obvious warnings one package at a time, or submit one patch per warning type? I also wonder whether this should go into its own issue... Henk On 06/04/2006, at 15:17, Werner Guttmann wrote: Can you please add this findings to the issue you created. Werner -Original Message- From: Henk van Voorthuijsen [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 06. April 2006 13:59 To: [email protected] Subject: Re: [castor-dev] Possible problem in Castor XML On 05/04/2006, at 21:16, [EMAIL PROTECTED] wrote: Eclipse also reports this for - org.exolab.castor.dsml.Consumer.java:125 - org.exolab.castor.xml.util:XMLClassDescriptorImpl.java:1240 - org.exolab.castor.xml.util:XMLClassDescriptorImpl.java:1249 - If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -
RE: [castor-dev] Possible problem in Castor XML
Can you please add this findings to the issue you created. Werner > -Original Message- > From: Henk van Voorthuijsen [mailto:[EMAIL PROTECTED] > Sent: Donnerstag, 06. April 2006 13:59 > To: [email protected] > Subject: Re: [castor-dev] Possible problem in Castor XML > > > On 05/04/2006, at 21:16, [EMAIL PROTECTED] wrote: > > > > > I was looking through the source for castor-0.9.9.1-xml.jar > > > > I found 4 places in > org.exolab.castor.xml.schema.Schema.java where > > the following pattern exists > > > > ... > > if ( result = false ) { > >... > > } > > ... > > > > NOTE: The single equals(=) assignment operator instead on the > > comparsion(==) operator. > > > > Eclipse also reports this for > - org.exolab.castor.dsml.Consumer.java:125 > - org.exolab.castor.xml.util:XMLClassDescriptorImpl.java:1240 > - org.exolab.castor.xml.util:XMLClassDescriptorImpl.java:1249 > > > > - > If you wish to unsubscribe from this list, please send an > empty message to the following address: > > [EMAIL PROTECTED] > - > > > - If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -
Re: [castor-dev] Possible problem in Castor XML
On 05/04/2006, at 21:16, [EMAIL PROTECTED] wrote:
I was looking through the source for castor-0.9.9.1-xml.jar
I found 4 places in org.exolab.castor.xml.schema.Schema.java where
the following pattern exists
...
if ( result = false ) {
...
}
...
NOTE: The single equals(=) assignment operator instead on the
comparsion(==) operator.
Eclipse also reports this for
- org.exolab.castor.dsml.Consumer.java:125
- org.exolab.castor.xml.util:XMLClassDescriptorImpl.java:1240
- org.exolab.castor.xml.util:XMLClassDescriptorImpl.java:1249
-
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-
Re: [castor-dev] Possible problem in Castor XML
Dave,
I'd find it hard to believe if this is on intention (though I might
stand corrected .. ;-)). Can you please open a new Jira issue at
http://jira.codehaus.org/browse/CASTOR based upon your findings, and
attach a unified patch (if that's an option for you).
Thanks for your help.
Werner
[EMAIL PROTECTED] wrote:
>
> I was looking through the source for castor-0.9.9.1-xml.jar
>
> I found 4 places in org.exolab.castor.xml.schema.Schema.java where the
> following pattern exists
>
> ...
> if ( result = false ) {
>...
> }
> ...
>
> NOTE: The single equals(=) assignment operator instead on the
> comparsion(==) operator.
>
>
>
> This line numbers to the 4 instances on the pattern are : 1815, 1840,
> 1897, 2002
>
> Is this the intended behavior?
>
> Thanks,
>DaVe.
>.-.
> /v\
> // \\
> /( )\
>^^-^^
> LAMP RulesDavid Buschman, SCJP
> Web Developer
> LEOPARD
> Marketing. Communications. In that order.
> http://www.leopard.com
> 303.527.5143 tel 303.530.3480 fax
>
>
>
>
>
>
-
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-
