[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] Best practices for modularity?
|
ah, I see. This is an interesting strategy. It gives me a lot of food for
thought, and I'll definitely keep it in mind.
Thanks,
Polly
Blaise Doughan wrote:
>
> Hi Polly,
>
> I'm going to try and develop this a little more but here are some
> current thoughts:
>
> We use MOXy to map our XML mapping data to our programmatic metadata.
> This means that you could use MOXy to unmarshal your XML metadata files
> into the programmatic metadata:
>
> import java.io.File;
> import
> org.eclipse.persistence.internal.sessions.factories.EclipseLinkObjectPersistenceRuntimeXMLProject;
> import org.eclipse.persistence.oxm.*;
> import org.eclipse.persistence.sessions.Project;
> ...
> EclipseLinkObjectPersistenceRuntimeXMLProject project = new
> EclipseLinkObjectPersistenceRuntimeXMLProject();
> XMLContext xmlContext = new XMLContext(project);
>
> XMLUnmarshaller unmarshaller = xmlContext.createUnmarshaller();
> Project baseProject = (Project) unmarshaller.unmarshal(new
> File("your_base_metadata.xml"));
> Project extensionProject = (Project) unmarshaller.unmarshal(new
> File("your_extension_metadata.xml"));
>
> Then you could pull data from extensionProject into the baseProject,
> useful methods here are the following:
>
> XMLDescriptor customerDescriptor = (XMLDescriptor)
> project.getClassDescriptor(Customer.class);
> XMLDirectMapping firstNameMapping = (XMLDirectMapping)
> customerDescriptor.getMappingForAttributeName("firstName");
>
> Finally you would create an XMLContext on your combined project, if you
> moved everything into your base project, then this would be done as
> follows:
>
> XMLContext xmlContext2 = new XMLContext(baseProject);
>
> ---
>
> Other Items:
>
> * You are correct you can not use multiple Any mappings at the same
> level.
> * To get the xsi prefix to appear in the out document, in the UI be
> sure that in the schemas panel it is selected as a declaration to
> be included, or programmatically add it to the NamespaceResolver
> held onto by the descriptor.
>
>
> -Blaise
>
> amphoras wrote:
>> 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
>>
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>
>
--
View this message in context: http://www.nabble.com/Best-practices-for-modularity--tp18654654p18819875.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.
