Re: Best practices for modularity?

Hi Polly,

I'm glad to hear you are enjoying your experience with EclipseLink, in particular the OXM mapping.  Below is my first stab at an answer based on some things we have done in the past. 

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.

---

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.

In Root Project

public RootProject() {
    super();
    this.addDescriptor(buildFooDescriptor);
}

protected XMLDescriptor buildFooDescriptor() {
    XMLDescriptor fooDescriptor = new XMLDescriptor();
    // set up the descriptor
    return fooDescriptor;
}

In Child Project (Which Extends Root Project)

protected XMLDescriptor buildFooDescriptor() {
    XMLDescriptor fooDescriptor = super.buildFooDescriptor();
    // add to the descriptor
    return fooDescriptor;
}

This strategy is demonstrated in the EclipseLink source code in the following classes:

org.eclipse.persistence.internal.sessions.factories.ObjectPersistenceRuntimeXMLProject.java
org.eclipse.persistence.internal.sessions.factories.ObjectPersistenceRuntimeXMLProject_11_1_1.java
org.eclipse.persistence.internal.sessions.factories.EclipseLinkObjectPersistenceRuntimeXMLProject.java

---

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.

---

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.  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).

---

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?

-Blaise

amphoras wrote:

Does anybody know the answers?  I tried hacking some stuff together but
haven't met any success.  I really need the answers to 3 and 4 the most.

Thanks,
Polly



amphoras wrote:
  

Hi everyone,

I'm back.  :)  I have been using EclipseLink for OXM, and it has succeeded
extremely well for my prototype.  Thank you guys for all your help!  And
congrats on the 1.0 release.  EclipseLink is awesome.  

Now I need to figure out a general strategy for using EclipseLink OXM in
our enterprise.  I'm thinking that we will have some mappings that are
considered "common" and then others that are application-specific and not
shared.  The common vs. application mappings will be in different projects
and deployed as different jars.  I can see that it's possible to partition
the mappings from different projects so that they each have their own
project.xml fiile, and then you can have one session.xml file that is able
to work with multiple projects.xml files (we want to define as much as we
can in the project xml files for easier maintenance).

My questions are:

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?

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

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?

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?

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

Thanks for your help!

Polly


    

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users