Armin Waibel wrote:
Also: * status: +warning re OTM, please help updating the docs!
Isn't a normal note instead of a warning sufficient or do think a warning is needed because of the unsettled status?
That was more of an "eye-catcher" for us, I planned to remove both notice/warning before commiting anything. I just put this up big where I had no clue what to write. :)
I vote to keep the "eye-catcher" in OTM section of status page (using a <note> element) to emphasize that work currently stopped.
* status: +notice/fixme re S.O.D.A., please help updating the docs!
AFAIK long time ago it was decided that the SODA support will be removed (maybe I'm wrong), because no one ever used this api.
OK, I'll drop it from the doco again until further notice, but I think: *) if it is usable, why not mention it?
Sorry, I never test it.
*) if it us unsuable, why not remove it from both docs and code?
Maybe we should discuss about the SODA api in a separate thread again and remove it if all agree.
Update the texts for the "Testing" section.
+1
Suggest to remove in all summary.xml files the <section> element to suppress the TOC at the beginning of the document. On a summary site a TOC is not needed.
Yes, I thought so too- it looked a bit strange with a redundand TOC like so:
TOC TITLE link to boxed title
[BOXED TITLE]
paragraph about title
It's really rubbing it in, in the readers face? :)
I'll have a look a changing the boxed title into just title for all of those.
Thanks. I found redundand TOC/Introduction in doc index page too. http://people.apache.org/~mkalen/ojb/site/docu/index.html
I took the latest descriptions from Commons Pool and Commons DBCP websites and updated
repository.dtd (what you see on the webpage is copied from repository.dtd).
(Note that there is a new 'minIdle' marked "since OJB 1.0.4", since it only exists in
my local codebase yet. When upgrading commons pool we got this one "secretly" with
a backwards compatible default of 0. I will add it to repository.dtd and connection conf.)
Could we add these properties too (to enable prepared statement caching in DBCP, as suggested by you in another thread)?
poolPreparedStatements
maxOpenPreparedStatements
Yup, they are in my code and I am running tests at the moment. I can't test those very well because they conflict with the same concept (PreparedStatement caching) in the Oracle JDBC-driver, I will run it against HSQLDB also since the DBCP solution is pure POJO-based and has no driver requierments at all. Ie, I _think_ it should be good for MaxDB/SapDB.
I'm finishing the tests/comitts for a few smaller updates in connection factories in a few hours.
Great! Don't be in such a hurry, you not paid for it ;-)
http://people.apache.org/~mkalen/ojb/site/docu/guides/deployment.html#Introduction
+0, I run my tests against JBoss 3.2.3. Think this version is J2EE 1.3 compliant, never tested with JBoss 4.0. Do we have to make a recommendation?
Not at all, I just scanned many documents quickly and thought that "hey, J2SDK 1.4 is not exactly the void and unknown - do we really mean what we say here?".
If you say we do, I agree by default. :)
I would suggest to remove this recommendation. J2EE 1.4/1.3 there is no difference in the JTA and the TxManager is the starting point for OJB to participate in the JTA-tx.
regards, Armin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
