Here i will show how we can deploy an xsd based artifacts application to web logic server and access them as directory on server.
Advantage:
- One time deployment.
- any future changes are just modify the file in directory and takes effect on application
- accessible through browser
Disadvantage:
- single point failure (until unless file system is configured as fail-over detection)
- you need to change host url/port before migration VS mds xpath to access artifacts
How to:
- prepare directory system and put your xsd artifacts accordingly
- create META-INF,WEB-INF directory at top level under application folder
- under META-INF directory, create file application.xml and specify web-uri (XYZ.war) and context-root (root path from where you can access /XYZ)
- under WEB-INF directory create two files web.xml and weblogic.xml
- web.xml would be normal default file no changes
- weblogic.xml would be bet here how do you want to access your artifacts i mean through file system or just an deployed application
-- if as file system then specify virtual-directory-mapping node element and define local-path(from where you wanna access) and url-pattern (what type of url should be served from this location).
Now package your application and deploy on weblogic server.
Now you can access your artifacts from specified location and refer them in your local wsdls or anywhere. Remember to change these referential URLS while deploying on other environments.
Happy coding.
Subscribe to:
Post Comments (Atom)
2 comments:
This project 'XrefDVMFiles10g' needs to be deployed using a MAP application. No one is talking about that yet. Other steps are simple enough, but there are no documents covering Metadata Artifact Repository(MAR) deployment.
The MDS is basically an XML store with transaction capabilities, versioning, merging and a persistence framework optimized to work with XML nodes and attributes. It is somehow similar to an ORM, but for XML entities. The persistence framework has two adapters that can persist the store to a database or to a folder on disk. The database store has more advanced features is the recommended way of working with MDS. The file store is useful for at development time, because one can change the files manually.
The same as an ORM needs a configuration file to know the environment (e.g. hibernate.cfg.xml), the MDS uses its own config file named adf-config.xml. You can find this file automatically generated by JDeveloper in any ADF FMW project, with a default configuration.
The file has several configuration sections, but one is of particular interest, and it's called
adf-mds-config:
/com/tutorial/model/schema/beanType.xsd
......
......
In the above configuration, the most interesting elements are: type-definitions, namespace and metadata-store:
type-definitions: here you can define custom XSD nodes that describe custom entities. The easiest way to generate XSD definitions is with the help of JAXB: you can define you data model as serializable POJOs (same as JPA entities) and then use Oracle's MDSBeanGenTool (located in the mdstools.jar file) java utility to generate the schema definition.
namespace: here you must define the virtual paths within the MDS repository, so the persistence framework will know where to store and find the files
metadata-store: this node configures the persistence adaper. It can be either DBMetadataStore, ClassPathMetadataStore, FileMetadataStore or ServletContextMetadataStore.
Once you have these in place, you are ready to connect to the metadata store:
MDSConfig config = new MDSConfig(new File(path to adf-config.xml));
MDSInstance mdsInstance = MDSInstance.getOrCreateInstance("test-instance", config);
MDSSession mdsSession = mdsInstance.createSession(new SessionOptions(null, null, new CustConfig(new CustClassListMapping[0])), null);
The mdsSession variable holds the session instance for the MDS repository. A MDSSession is similar to the Hibernate Session object. It will handle all persistence operations and holds a transactional context.
You can now query the repository to find the desired items. For example, to find all files in repository you would write:
NameQueryImpl query = new NameQueryImpl(mdsSession, ConditionFactory.createNameCondition("/", "%", true));
Iterator result = query.execute();
while(result.hasNext()) {
QueryResult qr = result.next();
// ...do your magic here...
}
Using the above query, you would only retrieve the names of the items inside the repository. To get the actual instance of an MDS object ( MetadataObject ), you have to write:
MOReference ref = mdsSession.getMOReference(path inside the repository);
MetadataObject mo = mdsSession.getMetadataObject(ref);
Once you have the MetadataObject instance, you can retrieve the XML document behind with mo.getDocument(); Having the DOM XML Document instance, you can alter the XML file and save it hack to the repository by issuing mdsSession.flushChanges();
Using the information briefly described here and with a little bit of SWING knowledge, you can easily write an MDS browser and XML editor to change what you want inside the repository.
Post a Comment