Re: [eclipselink-users] Best practices for modularity?

[amphoras <polly.c.chang@xxxxxxxxx>]

Hi Blaise,

Thanks for your detailed and helpful response.  I just have a few more
questions.

> > 1.  What does it mean to have a "primary" project versus "additional"
> > projects in the session?  The documentation talks about how to configure
> > these but doesn't really go into the ramifications.  Does the order of
> the
> > projects matter?

> I never really thought of it as primary vs additional projects.  Each
> project is equal, the order is only 
> significant if you have multiple objects mapped to the same default root
> element.  As a default root 
> element must correspond to only one descriptor.

What I was trying to do was create an incomplete/abstract mapping for a
class in my "common" project.xml file.  Then I created another mapping for
the same class in my "app" project.xml file that fills in the missing pieces
and overrides certain settings from the "common" mapping.  My session.xml
file loads both project files.  

I found that since both mappings are for the same class, whichever one that
I set as the "primary" in the session was wiped out by the second one. 
Actually, all settings were replaced except for one.  The "common" and "app"
versions of the class mappings have different "default root element"
settings, and I found that both were available for unmarshalling.  So the
result was cumulative.  It sounds like you expect that the default root
element should have been replaced by the second class mapping?

---

> > 2.  Is is possible for an application's mappings to override the ones
> from
> > the common project?

> I'll describe a strategy we use to unmarshal our own metadata.  We use 
> the Java version of the metadata  and create a subclass of the project 
> for each version that we distribute.  Each descriptor is built in its 
> own method, and when new features are added the corresponding mapping 
> project overrides the corresponding buildDescriptor method.
> ...

yes, that is the exact behavior that I'm looking for!  Is it possible to do
this using the deployment project.xml files?  I am trying to do as much as I
can using the xml files.  I am ok with creating event listeners like the
amendment method, but I am trying to minimize use of Java for ease of
changing the mappings.

---

> > 3.  Is is possible for the common project to define mappings that are
> > "abstract" or based on interfaces?  I see that there is an
> > XMLChoiceMapping, but I am not sure how to use that because I won't know
> > ahead of time what application-specific class I need to use.  I would
> like
> > to have a common POJO that contains composite objects that are defined
> in
> > the application-specific project.  Is that possible?

> I have seen users make use of our Any mappings for this.  Their scenario 
> is usually the following, they have one OXM project that corresponds to 
> the message envelope, and many OXM projects that correspond to possible 
> payloads.  To implement this they use an XMLAnyObjectMapping to map the 
> message body property on their message object, and then in the payload 
> projects they ensure that all of objects that form the root of the body 
> have default root elements set.  You will need to ensure that the 
> XMLContext is created with both the message and payload projects.

yes, exactly.  I have an element like this:

<Foo>
    <Action></Action>
    <Data></Data>
    <Data></Data>
    ...
</Foo>

"Action" is a class hierarchy of different kinds of actions, and "Data" is a
collection of any type of element.  So I configured "Action" with an
XMLChoiceMapping and "Data" as XMLAnyCollectionMapping, and that works!  I
did try to set "Action" to XMLAnyObjectMapping, but EclipseLink got
confused.  So I guess you can't use two "any" mappings next to one another,
which makes sense.  The XMLChoiceMapping works fine for the "Action".

The only problem is when I try to go roundtrip more than once.  I can
unmarshall the document and marshall it back out, but the Action element is
output with the attribute 'xsi:type="ns1:ProcessType"'.  I don't think this
attribute is allowed by the schema, and when I unmarshall the document
again, I get:

[Fatal Error] :178:72: The prefix "xsi" for attribute "xsi:type" associated
with an element type "ns1:Process" is not bound.

I noticed that the "xsi" namespace is not defined in the output file even
though it was in the original one.  So my questions are:

a.  Can I suppress the xsi:type attribute from being generated?
b.  Failing that, I need to get this attribute added to the schema, correct?  
c.  How do I get the "xsi" namespace to be generated for the output?

---

> > 4.  Is is possible to map different root elements to the same POJO?  Or
> > can I use a regular expression when matching the root element name?  Our
> > schema is defined such that we have root elements with different names
> > that have very similar content, so I'd like to be able to map them to
> the
> > same POJO.  From what I've seen from the code, it looks like I will not
> be
> > able to do this directly.  So I think my alternative is to come up with
> a
> > transformation to apply before unmarshalling and after marshalling to
> > change the root element name.  Or do you have other suggestions?

> You can map multiple root elements to the same POJO.  Currently this can 
> not be done in the UI, but you can create an "After Load" method and 
> modify the descriptor by hand.  You can call 
> "setDefaultRootElement(String)" multiple times on the descriptor.  All 
> of these names will be used to recognize the object during 
> unmarshalling, but the last defaultRootElement set will be used for 
> marshalling.  

Hmm, my scenario is that the class mapping is in the "common" project, and I
won't know what the possible default root elements are ahead of time.  Only
the "app" project will know that, and it needs to define multiple root
elements (around 5).  So I cannot call setDefaultRootElement() from the
amendment method while the "common" project is loading.  This is similar to
the "data" element in question 3 that was solved by the "any" mapping.  I
need to go roundtrip using these many root elements, so marshalling using
the last defined root element also won't work.  

> If you want to use a different root element, you can wrap 
> your object in an instance of org.eclipse.persistence.oxm.XMLRoot of 
> javax.xml.bind.JAXBElement (if your are using JAXB).

can you clarify this?  I've never actually worked with JAXB directly.  So
far I've been very happy to let EclipseLink hide JAXB under the covers.  ;)

If I can marshall to those different root elements using a callback method,
that would be fine.  I can figure out what root element to use based on data
inside the object.

Or... would the "preserve document" setting help in this case?

---

> > 5.  Can you share any other best practices for implementing a modular
> > design with these mappings?

> I mentioned a couple of our most common strategies above.  Can you share 
> more details about the type of modularity you would like to see?

sure, I'll summarize from my response above:
* ability to allow the project.xml files to inherit and override mappings
like you are doing with Java.
* ability to defer defining root elements to another project.xml file.  
* ability to marshall using different root elements using a callback method
or some way to "remember" what was unmarshalled.

Thanks for your help!  This is much easier than debugging random EclipseLink
source code in hope of finding a hint.  :)

--Polly
-- 
View this message in context: http://www.nabble.com/Best-practices-for-modularity--tp18654654p18721663.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.