Hi,
I have implemented a solution to serialize metadata. This is a much simpler
implementation, and is independent of the artifact types. You can find it
at [1].
Here We are providing an API to save a given set of metadata/parameters as
key-value pairs. The artifact name, ArtifactType [2], and a set of
key-value pairs should be provided when invoking this API. Then, this API
serializes the contents to a file by leveraging Java Properties class. Any
artifact type that require metadata persistence can use this API.
TODO:
Use of OSGi declarative services to
retrieve DeploymentArtifactMetadataFactory
instance. DeploymentArtifactMetadataFactory is a per-tenant instance. And,
is currently stored/retrieved via a AxisConfiguration parameter. Can we use
OSGi declarative services to retrieve this instance in a tenant aware way?
A sample use of this API would look like the following. This shows
persisting of the BAM webapp stats enable property for a given webapp.
private void persistWebappMetadata(WebApplication webApplication,
AxisConfiguration axisConfig) throws
ArtifactMetadataException, AxisFault {
String bamStatsEnabled =
webApplication.findParameter(WebappsConstants.ENABLE_BAM_STATISTICS);
if (bamStatsEnabled == null) {
webApplication.addParameter(WebappsConstants.ENABLE_BAM_STATISTICS,
Boolean.FALSE.toString());
}
* ArtifactType type = new
ArtifactType(WebappsConstants.WEBAPP_FILTER_PROP,
WebappsConstants.WEBAPP_METADATA_DIR);*
*
*
* ArtifactMetadataManager manager =
DeploymentArtifactMetadataFactory.getInstance(axisConfig).*
* getMetadataManager();*
* manager.setParameter(webApplication.getContextName(), type,*
* WebappsConstants.ENABLE_BAM_STATISTICS,
Boolean.FALSE.toString());*
}
Please share your thoughts.
[1]
https://svn.wso2.org/repos/wso2/carbon/kernel/trunk/core/org.wso2.carbon.core/src/main/java/org/wso2/carbon/core/persistence/metadata
[2]
https://svn.wso2.org/repos/wso2/carbon/kernel/trunk/core/org.wso2.carbon.core/src/main/java/org/wso2/carbon/core/persistence/metadata/ArtifactType.java
Thanks,
KasunG
On Wed, Feb 6, 2013 at 9:01 AM, Pradeep Fernando <prad...@wso2.com> wrote:
> Hi KasunG,
>
> Even though we (sameera , me ) suggested a more generalized approach for
> meta-data persistence, we did not finalize the architecture. Persistence
> layer should only provide the core functionality. The tasks (serializing
> metadata/deploying metadata,etc) should be delegated to implementations.
> (Even you have mentioned some implementation details thats what you are
> trying to explain as well i guess :) )
>
> We have to think about how we can plugin those implementations to
> persistence layer. config files does not make sense IMHO. Making use of
> OSGi services layer is one option.
>
> lets have a brainstorm session + architecture session sometime later.
>
> thanks,
> --Pradeep
>
>
> On Tue, Feb 5, 2013 at 9:00 PM, Kasun Gajasinghe <kas...@wso2.com> wrote:
>
>> Hi,
>>
>> We are doing $subject to have one API for all the artifact metadata types
>> like service/module metadata, ghost service/webapp metadata etc. Let me
>> briefly explain what a client should do to use this API.
>>
>> Have a metadata object, say, MetadataObject, via a factory instance, say,
>> MetadataFactory. This metadata object is common to all the types.
>> We enter the metadata we need to persist as *key-value pairs. /*A simple
>> hashmap like put operation/
>> After we enter all the data, we say metadataObject.save().
>>
>> We call the relevant persistence implementations depending on the
>> artifact type from the metadataObject#save method.
>>
>> But we have a question on using key-value pairs to set artifact
>> metadata. This would work just fine for linear data. For ex. as I got to
>> know from Kishanthan, this would work fine for ghost webapp metadata
>> because the metadata is stored in a linear manner (thought it's in XML
>> format) [1]. We could set values like OM elements as well.
>>
>> But we're not sure how to set key-value pairs effectively for cases like
>> service metafile, ghost service metadata etc. Sometimes these contains a
>> XML hierarchy that can go 4 levels deep. In that kind of scenario, how can
>> we formulate appropriate keys for key-value pairs? We use xpath for service
>> metafiles, but use of XPaths clumsy I guess.
>>
>> The upcoming CXF metadata support will be developed based on this API.
>> So, we may not need to concern about the said problem in that scenario. But
>> it's better to have a good design to begin with.
>>
>> Any ideas?
>>
>> [1] <webApplication name="/jaxrs" contextPath="/jaxrs"
>> jaxContext="/services" jaxMapping="JAXServlet" webappFilter="jaxWebapp"
>> .../>
>>
>> Thanks,
>> KasunG
>>
>> --
>> *Kasun Gajasinghe*
>> Software Engineer;
>> Development Technologies Team, WSO2 Inc.; http://wso2.com
>>
>> ,
>> *email: **kasung AT spamfree wso2.com
>>
>> ** cell: **+94 (77) 678-0813*
>> *linked-in: *http://lk.linkedin.com/in/gajasinghe
>>
>> *
>> *
>> *blog: **http://blog.kasunbg.org* <http://blog.kasunbg.org>
>>
>> *
>> twitter: **http://twitter.com/kasunbg* <http://twitter.com/kasunbg>
>>
>> *
>> *
>>
>
>
>
> --
> *Pradeep Fernando*
> Member, Management Committee - Platform & Cloud Technologies
> Senior Software Engineer;WSO2 Inc.; http://wso2.com
>
> blog: http://pradeepfernando.blogspot.com
> m: +94776603662
>
--
*Kasun Gajasinghe*
Software Engineer;
Development Technologies Team, WSO2 Inc.; http://wso2.com
,
*email: **kasung AT spamfree wso2.com
** cell: **+94 (77) 678-0813*
*linked-in: *http://lk.linkedin.com/in/gajasinghe
*
*
*blog: **http://kasunbg.org* <http://kasunbg.org>
*
twitter: **http://twitter.com/kasunbg* <http://twitter.com/kasunbg>
*
*
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
