|
Home > Archive > Apache JDO Project > December 2005 > Tests for execution in managed environments / J2EE containers?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Tests for execution in managed environments / J2EE containers?
|
|
| Jörg von Frantzius 2005-12-13, 7:45 am |
| Hi,
does the TCK currently include any tests for managed environments?
Thanks for information,
Jörg
--
________________________________________
__________________
Dipl.-Inf. Jörg von Frantzius | artnology GmbH
| Milastr. 4
Tel +49 (0)30 4435 099 26 | 10437 Berlin
Fax +49 (0)30 4435 099 99 | http://www.artnology.com
_______________________________|________
__________________
| |
| erik@jpox.org 2005-12-13, 7:45 am |
| No.
Quoting Jörg von Frantzius <joerg.von.frantzius@artnology.com>:
> Hi,
>
> does the TCK currently include any tests for managed environments?
>
> Thanks for information,
> Jörg
>
> --
> ________________________________________
__________________
> Dipl.-Inf. Jörg von Frantzius | artnology GmbH
> | Milastr. 4
> Tel +49 (0)30 4435 099 26 | 10437 Berlin
> Fax +49 (0)30 4435 099 99 | http://www.artnology.com
> _______________________________|________
__________________
>
>
| |
| Michael Bouschen 2005-12-13, 7:45 am |
| Hi Jörg,
> Hi,
>
> does the TCK currently include any tests for managed environments?
not that I'm aware of.
Regards Michael
>
> Thanks for information,
> Jörg
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
| |
| Jörg von Frantzius 2005-12-13, 7:45 am |
| Alright, does anybody know if there is some rationale behind that? I'd
think that a majority of the JDO users are writing web applications and
need to run their stuff in an application server.
Doesn't that mean the TCK is of limited use for the majority of JDO users?
(Trying to be a little provocative here, the TCK surely still is very
useful ;)
erik@jpox.org schrieb:
> No.
>
> Quoting Jörg von Frantzius <joerg.von.frantzius@artnology.com>:
>
>
>
>
>
>
>
>
--
________________________________________
__________________
Dipl.-Inf. Jörg von Frantzius | artnology GmbH
| Milastr. 4
Tel +49 (0)30 4435 099 26 | 10437 Berlin
Fax +49 (0)30 4435 099 99 | http://www.artnology.com
_______________________________|________
__________________
| |
| erik@jpox.org 2005-12-13, 7:45 am |
| To automate a JCA adapter test suite is hard. If you point us one open
source/free JCA container+Tx manager easy to launch from a junit test, I would
be glad to provide some unit tests.
Quoting Jörg von Frantzius <joerg.von.frantzius@artnology.com>:
> Alright, does anybody know if there is some rationale behind that? I'd
> think that a majority of the JDO users are writing web applications and
> need to run their stuff in an application server.
>
> Doesn't that mean the TCK is of limited use for the majority of JDO users?
> (Trying to be a little provocative here, the TCK surely still is very
> useful ;)
>
>
> erik@jpox.org schrieb:
>
>
> --
> ________________________________________
__________________
> Dipl.-Inf. Jörg von Frantzius | artnology GmbH
> | Milastr. 4
> Tel +49 (0)30 4435 099 26 | 10437 Berlin
> Fax +49 (0)30 4435 099 99 | http://www.artnology.com
> _______________________________|________
__________________
>
>
| |
| erik@jpox.org 2005-12-13, 5:45 pm |
| I found one project that may be interesting. It is called Jencks (David Jencks),
and apache licensed.
There are some samples of it in combination of Spring. Could the TCK incorporate
JCA adapter tests if technically feasible?
Regards,
Quoting erik@jpox.org:
> To automate a JCA adapter test suite is hard. If you point us one open
> source/free JCA container+Tx manager easy to launch from a junit test, I
> would
> be glad to provide some unit tests.
>
> Quoting Jörg von Frantzius <joerg.von.frantzius@artnology.com>:
>
>
>
>
>
| |
| Jörg von Frantzius 2005-12-13, 5:45 pm |
| One approach might by to start up the app server and have some kind of
startup class run the tests, i.e. a class that is invoked by the app
server upon startup.
It might be possible to startup the app server from within JUnit, but if
not that only means a second launch has to be made next to launching the
JUnit test suite.
erik@jpox.org schrieb:
> To automate a JCA adapter test suite is hard. If you point us one open
> source/free JCA container+Tx manager easy to launch from a junit test, I would
> be glad to provide some unit tests.
>
> Quoting Jörg von Frantzius <joerg.von.frantzius@artnology.com>:
>
>
>
>
>
>
>
>
--
________________________________________
__________________
Dipl.-Inf. Jörg von Frantzius | artnology GmbH
| Milastr. 4
Tel +49 (0)30 4435 099 26 | 10437 Berlin
Fax +49 (0)30 4435 099 99 | http://www.artnology.com
_______________________________|________
__________________
| |
| Jörg von Frantzius 2005-12-14, 7:45 am |
| I think it would be nice if the tests would also say something about the
real world usability of the tested JDO implementation, i.e. whether it
will run inside e.g. the most widespread open-source J2EE container.
What does it help to be standards-compliant if e.g. my appserver ist
much more picky about things than the test container? It turned out e.g.
that JBoss doesn't like any calls to begin(), commit() or rollback() on
a java.sql.Connection that has autoCommit set to true.
How about this:
* a JBoss server is started from within the JUnit testsuite (the
JBoss installation would best be included in the test project) in
a separate VM,
* (the implementation is deployed in it using .rar and ds.xml)
* the test methods invoke individual corresponding JSPs in the JBoss
that try-catch Exception and either return a success HTML or the
stacktrace of any occurred exception
erik@jpox.org schrieb:
> I found one project that may be interesting. It is called Jencks (David Jencks),
> and apache licensed.
>
> There are some samples of it in combination of Spring. Could the TCK incorporate
> JCA adapter tests if technically feasible?
>
> Regards,
>
> Quoting erik@jpox.org:
>
>
>
>
>
>
>
>
--
________________________________________
__________________
Dipl.-Inf. Jörg von Frantzius | artnology GmbH
| Milastr. 4
Tel +49 (0)30 4435 099 26 | 10437 Berlin
Fax +49 (0)30 4435 099 99 | http://www.artnology.com
_______________________________|________
__________________
| |
| Karan Malhi 2005-12-14, 5:45 pm |
| Hi Jorg,
Getting an exception when in auto-commit mode should not be a JBoss specific
thing. Below is the description of the commit method from
java.sql.Connection class:
commit
public void *commit*()
throws SQLException
<file:///c:/Documents%20and%20Settings/karan/My%20Documents/DOCS/j2sdk1.4.2/docs/api/java/sql/SQLException.html>
*Throws:* SQLException<file:///c:/Documents%20and%20Settings/karan/My%20Documents/DOCS/j2sdk1.4.2/docs/api/java/sql/SQLException.html>-
if a database access error occurs or this
Connection object is in auto-commit mode
On 12/14/05, Jörg von Frantzius <joerg.von.frantzius@artnology.com> wrote:
>
> I think it would be nice if the tests would also say something about the
> real world usability of the tested JDO implementation, i.e. whether it
> will run inside e.g. the most widespread open-source J2EE container.
>
> What does it help to be standards-compliant if e.g. my appserver ist
> much more picky about things than the test container? It turned out e.g.
> that JBoss doesn't like any calls to begin(), commit() or rollback() on
> a java.sql.Connection that has autoCommit set to true.
>
> How about this:
>
> * a JBoss server is started from within the JUnit testsuite (the
> JBoss installation would best be included in the test project) in
> a separate VM,
> * (the implementation is deployed in it using .rar and ds.xml)
> * the test methods invoke individual corresponding JSPs in the JBoss
> that try-catch Exception and either return a success HTML or the
> stacktrace of any occurred exception
>
>
> erik@jpox.org schrieb:
> Jencks),
> incorporate
> I
> and
> users?
>
>
> --
> ________________________________________
__________________
> Dipl.-Inf. Jörg von Frantzius | artnology GmbH
> | Milastr. 4
> Tel +49 (0)30 4435 099 26 | 10437 Berlin
> Fax +49 (0)30 4435 099 99 | http://www.artnology.com
> _______________________________|________
__________________
>
>
--
Karan Malhi
| |
| Jörg von Frantzius 2005-12-14, 5:45 pm |
| Karan Malhi schrieb:
> Hi Jorg,
>
> Getting an exception when in auto-commit mode should not be a JBoss specific
> thing.
That's true, but it turned out to be a problem for JPOX only recently
when using JBoss 4.0.3.
> Below is the description of the commit method from
> java.sql.Connection class:
>
> commit
>
> public void *commit*()
> throws SQLException
> <file:///c:/Documents%20and%20Settings/karan/My%20Documents/DOCS/j2sdk1.4.2/docs/api/java/sql/SQLException.html>
>
> *Throws:* SQLException<file:///c:/Documents%20and%20Settings/karan/My%20Documents/DOCS/j2sdk1.4.2/docs/api/java/sql/SQLException.html>-
> if a database access error occurs or this
> Connection object is in auto-commit mode
>
> On 12/14/05, Jörg von Frantzius <joerg.von.frantzius@artnology.com> wrote:
>
>
>
> --
> Karan Malhi
>
>
--
________________________________________
__________________
Dipl.-Inf. Jörg von Frantzius | artnology GmbH
| Milastr. 4
Tel +49 (0)30 4435 099 26 | 10437 Berlin
Fax +49 (0)30 4435 099 99 | http://www.artnology.com
_______________________________|________
__________________
| |
| Craig L Russell 2005-12-14, 5:45 pm |
| | |
| Jörg von Frantzius 2005-12-14, 5:45 pm |
| Craig L Russell schrieb:
> The TCK tests are designed to test the functionality of JDO in J2SE
> environments, as this is where the spec is focused. There are no spec
> requirements of a JDO implementation with regard to behavior inside a
> container (there is no contract that is required on either the
> container side or the JDO side).
The spec says in "2.3 Goals":
The JDO architecture uses the J2EE Connector Architecture to make it
applicable to all J2EE platform compliant application servers from
multiple vendors.
Maybe the provision of a JCA adapter is optional, but is it that only
mandatory requirements are tested in the TCK?
> Most JDO implementations use a non-standard way to configure the web
> environment (such as a non-Java Connector Architecture resource)
> mainly because the Java Connector Architecture resource requirements
> are overkill for most applications.
I'm not so sure about that. We're not talking about simple
Servlet-engines here, but application servers, which provide e.g. JMS.
In order to be able to transactionally send JMS messages and modify data
within the same transaction, integration in the JTA is a must, and most
of the times done via JCA, I think. In my experience, use of JCA is very
common when application servers are used.
> It's also not clear what the TCK test suite would actually do.
It should simply assure that retrieving and modifying data works within
the container. When I tried that with JPOX 1.1.0-beta-5 and JBoss 4.0.3
SP1, I was suprised to see lots of bugs, probably mostly because this is
not covered by any JUnit tests yet. There could e.g. these two varations
be tested to assure transaction enlisting works:
* first create a PM, then begin a UserTransaction, retrieve and
modify some data, commit the UserTransaction and verify the data
was written to DB (JPOX currently fails here for me)
* first begin a UserTransaction, then create a PM, retrieve and
modify some data, commit the UserTransaction and verify the data
was written to DB
There are some other scenarious involving EJBs to be found in 16.1.3 of
the PFD spec, just look for "How to test?" comments in that chapter ;-)
Maybe it is theoretically possible to have enlisting in JTA transactions
without using JCA, I don't know. That could be tested by deploying a
different configuration of the appserver (without .rar).
Testing advanced features like XA and 2PC would be really great, if not
only by providing an example of how to configure the reference
implementation for that... (does JPOX do XA and 2PC?)
>
> That said, I think it's worth a discussion if you have some ideas of
> the scope and environment of such tests.
Please see my other mail for an idea of how to include an appserver in
the tests (how feasible ever it is...)
>
> True, but the TCK will likely not be normative as to the configuration
> of the JDO implementation inside the specific container environment.
It could look for some .rar and accompanying *ds.xml file and deploy
them if found. If there are none, maybe the implementation has found a
way to plug into JTA.
> The TCK is not for end users, but rather for JDO implementations to
> help them make sure that they are compliant with the specification. I
> think the major value of the TCK for end users is to make sure that
> their vendor passes it.
Right. So at the moment as an end-user you can't really know whether
that implementation will do what you need it for, i.e. work inside an
appserver.
Best regards,
Jörg.
P.S.
How come you can send those nice HTML mails, mine were always rejected
by the mailserver?
>
> Best regards,
>
> Craig
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
--
________________________________________
__________________
Dipl.-Inf. Jörg von Frantzius | artnology GmbH
| Milastr. 4
Tel +49 (0)30 4435 099 26 | 10437 Berlin
Fax +49 (0)30 4435 099 99 | http://www.artnology.com
_______________________________|________
__________________
| |
| Craig L Russell 2005-12-21, 5:45 pm |
| |
|
|
|
|