You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jaxme-dev@ws.apache.org by Alexey Loubyansky <al...@jboss.org> on 2003/12/09 11:13:29 UTC
feature requests
Hello,
I am not an expert in the area and maybe wrong in some assumptions,
please, correct me in that case.
I would like a binding tool to meet some requirements. In no specific
order, the requirements are:
* custom object model
AFAIK, existing tools propose one to implement the generated interfaces.
I would like to write my own object model and avoid generated interfaces.
* flexible object model
In existing tools, object model strictly reflects the shema definition.
For example
<!ELEMENT ejb-jar (description?, display-name?, small-icon?,
large-icon?, enterprise-beans, relationships?, assembly-descriptor?,
ejb-client-jar?)>
It means in the object model, all the children will be represented by
classes. I would like to skip some of them, such as description, icons,
etc. I would like even to skip enterprise-beans element but have its
children (entity, session, etc) present in my (custom) object model.
* population of the same object model from different XML sources
For example, deployment information for an EJB comes splitted into
several deployment descriptors. For example, ejb-jar.xml, jboss.xml and
jbosscmp-jdbc.xml. Each deployment descriptor provides different kind of
information for the same, say, entity bean (ejb-jar.xml - spec info,
jboss.xml - container configuration, jbosscmp-jdbc.xml - persistence
configuration). I would not like to end up with three object models, one
per deployment descriptor. I would like to combine the information from
all the three files into the same object model.
* support for both DTD and XML schemas
What do you think about implementing the features above?
I have a proof of concept implementation of the binding binding tool
that supports all the features above including marshalling. I would be
glad to contribute the code.
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: feature requests
Posted by Alexey Loubyansky <al...@jboss.org>.
robert burrell donkin wrote:
> FWIW
>
> (without wanting to dampen alexey's enthusiasm for jaxme ;)
>
> i think what alexey seems to be talking about is most commonly called
> the start-from-java problem. i'd always assumed that JAXB was a strongly
> generative solution. other mapping technologies might be better suited
> to start-from-java.
AFAICT, you are absolutely right. Therefore, I tried to invent something
that would meet my needs. If I found a project that supported all I
need, I would not do it.
I would like to address one more point about generation. First of all, I
am NOT against it in any way. I am all for it. It also should be
configurable as Jochen wrote.
Supposedly, we even have a highly configurable generator that can
produce extremely exotic class hierarchy from my mind. Cool.
But code generation, as for me, is just a FEATURE, although very useful.
It just frees you from writting the code yourself.
Being able to work with ANY kind of class hierarchy, maybe not even
supported by the generator, is the most important thing to me.
Alexey
>
> i'd interested to hear what jochen has to say on this :)
>
> - robert
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: feature requests
Posted by Alexey Loubyansky <al...@jboss.org>.
Jochen Wiedmann wrote:
JAXB is, IMO, the "default"
> and I accept the default, because I value standards. But the default
> must be configurable to my personal needs - and that is exactly what
> Alexey desires, except that his wishes might differ from mine.
Absolutely agree. Standards are important and are the MINIMUM that
should be supported by a modern tool. But, unfortunately, standards tend
to have some limitations. Therefore, I would like the core (of the tool)
to be more abstract, flexible and customizable. That also gives some
ensurance that future standards can easily be supported.
Alexey
>
>
> Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: feature requests
Posted by Jochen Wiedmann <jo...@ispsoft.de>.
Robert,
robert burrell donkin wrote:
> i think what alexey seems to be talking about is most commonly called
> the start-from-java problem. i'd always assumed that JAXB was a strongly
> generative solution. other mapping technologies might be better suited
> to start-from-java.
>
> i'd interested to hear what jochen has to say on this :)
it never occured to me, that the generated sources *could* not suit my needs
or wishes: If they didn't in the past, I simply changed the generator. ;-)
But seriously: I think it depends very much on what you use it for. For
example, I am typically using the generators in an environment where they
are used for database representation. (Be it XML database or relational.) A
typical application has a hundred different schemas or so. In that
environment it is of utmost importance to be as close to the database as
possible. In other words, you depend very much on an external schema that
predefines your set of classes. Mandating that the Java classes require
changes in the database would be the wrong way. The situation is partially
the same for Alexey, having a predefined schema like that of ejb-jar.xml.
Of course things change drastically, if you are handling, for example, a
configuration file, where the schema is just a representation of your
internal Java class which configures the application and it doesn't matter
so much, how the generated XML looks like. You'd be a fool making your
programming overly complex by following the generators requirements.
For that reason, I found it always desirable to have a generator that
accepts varying sources as input. In fact, after you have read the schema
source and converted it into the generators internal representation, things
aren't so different. JAXB is, IMO, the "default" and I accept the default,
because I value standards. But the default must be configurable to my
personal needs - and that is exactly what Alexey desires, except that his
wishes might differ from mine.
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
RE: feature requests
Posted by Ias <ia...@tmax.co.kr>.
> i think what alexey seems to be talking about is most
> commonly called the start-from-java problem. i'd always
> assumed that JAXB was a strongly generative solution. other
> mapping technologies might be better suited to start-from-java.
Actually one of what JAXB 1.0 lacks in is the mapping from Java to XML that
some other Java-based XML binding solutions like Castor provide. JSR-222,
JAXB 2.0 is going to make it up. You can see the following phrase from
http://jcp.org/en/jsr/detail?id=222 .
---
JAXB 1.0 specified the mapping of XML Schema to Java TM but not JavaTM to
XML Schema. JAXB 2.0 will specify the mapping from Java to XML Schema. This
addresses scenarios where an application design begins with Java TM objects
rather than an XML schema. One such example is an application that exports
itself as a web service that communicates using SOAP and XML as a transport
mechanism.
---
As JAXB 2.0 becomes public, I'll propose a plan for implementing new
features from JAXB 2.0 including Java-to-XML. If you want a new feature in
JAXB 2.0, please let me know that, so I can discuss it with the JSR-222 EG
from the early stage on your behalf. Before you make such a request, I
strongly recommend your reading "Section 2: Request" at
http://jcp.org/en/jsr/detail?id=222 closely.
Thanks,
Ias
>
> i'd interested to hear what jochen has to say on this :)
>
> - robert
>
> On 10 Dec 2003, at 10:59, Alexey Loubyansky wrote:
>
> > Hello Jochen,
> >
> > thanks for the response.
> > Yes, I spend most of the time in EJB land and just assumed
> everyone is
> > familiar with the problems :) I am sorry. I'll try to abstract from
> > the EJB specifics and answer all your questions. I am
> interested in it.
> > The answers inlined.
> >
> > Jochen Wiedmann wrote:
> >> Hi, Alexey,
> >> Alexey Loubyansky wrote:
> >>> * custom object model
> >>> AFAIK, existing tools propose one to implement the generated
> >>> interfaces. I would like to write my own object model and avoid
> >>> generated interfaces.
> >> I am not sure, whether I get your idea right. In the case of JAXB,
> >> the "proposed" object model (hence the generated interfaces) are
> >> specified by an XML schema. IMO this qualifies as "writing my own
> >> object model".
> >> Perhaps
> >> you would prefer other ways of specifying a schema, for example a
> >> Java class or interface written by you? This is something
> we had in mind.
> >> It
> >> is a fairly trivial task. However, so far noone has
> started to work
> >> on it.
> >> See http://marc.theaimsgroup.com/?l=jaxme-dev&m=106931176112646&w=2
> >> for
> >> details.
> >
> > Yes, we see the problem a bit differently. Let me explain. When you
> > are the author of the XML schema, it is under your control. In my
> > case, I am not the author. The schema is given to me. To
> use a binding
> > tool I have to generate interfaces/classes. These generated
> > interfaces/classes I called "proposed" object model. I
> would like to
> > write my own, custom object model (yes, written by me).
> > I don't say it is hard to do, but, AFAIK, it is not done yet ;)
> >
> >> If it is simply that you would like to restrict the
> generated classes
> >> to implementation classes, that's fine for me. I can't see the
> >> necessity for doubling the number of classes in the case of value
> >> objects.
> >> That's
> >> something which has been simply specified by JAXB, but I am
> >> completely open for adding an option to JaxMe that
> disables interface
> >> generation..
> >
> > As I see it, the problems with generation are:
> > - it can produce more interfaces/classes that I would like
> to have in
> > my object model.
> > - it forces to implement the generated interfaces. Might
> not be a big
> > deal but we could avoid it.
> > - might dictate the interface or public view and even maybe the
> > internal structure of the class that represents a schema element. I
> > mean if a generated interface states that children are
> returned as an
> > array, or List or Iterator.
> >
> >>> * flexible object model
> >>> In existing tools, object model strictly reflects the shema
> >>> definition. For example <!ELEMENT ejb-jar (description?,
> >>> display-name?, small-icon?, large-icon?, enterprise-beans,
> >>> relationships?, assembly-descriptor?, ejb-client-jar?)>
> It means in
> >>> the object model, all the children will be represented by
> classes. I
> >>> would like to skip some of them, such as description,
> icons, etc. I
> >>> would like even to skip enterprise-beans element but have its
> >>> children (entity, session, etc) present in my (custom)
> object model.
> >
> > I would like to build an object model that will reflect the ejb-jar
> > document. But
> >
> > - I am not interested in all the information from the ejb-jar and
> > would like to ignore some elements and thier representation in my
> > object model. For example, let's suppose I am interested only in
> > enterprise-beans, relationships and assembly-descriptor. Everything
> > else is garbage to me.
> >
> > - now, as I understand, I will have an object that will represent
> > ejb-jar element that will have some method that will return an
> > object[s] that represnts enterprise-beans. Right? Here is its
> > definition <!ELEMENT enterprise-beans (session | entity |
> > message-driven)+> I would like a class that will represent ejb-jar
> > element to have methods like getEntityBeans(),
> getSessionBeans() and
> > getMessageDrivenBeans().
> > NOT getEnterpriseBeans() that will return an object the represents
> > enterprise-beans element.
> > Can I do it with jaxme?
> >
> >>> * population of the same object model from different XML
> sources For
> >>> example, deployment information for an EJB comes splitted into
> >>> several deployment descriptors. For example, ejb-jar.xml,
> jboss.xml
> >>> and jbosscmp-jdbc.xml. Each deployment descriptor
> provides different
> >>> kind of information for the same, say, entity bean (ejb-jar.xml -
> >>> spec info, jboss.xml - container configuration,
> jbosscmp-jdbc.xml -
> >>> persistence configuration). I would not like to end up with three
> >>> object models, one per deployment descriptor. I would like to
> >>> combine the information from all the three files into the same
> >>> object model.
> >
> > Here, I am talking about several XML files, each of which
> describes a
> > different view of (provides different kind of information
> about) the
> > same thing.
> > For example, ejb-jar.xml, jboss.xml and jbosscmp-jdbc.xml all have
> > <entity>
> > <ejb-name>SomeEJBName</ejb-name>
> > ...
> > </entity>
> >
> > But each file contains different kind of information. ejb-jar.xml
> > contains some basic information about an entity bean.
> jboss.xml adds
> > some more (different) information about the same entity bean. And
> > jbosscmp-jdbc.xml provides other details of the same entity bean.
> >
> > I would like to have a class EntityBeanMetaData that will
> contain the
> > information from ALL the ejb-jar.xml, jboss.xml, jbosscmp-jdbc.xml.
> > I.e.
> > I would like to read the information from all the XML files in the
> > SAME object. Is it possible with jaxme? Or will I end up having
> > classes like EjbJarEntityBean, JBossEntityBean,
> > JBossCmpJdbcEntityBean, i.e. one class per XML file?
> >
> >> I must admit that I can't follow you here at all. It seems
> that our
> >> background is too different, me being a stupid Java/XML programmer
> >> (;-) and you living in the EJB world completely. Would you
> please be
> >> so kind and explain
> >
> > I am sorry. I will try to answer all your questions. Just
> ask me what
> > is unclear.
> >
> >>> * support for both DTD and XML schemas
> >> In JaxMe 1 there was a schema reader for DTD. It shouldn't be too
> >> complex to port it to ws-jaxme. However, that is also
> something which
> >> hasn't been done yet. I personally do not expect to find
> the time for
> >> it.
> >
> > I would like to have it. Currently, I am using Mark Wutka's
> DTD parser.
> >
> > Thank you!
> >
> > Alexey
> >
> > PS: as I wrote in previous email, I have something doing it
> all. BTW,
> > I used your schema parser ;)
> >
> >> Jochen
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: jaxme-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: jaxme-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: feature requests
Posted by robert burrell donkin <rd...@apache.org>.
FWIW
(without wanting to dampen alexey's enthusiasm for jaxme ;)
i think what alexey seems to be talking about is most commonly called
the start-from-java problem. i'd always assumed that JAXB was a
strongly generative solution. other mapping technologies might be
better suited to start-from-java.
i'd interested to hear what jochen has to say on this :)
- robert
On 10 Dec 2003, at 10:59, Alexey Loubyansky wrote:
> Hello Jochen,
>
> thanks for the response.
> Yes, I spend most of the time in EJB land and just assumed everyone is
> familiar with the problems :) I am sorry. I'll try to abstract from the
> EJB specifics and answer all your questions. I am interested in it.
> The answers inlined.
>
> Jochen Wiedmann wrote:
>> Hi, Alexey,
>> Alexey Loubyansky wrote:
>>> * custom object model
>>> AFAIK, existing tools propose one to implement the generated
>>> interfaces. I would like to write my own object model and avoid
>>> generated interfaces.
>> I am not sure, whether I get your idea right. In the case of JAXB, the
>> "proposed" object model (hence the generated interfaces) are
>> specified by
>> an XML schema. IMO this qualifies as "writing my own object model".
>> Perhaps
>> you would prefer other ways of specifying a schema, for example a Java
>> class or interface written by you? This is something we had in mind.
>> It
>> is a fairly trivial task. However, so far noone has started to work
>> on it.
>> See http://marc.theaimsgroup.com/?l=jaxme-dev&m=106931176112646&w=2
>> for
>> details.
>
> Yes, we see the problem a bit differently. Let me explain. When you are
> the author of the XML schema, it is under your control. In my case, I
> am
> not the author. The schema is given to me. To use a binding tool I have
> to generate interfaces/classes. These generated interfaces/classes I
> called "proposed" object model. I would like to write my own, custom
> object model (yes, written by me).
> I don't say it is hard to do, but, AFAIK, it is not done yet ;)
>
>> If it is simply that you would like to restrict the generated classes
>> to
>> implementation classes, that's fine for me. I can't see the necessity
>> for doubling the number of classes in the case of value objects.
>> That's
>> something which has been simply specified by JAXB, but I am completely
>> open for adding an option to JaxMe that disables interface
>> generation..
>
> As I see it, the problems with generation are:
> - it can produce more interfaces/classes that I would like to have in
> my
> object model.
> - it forces to implement the generated interfaces. Might not be a big
> deal but we could avoid it.
> - might dictate the interface or public view and even maybe the
> internal
> structure of the class that represents a schema element. I mean if a
> generated interface states that children are returned as an array, or
> List or Iterator.
>
>>> * flexible object model
>>> In existing tools, object model strictly reflects the shema
>>> definition. For example
>>> <!ELEMENT ejb-jar (description?, display-name?, small-icon?,
>>> large-icon?, enterprise-beans, relationships?, assembly-descriptor?,
>>> ejb-client-jar?)>
>>> It means in the object model, all the children will be represented
>>> by classes. I would like to skip some of them, such as description,
>>> icons, etc. I would like even to skip enterprise-beans element but
>>> have its children (entity, session, etc) present in my (custom)
>>> object model.
>
> I would like to build an object model that will reflect the ejb-jar
> document. But
>
> - I am not interested in all the information from the ejb-jar and would
> like to ignore some elements and thier representation in my object
> model. For example, let's suppose I am interested only in
> enterprise-beans, relationships and assembly-descriptor. Everything
> else
> is garbage to me.
>
> - now, as I understand, I will have an object that will represent
> ejb-jar element that will have some method that will return an
> object[s]
> that represnts enterprise-beans. Right? Here is its definition
> <!ELEMENT enterprise-beans (session | entity | message-driven)+>
> I would like a class that will represent ejb-jar element to have
> methods
> like getEntityBeans(), getSessionBeans() and getMessageDrivenBeans().
> NOT getEnterpriseBeans() that will return an object the represents
> enterprise-beans element.
> Can I do it with jaxme?
>
>>> * population of the same object model from different XML sources
>>> For example, deployment information for an EJB comes splitted into
>>> several deployment descriptors. For example, ejb-jar.xml, jboss.xml
>>> and jbosscmp-jdbc.xml. Each deployment descriptor provides different
>>> kind of information for the same, say, entity bean (ejb-jar.xml -
>>> spec info, jboss.xml - container configuration, jbosscmp-jdbc.xml -
>>> persistence configuration). I would not like to end up with three
>>> object models, one per deployment descriptor. I would like to
>>> combine the information from all the three files into the same
>>> object model.
>
> Here, I am talking about several XML files, each of which describes a
> different view of (provides different kind of information about) the
> same thing.
> For example, ejb-jar.xml, jboss.xml and jbosscmp-jdbc.xml all have
> <entity>
> <ejb-name>SomeEJBName</ejb-name>
> ...
> </entity>
>
> But each file contains different kind of information. ejb-jar.xml
> contains some basic information about an entity bean. jboss.xml adds
> some more (different) information about the same entity bean. And
> jbosscmp-jdbc.xml provides other details of the same entity bean.
>
> I would like to have a class EntityBeanMetaData that will contain the
> information from ALL the ejb-jar.xml, jboss.xml, jbosscmp-jdbc.xml.
> I.e.
> I would like to read the information from all the XML files in the SAME
> object. Is it possible with jaxme? Or will I end up having classes like
> EjbJarEntityBean, JBossEntityBean, JBossCmpJdbcEntityBean, i.e. one
> class per XML file?
>
>> I must admit that I can't follow you here at all. It seems that our
>> background is too different, me being a stupid Java/XML programmer
>> (;-) and you living in the EJB world completely. Would you please be
>> so kind and explain
>
> I am sorry. I will try to answer all your questions. Just ask me what
> is
> unclear.
>
>>> * support for both DTD and XML schemas
>> In JaxMe 1 there was a schema reader for DTD. It shouldn't be too
>> complex
>> to port it to ws-jaxme. However, that is also something which hasn't
>> been
>> done yet. I personally do not expect to find the time for it.
>
> I would like to have it. Currently, I am using Mark Wutka's DTD parser.
>
> Thank you!
>
> Alexey
>
> PS: as I wrote in previous email, I have something doing it all. BTW, I
> used your schema parser ;)
>
>> Jochen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: jaxme-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: feature requests
Posted by Alexey Loubyansky <al...@jboss.org>.
Great! Thanks, Jochen!
Now, since I know it is of interest, I will look at how I could apply my
ideas to JAXME codebase and keep this list informed.
Jochen Wiedmann wrote:
> Alexey Loubyansky wrote:
>
>> - you need someone to do it.
>>
>> Is that correct? :)
>
>
> Right. :-)
>
>
>> For the last item, consider myself to be that someone ;)
>> I do need the features ASAP and need to decide whether I work with you
>> or alone.
>> In case you just have other plans and would not like to add something
>> I need right now (meaning 'go ahead alone'), it's absolutely ok. I
>> won't take offence ;)
>
>
> If I can assist somehow, count on me. So far I did this typically by
> discussing the required features and describing the way to go. See,
> for example,
>
> http://ws.apache.org/jaxme/features.html
>
> Jochen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: jaxme-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: feature requests
Posted by Jochen Wiedmann <jo...@ispsoft.de>.
Alexey Loubyansky wrote:
> - you need someone to do it.
>
> Is that correct? :)
Right. :-)
> For the last item, consider myself to be that someone ;)
> I do need the features ASAP and need to decide whether I work with you
> or alone.
> In case you just have other plans and would not like to add something I
> need right now (meaning 'go ahead alone'), it's absolutely ok. I won't
> take offence ;)
If I can assist somehow, count on me. So far I did this typically by
discussing the required features and describing the way to go. See,
for example,
http://ws.apache.org/jaxme/features.html
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: feature requests
Posted by Alexey Loubyansky <al...@jboss.org>.
Hi Jochen,
so my short resume of our discussion so far is:
- there still maybe some misunderstandings in our views of the problems,
but, generally, I think, you got me and don't mind to support the features;
- it is not that hard to do;
- you just have another priorities and my features are not on top of the
list;
- you need someone to do it.
Is that correct? :)
For the last item, consider myself to be that someone ;)
I do need the features ASAP and need to decide whether I work with you
or alone.
In case you just have other plans and would not like to add something I
need right now (meaning 'go ahead alone'), it's absolutely ok. I won't
take offence ;)
Thanks,
Alexey
Jochen Wiedmann wrote:
>
> Hi, Alexey,
>
> Alexey Loubyansky wrote:
>
>> Yes, we see the problem a bit differently. Let me explain. When you are
>> the author of the XML schema, it is under your control. In my case, I am
>> not the author. The schema is given to me. To use a binding tool I have
>> to generate interfaces/classes. These generated interfaces/classes I
>> called "proposed" object model. I would like to write my own, custom
>> object model (yes, written by me).
>> I don't say it is hard to do, but, AFAIK, it is not done yet ;)
>
>
> but, if I get you right, you won't differ too much from the proposed
> model. So I would still consider that as the case where a schema defined
> by someone else is the source - except that you probably want some
> configurability.
>
>
>> As I see it, the problems with generation are:
>> - it can produce more interfaces/classes that I would like to have in my
>> object model.
>> - it forces to implement the generated interfaces. Might not be a big
>> deal but we could avoid it.
>> - might dictate the interface or public view and even maybe the internal
>> structure of the class that represents a schema element. I mean if a
>> generated interface states that children are returned as an array, or
>> List or Iterator.
>
>
> I still see this as the desire for configurability. For example:
>
> - being able to ignore some elements/attributes, regards of whether they
> are complex or not (you have termed that as "skipping them" below)
> - being able to choose the representation of lists
> - being able to choose the schema source (XML schema, DTD, Java bean class
> or interface)
> - being able to choose whether an interface is even used or generated
> ....
>
>
>> I would like a class that will represent ejb-jar element to have methods
>> like getEntityBeans(), getSessionBeans() and getMessageDrivenBeans().
>> NOT getEnterpriseBeans() that will return an object the represents
>> enterprise-beans element.
>> Can I do it with jaxme?
>
>
> As of now, you can't. But that has been a configurable option in JaxMe 1
> and I see no reason for not introducing them - except that someone needs
> to do the job. :-)
>
>
>> I would like to have a class EntityBeanMetaData that will contain the
>> information from ALL the ejb-jar.xml, jboss.xml, jbosscmp-jdbc.xml. I.e.
>> I would like to read the information from all the XML files in the SAME
>> object. Is it possible with jaxme? Or will I end up having classes like
>> EjbJarEntityBean, JBossEntityBean, JBossCmpJdbcEntityBean, i.e. one
>> class per XML file?
>
>
> In XML Schema, one would use an "extension" for these kind of things. I
> can also imagine a special kind of schema reader that collects schema
> particles from various sources and combines them into a single schema.
>
> However, given your special case, I would assume that this is not all
> what you want: In fact you would want not only the schema to be
> combined, but you would also want the data to be collected from various
> sources. However, I still do not consider this as a very difficult
> thing. It mainly requires that the XML reader will not necessarily
> create a new object, but is also able to accept an object from you and
> fill it with data.
>
> Again, it isn't too difficult. However, I would consider it as something
> that is unlikely to be implemented unless someone says "I need it, so
> I'll do it". (To be distinguished from the above points where I would
> expect that sooner or later there are more people like you requesting
> it, so we'll gonna implement it sooner or later.)
>
>
>
>> PS: as I wrote in previous email, I have something doing it all. BTW, I
>> used your schema parser ;)
>
>
> I new that this has to be good for something. :-)
>
>
> Jochen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: jaxme-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: feature requests
Posted by Jochen Wiedmann <jo...@ispsoft.de>.
Hi, Alexey,
Alexey Loubyansky wrote:
> Yes, we see the problem a bit differently. Let me explain. When you are
> the author of the XML schema, it is under your control. In my case, I am
> not the author. The schema is given to me. To use a binding tool I have
> to generate interfaces/classes. These generated interfaces/classes I
> called "proposed" object model. I would like to write my own, custom
> object model (yes, written by me).
> I don't say it is hard to do, but, AFAIK, it is not done yet ;)
but, if I get you right, you won't differ too much from the proposed model.
So I would still consider that as the case where a schema defined by someone
else is the source - except that you probably want some configurability.
> As I see it, the problems with generation are:
> - it can produce more interfaces/classes that I would like to have in my
> object model.
> - it forces to implement the generated interfaces. Might not be a big
> deal but we could avoid it.
> - might dictate the interface or public view and even maybe the internal
> structure of the class that represents a schema element. I mean if a
> generated interface states that children are returned as an array, or
> List or Iterator.
I still see this as the desire for configurability. For example:
- being able to ignore some elements/attributes, regards of whether they
are complex or not (you have termed that as "skipping them" below)
- being able to choose the representation of lists
- being able to choose the schema source (XML schema, DTD, Java bean class
or interface)
- being able to choose whether an interface is even used or generated
....
> I would like a class that will represent ejb-jar element to have methods
> like getEntityBeans(), getSessionBeans() and getMessageDrivenBeans().
> NOT getEnterpriseBeans() that will return an object the represents
> enterprise-beans element.
> Can I do it with jaxme?
As of now, you can't. But that has been a configurable option in JaxMe 1 and
I see no reason for not introducing them - except that someone needs to do
the job. :-)
> I would like to have a class EntityBeanMetaData that will contain the
> information from ALL the ejb-jar.xml, jboss.xml, jbosscmp-jdbc.xml. I.e.
> I would like to read the information from all the XML files in the SAME
> object. Is it possible with jaxme? Or will I end up having classes like
> EjbJarEntityBean, JBossEntityBean, JBossCmpJdbcEntityBean, i.e. one
> class per XML file?
In XML Schema, one would use an "extension" for these kind of things. I can
also imagine a special kind of schema reader that collects schema particles
from various sources and combines them into a single schema.
However, given your special case, I would assume that this is not all what
you want: In fact you would want not only the schema to be combined, but you
would also want the data to be collected from various sources. However, I
still do not consider this as a very difficult thing. It mainly requires
that the XML reader will not necessarily create a new object, but is also
able to accept an object from you and fill it with data.
Again, it isn't too difficult. However, I would consider it as something
that is unlikely to be implemented unless someone says "I need it, so I'll
do it". (To be distinguished from the above points where I would expect that
sooner or later there are more people like you requesting it, so we'll gonna
implement it sooner or later.)
> PS: as I wrote in previous email, I have something doing it all. BTW, I
> used your schema parser ;)
I new that this has to be good for something. :-)
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: feature requests
Posted by Alexey Loubyansky <al...@jboss.org>.
Hello Jochen,
thanks for the response.
Yes, I spend most of the time in EJB land and just assumed everyone is
familiar with the problems :) I am sorry. I'll try to abstract from the
EJB specifics and answer all your questions. I am interested in it.
The answers inlined.
Jochen Wiedmann wrote:
>
> Hi, Alexey,
>
> Alexey Loubyansky wrote:
>
>> * custom object model
>> AFAIK, existing tools propose one to implement the generated
>> interfaces. I would like to write my own object model and avoid
>> generated interfaces.
>
>
> I am not sure, whether I get your idea right. In the case of JAXB, the
> "proposed" object model (hence the generated interfaces) are specified by
> an XML schema. IMO this qualifies as "writing my own object model". Perhaps
> you would prefer other ways of specifying a schema, for example a Java
> class or interface written by you? This is something we had in mind. It
> is a fairly trivial task. However, so far noone has started to work on it.
> See http://marc.theaimsgroup.com/?l=jaxme-dev&m=106931176112646&w=2 for
> details.
Yes, we see the problem a bit differently. Let me explain. When you are
the author of the XML schema, it is under your control. In my case, I am
not the author. The schema is given to me. To use a binding tool I have
to generate interfaces/classes. These generated interfaces/classes I
called "proposed" object model. I would like to write my own, custom
object model (yes, written by me).
I don't say it is hard to do, but, AFAIK, it is not done yet ;)
> If it is simply that you would like to restrict the generated classes to
> implementation classes, that's fine for me. I can't see the necessity
> for doubling the number of classes in the case of value objects. That's
> something which has been simply specified by JAXB, but I am completely
> open for adding an option to JaxMe that disables interface generation..
As I see it, the problems with generation are:
- it can produce more interfaces/classes that I would like to have in my
object model.
- it forces to implement the generated interfaces. Might not be a big
deal but we could avoid it.
- might dictate the interface or public view and even maybe the internal
structure of the class that represents a schema element. I mean if a
generated interface states that children are returned as an array, or
List or Iterator.
>
>> * flexible object model
>> In existing tools, object model strictly reflects the shema
>> definition. For example
>> <!ELEMENT ejb-jar (description?, display-name?, small-icon?,
>> large-icon?, enterprise-beans, relationships?, assembly-descriptor?,
>> ejb-client-jar?)>
>> It means in the object model, all the children will be represented by
>> classes. I would like to skip some of them, such as description,
>> icons, etc. I would like even to skip enterprise-beans element but
>> have its children (entity, session, etc) present in my (custom) object
>> model.
I would like to build an object model that will reflect the ejb-jar
document. But
- I am not interested in all the information from the ejb-jar and would
like to ignore some elements and thier representation in my object
model. For example, let's suppose I am interested only in
enterprise-beans, relationships and assembly-descriptor. Everything else
is garbage to me.
- now, as I understand, I will have an object that will represent
ejb-jar element that will have some method that will return an object[s]
that represnts enterprise-beans. Right? Here is its definition
<!ELEMENT enterprise-beans (session | entity | message-driven)+>
I would like a class that will represent ejb-jar element to have methods
like getEntityBeans(), getSessionBeans() and getMessageDrivenBeans().
NOT getEnterpriseBeans() that will return an object the represents
enterprise-beans element.
Can I do it with jaxme?
>> * population of the same object model from different XML sources
>> For example, deployment information for an EJB comes splitted into
>> several deployment descriptors. For example, ejb-jar.xml, jboss.xml
>> and jbosscmp-jdbc.xml. Each deployment descriptor provides different
>> kind of information for the same, say, entity bean (ejb-jar.xml - spec
>> info, jboss.xml - container configuration, jbosscmp-jdbc.xml -
>> persistence configuration). I would not like to end up with three
>> object models, one per deployment descriptor. I would like to combine
>> the information from all the three files into the same object model.
Here, I am talking about several XML files, each of which describes a
different view of (provides different kind of information about) the
same thing.
For example, ejb-jar.xml, jboss.xml and jbosscmp-jdbc.xml all have
<entity>
<ejb-name>SomeEJBName</ejb-name>
...
</entity>
But each file contains different kind of information. ejb-jar.xml
contains some basic information about an entity bean. jboss.xml adds
some more (different) information about the same entity bean. And
jbosscmp-jdbc.xml provides other details of the same entity bean.
I would like to have a class EntityBeanMetaData that will contain the
information from ALL the ejb-jar.xml, jboss.xml, jbosscmp-jdbc.xml. I.e.
I would like to read the information from all the XML files in the SAME
object. Is it possible with jaxme? Or will I end up having classes like
EjbJarEntityBean, JBossEntityBean, JBossCmpJdbcEntityBean, i.e. one
class per XML file?
> I must admit that I can't follow you here at all. It seems that our
> background is too different, me being a stupid Java/XML programmer
> (;-) and you living in the EJB world completely. Would you please be
> so kind and explain
I am sorry. I will try to answer all your questions. Just ask me what is
unclear.
>
>
>> * support for both DTD and XML schemas
>
>
> In JaxMe 1 there was a schema reader for DTD. It shouldn't be too complex
> to port it to ws-jaxme. However, that is also something which hasn't been
> done yet. I personally do not expect to find the time for it.
I would like to have it. Currently, I am using Mark Wutka's DTD parser.
Thank you!
Alexey
PS: as I wrote in previous email, I have something doing it all. BTW, I
used your schema parser ;)
>
>
> Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: feature requests
Posted by Jochen Wiedmann <jo...@ispsoft.de>.
Hi, Alexey,
Alexey Loubyansky wrote:
> * custom object model
> AFAIK, existing tools propose one to implement the generated interfaces.
> I would like to write my own object model and avoid generated interfaces.
I am not sure, whether I get your idea right. In the case of JAXB, the
"proposed" object model (hence the generated interfaces) are specified by
an XML schema. IMO this qualifies as "writing my own object model". Perhaps
you would prefer other ways of specifying a schema, for example a Java
class or interface written by you? This is something we had in mind. It
is a fairly trivial task. However, so far noone has started to work on it.
See http://marc.theaimsgroup.com/?l=jaxme-dev&m=106931176112646&w=2 for
details.
If it is simply that you would like to restrict the generated classes to
implementation classes, that's fine for me. I can't see the necessity
for doubling the number of classes in the case of value objects. That's
something which has been simply specified by JAXB, but I am completely
open for adding an option to JaxMe that disables interface generation..
> * flexible object model
> In existing tools, object model strictly reflects the shema definition.
> For example
> <!ELEMENT ejb-jar (description?, display-name?, small-icon?,
> large-icon?, enterprise-beans, relationships?, assembly-descriptor?,
> ejb-client-jar?)>
> It means in the object model, all the children will be represented by
> classes. I would like to skip some of them, such as description, icons,
> etc. I would like even to skip enterprise-beans element but have its
> children (entity, session, etc) present in my (custom) object model.
>
> * population of the same object model from different XML sources
> For example, deployment information for an EJB comes splitted into
> several deployment descriptors. For example, ejb-jar.xml, jboss.xml and
> jbosscmp-jdbc.xml. Each deployment descriptor provides different kind of
> information for the same, say, entity bean (ejb-jar.xml - spec info,
> jboss.xml - container configuration, jbosscmp-jdbc.xml - persistence
> configuration). I would not like to end up with three object models, one
> per deployment descriptor. I would like to combine the information from
> all the three files into the same object model.
I must admit that I can't follow you here at all. It seems that our
background is too different, me being a stupid Java/XML programmer
(;-) and you living in the EJB world completely. Would you please be
so kind and explain
> * support for both DTD and XML schemas
In JaxMe 1 there was a schema reader for DTD. It shouldn't be too complex
to port it to ws-jaxme. However, that is also something which hasn't been
done yet. I personally do not expect to find the time for it.
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org