You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Borut Bolčina <bo...@gmail.com> on 2010/02/12 12:57:30 UTC
Merging Configuration from Multiple Deployment Units
Hello,
I have two projects (jars) - each is only having Cayenne Data Objects for
two different models/two different databases.
project-model1:
├───java
│ └───si
│ └───planet9
│ └───logotypes
│ └───model
│ │ Logo.java
│ └───auto
│ _Logo.java
│
└───resources
cayenne.xml
LogotypesMap.map.xml
project-model2:
├───java
│ ├───com
│ │ └───interseek
│ │ └───startpage
│ │ └───model
│ │ │ Fund.java
│ │ └───auto
│ │ _Fund.java
└───resources
cayenne.xml
StartpageMap.map.xml
Some of my web apps need project-model1, some project-model2 and some could
use both.
cayenne.xml for project-model1:
<?xml version="1.0" encoding="utf-8"?>
<domains project-version="3.0.0.1">
<domain name="InterseekDomain">
<map name="LogotypesMap" location="LogotypesMap.map.xml"/>
<node name="LogotypesNode"
datasource="dbcp-logotypes.properties"
factory="org.apache.cayenne.conf.DBCPDataSourceFactory">
<map-ref name="LogotypesMap"/>
</node>
</domain>
</domains>
and for project-model2:
<?xml version="1.0" encoding="utf-8"?>
<domains project-version="3.0.0.1">
<domain name="InterseekDomain">
<map name="StartpageMap" location="StartpageMap.map.xml"/>
<node name="StartpageNode"
datasource="dbcp.properties"
factory="org.apache.cayenne.conf.DBCPDataSourceFactory">
<map-ref name="StartpageMap"/>
</node>
</domain>
</domains>
I was hoping the two domains will get merged and so both datamaps will get
loaded.
The Logo data object is from LogotypesNode and the Fund data object is from
StartpageNode. The code
ObjectContext context = DataContext.createDataContext();
SelectQuery q = new SelectQuery(Logo.class);
List<Logo> logos = context.performQuery(q);
for (Logo logo : logos) {
logger.info(logo);
}
q = new SelectQuery(Fund.class);
List<Fund> funds = context.performQuery(q);
for (Fund fund : funds) {
logger.info(fund);
}
prints out:
DEBUG [12:33:00.020] using domain file name: cayenne.xml
DEBUG [12:33:00.021] initialize starting.
INFO [12:33:00.030] started configuration loading.
INFO [12:33:00.032] loaded domain: InterseekDomain
INFO [12:33:00.083] loaded <map name='LogotypesMap'
location='LogotypesMap.map.xml'>.
INFO [12:33:00.085] loading <node name='LogotypesNode'
datasource='dbcp-logotypes.properties'
factory='org.apache.cayenne.conf.DBCPDataSourceFactory'
schema-update-strategy='org.apache.cayenne.access.dbsync.SkipSchemaUpdateStrategy'>.
INFO [12:33:00.092] using factory:
org.apache.cayenne.conf.DBCPDataSourceFactory
DEBUG [12:33:00.093] DBCP Properties: {cayenne.dbcp.validationQuery="SELECT
1 FROM AUTO_PK_SUPPORT;", cayenne.dbcp.url=jdbc:mysql://
dev.interseek.com:3306/logotypes?characterEncoding=utf8&autoReconnect=true,
cayenne.dbcp.maxActive=50, cayenne.dbcp.maxIdle=8,
cayenne.dbcp.password=masterkey, cayenne.dbcp.maxWait=10000,
cayenne.dbcp.minIdle=5, cayenne.dbcp.driverClassName=com.mysql.jdbc.Driver,
cayenne.dbcp.username=backend}
INFO [12:33:00.109] loaded datasource.
INFO [12:33:00.110] no adapter set, using automatic adapter.
INFO [12:33:00.118] loaded map-ref: LogotypesMap.
DEBUG [12:33:00.119] added domain: InterseekDomain
INFO [12:33:00.119] finished configuration loading in 89 ms.
DEBUG [12:33:00.119] initialize finished.
INFO [12:33:00.200] --- will run 1 query.
INFO [12:33:00.376] --- transaction started.
DEBUG [12:33:00.386] searching for resource under:
org/apache/cayenne/dba/mysql/types.xml
INFO [12:33:00.405] Detected and installed adapter:
org.apache.cayenne.dba.mysql.MySQLAdapter
INFO [12:33:00.436] SELECT t0.url_firma, t0.url_image, t0.url_hash_image,
t0.url_tis, t0.url_bizi, t0.url, t0.id FROM logo t0 - prepared in 24 ms.
INFO [12:33:00.453] === returned 0 rows. - took 42 ms.
INFO [12:33:00.454] +++ transaction committed.
ERROR [12:33:00.459] Job reader.gold-logotypes threw an unhandled Exception:
org.apache.cayenne.CayenneRuntimeException: [v.3.0RC1 Jan 05 2010 14:44:59]
No DataMap found, can't route query
org.apache.cayenne.query.SelectQuery@1e881b6[root=class
com.interseek.startpage.model.Fund,name=<null>]
at org.apache.cayenne.query.AbstractQuery.route(AbstractQuery.java:134)
I am using Cayenne 3.0RC1.
What is the easiest way of doing this? I was reading
http://cwiki.apache.org/CAY/runtime-metadata-merging.html, but am I doing
something wrong?
Thanks,
Borut
Re: wiki pages design
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 17/02/10 9:29 PM, Andrus Adamchik wrote:
>
> * Authoring process (do we have to edit XML by hand?)
That's one way (and for developers not rocket science since the xml is fairly simple). I looked long and hard for the easiest to use tool for our technical writer here (who isn't particularly a developer) and the one I settled on was Oxygen Author. Not free. There are some free tools as well, but not as wysiwyg. I never tried OpenOffice.
> * Maven support
Should be easy I think. At the worst, maven can call ant scripts. I'm happy to donate ant scripts I've written, but there isn't much too them.
> * I assume the same doc source can be published as HTML on the web, and
> as PDF for the release. What does it take to wrap HTML in our site
> template? A Velocity template I guess?
That's the really beautiful part. I personally like XSLT, but there are a few ways to get the output. We also set up PDF output with minimal effort.
In short:
* authoring tools for docbook are poor to middling, but Confluence is hardly perfect
* flexibility of output is great
* commit the whole thing into svn (branching and everything else that entails) is brilliant
* moving everything across is lots and lots of work, especially getting all the links to still link and tying in all the screenshots
Ari Maniatis
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: wiki pages design
Posted by "Adrian A." <a....@googlemail.com>.
If you decide to use Docbook, I would gladly help with the conversion
> of the Cayenne documentation.
>>>>
>>>
>>> Before we decide, I guess somebody has to build a prototype showing how
>>> that would work using a few pages from the User Guide.
>>>
>> May I get an export of the WIKI content that might be desired to be
>> converted to Docbook? Confluence has this functionality.
>>
>> I can see the WIKI pages (individually), but I don't have the rights to
>> export them myself as a package :(.
>>
>
> I'll email them to you now. They come out as XML, so maybe you could write
> an XSLT to convert to docbook.
>
Thank you for the export.
I'll try to see how much can be automated.
Adrian.
Re: wiki pages design
Posted by "Adrian A." <a....@gmail.com>.
>> If you decide to use Docbook, I would gladly help with the conversion
>> of the Cayenne documentation.
>
> Before we decide, I guess somebody has to build a prototype showing how
> that would work using a few pages from the User Guide. I am interested
> in the following aspects. Ari or Adrian could you please comment:
>
> * Authoring process (do we have to edit XML by hand?)
The authoring process can be done in many ways - from manual XML edit
with smart assistance from the IDE (or various IDE plug-ins), to using
various WYSIWYG tools.
There are a few commercial WYSIWYG tools, but fortunately all I've
tried, had also free licenses for open source projects. E.g.
http://www.xmlmind.com/xmleditor/ was very efficient for me.
Even OpenOffice seems to have some Docbook support.
Regarding the typical workflow, I would differentiation:
1. Writing allot of documentation at once in one place (e.g. one entire
chapter, or at least more than one page), gives the WYSIWYG tool
an advantage (but I suppose this would be rare for Cayenne now).
2. Making small (one or two phrases, or even a few words)
additions/chanegs, makes the direct edit in the IDE faster.
> * Maven support
I can't tell much about Maven, but with ANT for the Click like template
(that I'm reusing allot for it's simplicity), it requires just typing:
%> ant get-deps
%> ant
and everything gets generated.
> * I assume the same doc source can be published as HTML on the web, and
> as PDF for the release.
Yes. For Click it generates 3 types of files (2 HTML and 1 PDF). See
here the results 3 type of results:
http://click.apache.org/docs/user-guide.html
> What does it take to wrap HTML in our site
> template? A Velocity template I guess?
Yes, Velocity would do it too.
XSite and SiteMesh are also good, but there are many
tools that can 're-decorate' HTML content statically or dynamically.
Also, if you would like to see a "prototype Docbook" it in action, I
would suggest taking a look at the Click documentation - since it's a
very good prototype (IMHO), and build it from source to see the process.
You can checkout from here:
http://svn.apache.org/repos/asf/click/trunk/click/documentation/
and build with the steps I described above in the "xdocs" subdirectory.
Adrian.
Re: wiki pages design
Posted by Joseph Schmidt <jo...@yahoo.com>.
>>>> If you decide to use Docbook, I would gladly help with the conversion
>>>> of the Cayenne documentation.
>>>
>>> Before we decide, I guess somebody has to build a prototype showing how
>>> that would work using a few pages from the User Guide.
>> May I get an export of the WIKI content that might be desired to be
>> converted to Docbook? Confluence has this functionality.
>>
>> I can see the WIKI pages (individually), but I don't have the rights to
>> export them myself as a package :(.
>
> I'll email them to you now. They come out as XML, so maybe you could
> write an XSLT to convert to docbook.
Even if Confluence is very cool, we abandoned Confluence in many
internal projects because it was not possible to export the content as a
set of WIKI pages (in WIKI format in a ZIP) - as it is possible with
most other WIKI software.
That XML backup is very convoluted, and mostly re-usable only in
Confluence, but not when you upgrade over more versions: - e.g. what you
export with Confluence 2.10.3 Build (what Apache is using now), can't be
imported in the latest version 3.1.x - because it say's that it can't
import individual "Spaces" :).
Joseph.
Re: wiki pages design
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 21/02/10 6:26 AM, Adrian A. wrote:
>>> If you decide to use Docbook, I would gladly help with the conversion
>>> of the Cayenne documentation.
>>
>> Before we decide, I guess somebody has to build a prototype showing how
>> that would work using a few pages from the User Guide.
> May I get an export of the WIKI content that might be desired to be
> converted to Docbook? Confluence has this functionality.
>
> I can see the WIKI pages (individually), but I don't have the rights to
> export them myself as a package :(.
I'll email them to you now. They come out as XML, so maybe you could write an XSLT to convert to docbook.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: wiki pages design
Posted by "Adrian A." <a....@gmail.com>.
>> If you decide to use Docbook, I would gladly help with the conversion
>> of the Cayenne documentation.
>
> Before we decide, I guess somebody has to build a prototype showing how
> that would work using a few pages from the User Guide.
May I get an export of the WIKI content that might be desired to be
converted to Docbook? Confluence has this functionality.
I can see the WIKI pages (individually), but I don't have the rights to
export them myself as a package :(.
Thank you,
Adrian.
Re: wiki pages design
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Feb 17, 2010, at 12:01 PM, Adrian A. wrote:
> If you decide to use Docbook, I would gladly help with the
> conversion of the Cayenne documentation.
Before we decide, I guess somebody has to build a prototype showing
how that would work using a few pages from the User Guide. I am
interested in the following aspects. Ari or Adrian could you please
comment:
* Authoring process (do we have to edit XML by hand?)
* Maven support
* I assume the same doc source can be published as HTML on the web,
and as PDF for the release. What does it take to wrap HTML in our site
template? A Velocity template I guess?
Andrus
Re: wiki pages design
Posted by "Adrian A." <a....@gmail.com>.
>> It's very efficient, and Docbook was made exactly for this kind of
>> scenarios.
>
> Sure, and in fact I'm moving across to docbook at work. If you are
> volunteering to migrate all the hundreds of pages of Confluence over to
> docbook, I'm sure there would be enthusiasm....
If you decide to use Docbook, I would gladly help with the conversion of
the Cayenne documentation.
I used Docbook , i.e. Click Framework Documentation (that mentioned in
my previous post) as a template for the documentation of several
internal projects, and using ANT is very very simply (I'm not sure
though what would be required to make it run under Maven).
Adrian.
Re: wiki pages design
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 17/02/10 8:46 PM, Adrian A. wrote:
> It's very efficient, and Docbook was made exactly for this kind of
> scenarios.
Sure, and in fact I'm moving across to docbook at work. If you are volunteering to migrate all the hundreds of pages of Confluence over to docbook, I'm sure there would be enthusiasm....
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: wiki pages design
Posted by "Adrian A." <a....@gmail.com>.
> Then we lose accumulated search ranking for the old docs, but I guess if
> we do it once, it will straighten things over time.
Just curious: why don't you use Docbook for your documentation?
An apoach that e.g. Click Framework is using too? (by the help of
another Apache project - Velocity DBF:
http://velocity.apache.org/docbook/
with some small modifications hosted here:
http://code.google.com/p/click-docbook/
to have a simpler automation.
You can see it how it works in the Click SVN in "click/documentation/xdocs"
)
It's very efficient, and Docbook was made exactly for this kind of
scenarios.
Adrian.
Re: wiki pages design
Posted by Andrus Adamchik <an...@objectstyle.org>.
Then we lose accumulated search ranking for the old docs, but I guess
if we do it once, it will straighten things over time.
Andrus
On Feb 17, 2010, at 10:53 AM, Aristedes Maniatis wrote:
> On 17/02/10 7:48 PM, Andrus Adamchik wrote:
>> On a related note, we need some visual separation of the docs for
>> different versions on the site. I've seen more than one case when
>> users
>> go confused, e.g. when Google returns an old version of the docs
>> for a
>> given search term. I guess after 3.0 goes final, we can remove
>> 1.2/2.0
>> docs from the site completely, and refer people to Cayenne
>> downloads for
>> the old docs, and then style 3.1 and 3.0 docs differently.
>>
>> (Also as I mentioned before, multiple versions of the docs reduce our
>> google ranking for a given search term, but that's a separate story).
>
> We could publish robots.txt to keep Google out of everything but the
> current docs...
>
> Ari
>
>
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
Re: wiki pages design
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 17/02/10 7:48 PM, Andrus Adamchik wrote:
> On a related note, we need some visual separation of the docs for
> different versions on the site. I've seen more than one case when users
> go confused, e.g. when Google returns an old version of the docs for a
> given search term. I guess after 3.0 goes final, we can remove 1.2/2.0
> docs from the site completely, and refer people to Cayenne downloads for
> the old docs, and then style 3.1 and 3.0 docs differently.
>
> (Also as I mentioned before, multiple versions of the docs reduce our
> google ranking for a given search term, but that's a separate story).
We could publish robots.txt to keep Google out of everything but the current docs...
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: wiki pages design
Posted by Andrus Adamchik <an...@objectstyle.org>.
On a related note, we need some visual separation of the docs for
different versions on the site. I've seen more than one case when
users go confused, e.g. when Google returns an old version of the docs
for a given search term. I guess after 3.0 goes final, we can remove
1.2/2.0 docs from the site completely, and refer people to Cayenne
downloads for the old docs, and then style 3.1 and 3.0 docs differently.
(Also as I mentioned before, multiple versions of the docs reduce our
google ranking for a given search term, but that's a separate story).
Andrus
On Feb 14, 2010, at 12:53 AM, Aristedes Maniatis wrote:
> On 13/02/10 11:03 PM, Andrus Adamchik wrote:
>> On a side note, we need a distinct style for the wiki scratch
>> pages, so
>> that they are not mistaken for the official documentation.
>
> I'll have a think about that.
>
>
> Ari
>
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
wiki pages design
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 13/02/10 11:03 PM, Andrus Adamchik wrote:
> On a side note, we need a distinct style for the wiki scratch pages, so
> that they are not mistaken for the official documentation.
I'll have a think about that.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Merging Configuration from Multiple Deployment Units
Posted by Borut Bolčina <bo...@gmail.com>.
Thanks Andrus,
so the approach I would take now is NOT to have cayenne in any project-model
jar.
Those deployment units should only have *.map.xml file and then all
applications needing one or more of the data objects from those deployment
units have a custom cayenne.xml.
This would be awkward for the modeller if at all possible?
The other scenario is of course for each top project to have copies of
*.map.xml files of those deployment units holding data objects. This
violates DRY principle which brings a maintenance responsibility for syncing
mapping files across all projects.
I can also imagine having one giant project-model with all the data objects
defined in it for all the different databases in a company (across all
company projects), but that doesn't seem very modular.
Anyone with any good practice advice?
Cheers,
Borut
2010/2/13 Andrus Adamchik <an...@objectstyle.org>
>
> On Feb 12, 2010, at 1:57 PM, Borut Bolčina wrote:
>
>
>> What is the easiest way of doing this? I was reading
>> http://cwiki.apache.org/CAY/runtime-metadata-merging.html, but am I doing
>> something wrong?
>>
>
> This page is a design document. Cayenne doesn't support merging multiple
> projects out of the box, but hopefully will in 3.1. For now you'd have to
> implement your own merging algorithm, that shouldn't be too hard for a
> specific case.
>
> On a side note, we need a distinct style for the wiki scratch pages, so
> that they are not mistaken for the official documentation.
>
> Andrus
>
>
Re: Merging Configuration from Multiple Deployment Units
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Feb 12, 2010, at 1:57 PM, Borut Bolčina wrote:
>
> What is the easiest way of doing this? I was reading
> http://cwiki.apache.org/CAY/runtime-metadata-merging.html, but am I
> doing
> something wrong?
This page is a design document. Cayenne doesn't support merging
multiple projects out of the box, but hopefully will in 3.1. For now
you'd have to implement your own merging algorithm, that shouldn't be
too hard for a specific case.
On a side note, we need a distinct style for the wiki scratch pages,
so that they are not mistaken for the official documentation.
Andrus