[Design of JBossXB] - Re: Extending EnumValueAdapter
by adrian＠jboss.org
"alesj" wrote :
| Claiming constant 'not understanding' won't make your semi-detailed answers go away. :-)
|
They're semi-detailed because I'm saying your doing it wrong,
I want you try to understand how it really works (code - all of it) and the philisophy
(the spec), not expect to be spoon fed.
I could spend all day telling you how it works and linking to code snippets
(or having stupid arguments like this one) but then I'll never get any work done.
And I might as well do the implementation myself since I can do it twice as fast
if I don't have to go into painful details on the forums.
Let's look at the history:
"adrian(a)jboss.org" wrote :
| Then when constructing the map of valid values and doing the lookups
| convert the xml values to lower case if the "ignoreCase" is true.
|
Not all values can be converted to lower case:
"adrian(a)jboss.org" wrote :
| Yes. Obviously, you can't ignore case on an integer. ;-)
|
Next one:
"adrian(a)jboss.org" wrote :
| Everything is a String in xml :-)
|
And we got this from additional drill-down:
"adrian(a)jboss.org" wrote :
| "alesj" wrote :
| | Who makes sure "1" is passed into EVA::cast as an Integer?
| |
| Its the xsd:type (or technically its parent type) of the attribute/element.
|
This one also isn't as obvious as it could be:
"adrian(a)jboss.org" wrote :
|
| | @XmlEnum(type=Integer.class)
| | @JBossXmlEnum(ignoreCase=true)
| | public enum Numbers
| | {
| | @XmlEnumValue("ONE")
| | ONE(1),
| | }
| |
|
Defining Integer type + explicit String enum value.
OK, I'll can pass this one to 's&s' principle.
Though my first idea tells me that Integer.parse in IntegerEditor will complain since it will get passed "ONE".
Or it could be that perhaps I again don't understand. ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137424#4137424
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137424
18 years
[Design of JBoss Build System] - Re: Shared Parent POM for dependencyManagement
by pgier
"ALRubinger" wrote : If there are no objections by midday UTC-5 tomorrow (EOB for EU), I'll start on extracting the AS Versions into a new Component in jbossas/projects, called "component-matrix". This will include:
|
| * Moving the "dependencyManagement" section of the JBossAS Parent into the new component
| * Setting the parent of the JBossAS Parent to "component-matrix"
| * Removing the "dependencyManagement" section of the EJB3 Build POM
| * Setting the parent of the EJB3 Build POM to "component-matrix"
| * Resolving conflicts with EJB3 Build to match AS
| * Creation of a Dependency Policy Wiki Page
|
| PS - I'm not married to the name "component-matrix", but "build" sounded redundant and non-deterministic. Suggestions?
|
| S,
| ALR
So the new pom will be the parent of the current jboss-as-parent? You could probably move the pluginManagement section up to the new pom also, since it is just controlling which versions of plugins are used and some basic configuration that could probably be used for EJB also.
Once you're done, just let me know, and I'll update the poms in the thirdparty branch that I'm working on.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137423#4137423
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137423
18 years
[Design of JBossXB] - Re: Extending EnumValueAdapter
by alesj
"adrian(a)jboss.org" wrote :
| I naturally assumed you didn't understand how it works or the idea
| that is supposed to be declaritive (annotation based).
|
Claiming not understanding something as simple as a single class with the size of 20+ lines is low. ;-)
What is declarative is debatable.
Adding @JBossXxmlEnum(ignore=true) to my (although it was never written down, this is what I had in mind) @ValueAdapter(CaseIgnoreEnumAdapter.class) is not that far apart.
"adrian(a)jboss.org" wrote :
| This was confirmed to me when you kept asking questions
| instead of trying to understand how it really worked.
|
| Claiming to have a working implementation of a new feature when you're not showing and understanding of how the old stuff works is obviously a "red flag".
|
| Problems:
| 1) Why should we let you modify something you don't understand?
| 2) Why should we continue to answer questions when you haven't tried to understand it for yourself?
|
Claiming constant 'not understanding' won't make your semi-detailed answers go away. :-)
Let's look at the history:
"adrian(a)jboss.org" wrote :
| Then when constructing the map of valid values and doing the lookups
| convert the xml values to lower case if the "ignoreCase" is true.
|
Not all values can be converted to lower case:
"adrian(a)jboss.org" wrote :
| Yes. Obviously, you can't ignore case on an integer. ;-)
|
Next one:
"adrian(a)jboss.org" wrote :
| Everything is a String in xml :-)
|
And we got this from additional drill-down:
"adrian(a)jboss.org" wrote :
| "alesj" wrote :
| | Who makes sure "1" is passed into EVA::cast as an Integer?
| |
| Its the xsd:type (or technically its parent type) of the attribute/element.
|
This one also isn't as obvious as it could be:
"adrian(a)jboss.org" wrote :
|
| | @XmlEnum(type=Integer.class)
| | @JBossXmlEnum(ignoreCase=true)
| | public enum Numbers
| | {
| | @XmlEnumValue("ONE")
| | ONE(1),
| | }
| |
|
Defining Integer type + explicit String enum value.
OK, I'll can pass this one to 's&s' principle.
Though my first idea tells me that Integer.parse in IntegerEditor will complain since it will get passed "ONE".
Or it could be that perhaps I again don't understand. ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137420#4137420
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137420
18 years
[Design of JBossXB] - Re: JBossEntityResolver and xsd:redefine resolution
by kabir.khan＠jboss.com
Actually, I don't seem to be able to commit there?
| Error: Commit failed (details follow):
| Error: MKACTIVITY of '/repos/common/!svn/act/53551a94-a2fe-ee45-b2ab-213af84ca041': 403 Forbidden (https://svn.jboss.org)
|
Can you please apply the following patch
| Index: C:/cygwin/home/Kabir/sourcecontrol/common-trunks/common-core/src/main/java/org/jboss/util/xml/JBossEntityResolver.java
| ===================================================================
| --- C:/cygwin/home/Kabir/sourcecontrol/common-trunks/common-core/src/main/java/org/jboss/util/xml/JBossEntityResolver.java (revision 2744)
| +++ C:/cygwin/home/Kabir/sourcecontrol/common-trunks/common-core/src/main/java/org/jboss/util/xml/JBossEntityResolver.java (working copy)
| @@ -258,7 +258,9 @@
| boolean resolvePublicIdFirst = true;
| if(publicId != null && systemId != null)
| {
| - String registeredSystemId = (String) localEntities.get(publicId);
| + String registeredSystemId = null;
| + if (localEntities != null)
| + registeredSystemId = (String) localEntities.get(publicId);
| if(registeredSystemId == null)
| registeredSystemId = (String) entities.get(publicId);
|
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137418#4137418
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137418
18 years
[Design of JBossXB] - Re: Extending EnumValueAdapter
by adrian＠jboss.org
"alesj" wrote : "adrian(a)jboss.org" wrote :
| | Please, either read the spec, read the code, read the tests or "suck it and see".
| |
| | Don't keep expecting me to explain the finest points of every implementation detail
| | ad infinitum in the forums (unless you want to post in the user forums
| | where I can ignore you :-).
| |
| Hey, you started suggesting how to do it.
| Hence I need/want/like to know the details of what you meant. :-)
|
| Also, afaik I had a working impl + already suggested you throw in a 'suck it and see' principle. ;-)
|
It was you that started talking about people having to implement hooks
for a simple feature like ignore case.
I naturally assumed you didn't understand how it works or the idea
that is supposed to be declaritive (annotation based).
If you don't like the EnumValueAdapter (which is an implementation detail)
then you can replace it with your own adapter already (possibly extending the original).
There's a seperate annotation for that.
(There's no need to write hooks for hooks. Not very "cool" at all. :-)
This was confirmed to me when you kept asking questions
instead of trying to understand how it really worked.
Claiming to have a working implementation of a new feature when you're not showing
and understanding of how the old stuff works is obviously a "red flag".
Problems:
1) Why should we let you modify something you don't understand?
2) Why should we continue to answer questions when you haven't tried to understand
it for yourself?
"Because it SEEMS to work for me" isn't an answer. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137411#4137411
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137411
18 years