dev@openejb.apache.org Archives http://mail-archives.apache.org/mod_mbox/openejb-dev/ 2009-12-10T04:29:21Z Re: openejb-client has OSGi Require-Bundle without a maven dependency. Jarek Gawor <jgawor@gmail.com> urn:uuid:%3c5eb405c70912082048v96554d2l7c099d3b3d2fe1c@mail-gmail-com%3e 2009-12-09T04:48:33Z 
Hi,

I also have been looking at some OSGi issues in OpenEJB and I think
that Require-Bundle will be needed either in openejb-core (requiring
openejb-client) or openejb-client (requiring openejb-core) bundle in
order to deal with the split package problem in
org.apache.openejb.client package. The best solution would be to get
rid off the split package problem but if that's not possible you might
have to use the Require-Bundle solution. I started a related
discussion on this topic on the Geronimo list:
http://www.mail-archive.com/dev@geronimo.apache.org/msg75387.html

Jarek

On Tue, Dec 1, 2009 at 4:58 PM, David Blevins <david.blevins@visi.com> wrote:
>
> On Nov 3, 2009, at 12:12 PM, David Blevins wrote:
>
>>
>> On Nov 3, 2009, at 7:27 AM, Rick McGuire wrote:
>>
>>> I ran into a little issue with the bundlized version of the
>>> openejb-client jar.  This jar has a Require-Bundle dependency on
>>> org.apache.openejb.openebj-core, but the project pom does not specify a
>>> maven dependency on openejb-core.  This is causing a bit of an issue when
>>> used in Geronimo 3.0 because the framework is using the maven dependencies
>>> to determine the install/start order for the different bundles we're using.
>>>  Since there's no maven dependency, the openejb-client is giving a
>>> resolution constraint failure on the required jar depending on the relative
>>> order the different openejb bundles get started.  Having the correct maven
>>> dependency in the pom would sort all of that out.
>>>
>>> Is there some reason why this was done this way, or is it just an
>>> oversight?
>>
>> I'm not sure why there is a Require-Bundle dep on openejb-core.  Maybe
>> someone else can comment on that.
>>
>> Code-wise, the client jar is designed to work without any other OpenEJB
>> libraries or third party dependencies (except for specs), so that explains
>> why there is not a maven dep.
>
> Still looking for some followup.  As mentioned the openejb-client module
> does not need and should not be allowed to use the code in openejb-core.
>  Going to remove that dependency.
>
> -David
>
>
Re: openejb-client has OSGi Require-Bundle without a maven dependency. Jacek Laskowski <jacek@laskowski.net.pl> urn:uuid:%3c1b5bfeb50912072308k19d985cagcee08a3305540112@mail-gmail-com%3e 2009-12-08T07:08:15Z 
On Tue, Dec 1, 2009 at 10:58 PM, David Blevins <david.blevins@visi.com> wrote:

> Still looking for some followup.  As mentioned the openejb-client module
> does not need and should not be allowed to use the code in openejb-core.
>  Going to remove that dependency.

Me, on the other hand, is going to take a look at why it's needed in
the first place. Dunno why I added it - perhaps it made the
classloaders easier to work with.

Jacek

-- 
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Re: Resolve datasource from the application name Jean-Louis MONTEIRO <jean-louis.monteiro@atosorigin.com> urn:uuid:%3c26679345-post@talk-nabble-com%3e 2009-12-07T15:59:05Z 

Great!
Sorry ...

Jean-Louis


Luis F. Planella Gonzalez wrote:
> 
> The patch is there. It's called dataSourceFromModules.patch 
> (https://issues.apache.org/jira/secure/attachment/12427172/dataSourceFromModules.patch).
> I've attached the complete files just to make easier for someone to
> quickly see 
> the entire files...
> --
> Luis Fernando Planella Gonzalez
> 
> 
> Em Segunda-feira 07 Dezembro 2009, às 13:47:52, Jean-Louis MONTEIRO
> escreveu:
>> Hi,
>> 
>> first of all, congrats for your baby ;-)
>> 
>> Can you please attach a patch file instead of the source file?
>> Then, I gonna be more than happy to have a look and commit it for you.
>> 
>> Jean-Louis
>> 
>> Luis F. Planella Gonzalez wrote:
>> > Sorry for reposting, but if what I just proposed is to be implemented,
>> > maybe
>> > the findMatchingDataSources(String) method could be inlined, as I used
>> a
>> > String[] as return to be able to return 2 values.
>> >
>> > I actually liked this way better than what I've patched. The code is
>> > simpler
>> > and easier to add new ids in the check.
>> >
>> > --
>> > Luis Fernando Planella Gonzalez
>> >
>> > Em Segunda-feira 07 Dezembro 2009, às 11:42:13, você escreveu:
>> >> Actually, I was off for 2 weeks. And yes, she's the first baby. Thanks
>> >> God
>> >>  she's very calm....
>> >>
>> >> Well, returning to the issue: Sorry, with hundreds of mails after
>> those
>> >> 2 weeks, I've actually seen your answer after I've attached the patch
>> to
>> >>
>> https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12426288
>> >>
>> >> Please, check the comment on the issue.
>> >>
>> >> The code is there needing a review, but I did implemented it several
>> >> ifs, but it could be replaced by something like:
>> >>
>> >> // Collect which data sources will be searched
>> >> List<String> ids = new ArrayList<String>();
>> >> ids.add(unit.getName());
>> >> for (WebModule webModule : app.getWebModules()) {
>> >>     ids.add(webModule.getId());
>> >>     ids.add(webModule.getContextRoot());
>> >> }
>> >> ids.add(app.getModuleId());
>> >> // Search for a matching data source
>> >> for(String id : ids) {
>> >>     dataSources = findMatchingDataSources(id);
>> >>     if (dataSources != null) {
>> >>         jtaDataSourceId = dataSources[0];
>> >>         nonJtaDataSourceId = dataSources[1];
>> >>         break;
>> >> }
>> >>
>> >> Also, I did added a PersistenceModule.getModuleId() case (with a
>> TODO),
>> >> so
>> >>  it will probably have to be removed.
>> >>
>> >> Anyway, the tests are covering all cases (except for
>> >> PersistenceModule.getModuleId()), and I think the issue is resolved...
>> >>
>> >> Please, let me know if anything changes...
>> >>
>> >> --
>> >> Luis Fernando Planella Gonzalez
>> 
> 
> 

-- 
View this message in context: http://old.nabble.com/Resolve-datasource-from-the-application-name-tp25684131p26679345.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Resolve datasource from the application name Luis Fernando Planella Gonzalez <lfpg.dev@gmail.com> urn:uuid:%3c200912071355-18947-lfpg-dev@gmail-com%3e 2009-12-07T15:55:18Z 
The patch is there. It's called dataSourceFromModules.patch 
(https://issues.apache.org/jira/secure/attachment/12427172/dataSourceFromModules.patch).
I've attached the complete files just to make easier for someone to quickly see 
the entire files...
--
Luis Fernando Planella Gonzalez


Em Segunda-feira 07 Dezembro 2009, às 13:47:52, Jean-Louis MONTEIRO escreveu:
> Hi,
> 
> first of all, congrats for your baby ;-)
> 
> Can you please attach a patch file instead of the source file?
> Then, I gonna be more than happy to have a look and commit it for you.
> 
> Jean-Louis
> 
> Luis F. Planella Gonzalez wrote:
> > Sorry for reposting, but if what I just proposed is to be implemented,
> > maybe
> > the findMatchingDataSources(String) method could be inlined, as I used a
> > String[] as return to be able to return 2 values.
> >
> > I actually liked this way better than what I've patched. The code is
> > simpler
> > and easier to add new ids in the check.
> >
> > --
> > Luis Fernando Planella Gonzalez
> >
> > Em Segunda-feira 07 Dezembro 2009, às 11:42:13, você escreveu:
> >> Actually, I was off for 2 weeks. And yes, she's the first baby. Thanks
> >> God
> >>  she's very calm....
> >>
> >> Well, returning to the issue: Sorry, with hundreds of mails after those
> >> 2 weeks, I've actually seen your answer after I've attached the patch to
> >> https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12426288
> >>
> >> Please, check the comment on the issue.
> >>
> >> The code is there needing a review, but I did implemented it several
> >> ifs, but it could be replaced by something like:
> >>
> >> // Collect which data sources will be searched
> >> List<String> ids = new ArrayList<String>();
> >> ids.add(unit.getName());
> >> for (WebModule webModule : app.getWebModules()) {
> >>     ids.add(webModule.getId());
> >>     ids.add(webModule.getContextRoot());
> >> }
> >> ids.add(app.getModuleId());
> >> // Search for a matching data source
> >> for(String id : ids) {
> >>     dataSources = findMatchingDataSources(id);
> >>     if (dataSources != null) {
> >>         jtaDataSourceId = dataSources[0];
> >>         nonJtaDataSourceId = dataSources[1];
> >>         break;
> >> }
> >>
> >> Also, I did added a PersistenceModule.getModuleId() case (with a TODO),
> >> so
> >>  it will probably have to be removed.
> >>
> >> Anyway, the tests are covering all cases (except for
> >> PersistenceModule.getModuleId()), and I think the issue is resolved...
> >>
> >> Please, let me know if anything changes...
> >>
> >> --
> >> Luis Fernando Planella Gonzalez
>
Re: Resolve datasource from the application name Jean-Louis MONTEIRO <jean-louis.monteiro@atosorigin.com> urn:uuid:%3c26679167-post@talk-nabble-com%3e 2009-12-07T15:47:52Z 

Hi,

first of all, congrats for your baby ;-)

Can you please attach a patch file instead of the source file?
Then, I gonna be more than happy to have a look and commit it for you.

Jean-Louis



Luis F. Planella Gonzalez wrote:
> 
> Sorry for reposting, but if what I just proposed is to be implemented,
> maybe 
> the findMatchingDataSources(String) method could be inlined, as I used a 
> String[] as return to be able to return 2 values.
> 
> I actually liked this way better than what I've patched. The code is
> simpler  
> and easier to add new ids in the check.
> 
> --
> Luis Fernando Planella Gonzalez
> 
> 
> Em Segunda-feira 07 Dezembro 2009, às 11:42:13, você escreveu:
>> Actually, I was off for 2 weeks. And yes, she's the first baby. Thanks
>> God
>>  she's very calm....
>> 
>> Well, returning to the issue: Sorry, with hundreds of mails after those 2
>> weeks, I've actually seen your answer after I've attached the patch to
>> https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12426288
>> 
>> Please, check the comment on the issue.
>> 
>> The code is there needing a review, but I did implemented it several ifs,
>>  but it could be replaced by something like:
>> 
>> // Collect which data sources will be searched
>> List<String> ids = new ArrayList<String>();
>> ids.add(unit.getName());
>> for (WebModule webModule : app.getWebModules()) {
>>     ids.add(webModule.getId());
>>     ids.add(webModule.getContextRoot());
>> }
>> ids.add(app.getModuleId());
>> // Search for a matching data source
>> for(String id : ids) {
>>     dataSources = findMatchingDataSources(id);
>>     if (dataSources != null) {
>>         jtaDataSourceId = dataSources[0];
>>         nonJtaDataSourceId = dataSources[1];
>>         break;
>> }
>> 
>> Also, I did added a PersistenceModule.getModuleId() case (with a TODO),
>> so
>>  it will probably have to be removed.
>> 
>> Anyway, the tests are covering all cases (except for
>> PersistenceModule.getModuleId()), and I think the issue is resolved...
>> 
>> Please, let me know if anything changes...
>> 
>> --
>> Luis Fernando Planella Gonzalez
> 
> 

-- 
View this message in context: http://old.nabble.com/Resolve-datasource-from-the-application-name-tp25684131p26679167.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Resolve datasource from the application name Luis Fernando Planella Gonzalez <lfpg.dev@gmail.com> urn:uuid:%3c200912071153-43302-lfpg-dev@gmail-com%3e 2009-12-07T13:53:43Z 
Sorry for reposting, but if what I just proposed is to be implemented, maybe 
the findMatchingDataSources(String) method could be inlined, as I used a 
String[] as return to be able to return 2 values.

I actually liked this way better than what I've patched. The code is simpler  
and easier to add new ids in the check.

--
Luis Fernando Planella Gonzalez


Em Segunda-feira 07 Dezembro 2009, às 11:42:13, você escreveu:
> Actually, I was off for 2 weeks. And yes, she's the first baby. Thanks God
>  she's very calm....
> 
> Well, returning to the issue: Sorry, with hundreds of mails after those 2
> weeks, I've actually seen your answer after I've attached the patch to
> https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12426288
> 
> Please, check the comment on the issue.
> 
> The code is there needing a review, but I did implemented it several ifs,
>  but it could be replaced by something like:
> 
> // Collect which data sources will be searched
> List<String> ids = new ArrayList<String>();
> ids.add(unit.getName());
> for (WebModule webModule : app.getWebModules()) {
>     ids.add(webModule.getId());
>     ids.add(webModule.getContextRoot());
> }
> ids.add(app.getModuleId());
> // Search for a matching data source
> for(String id : ids) {
>     dataSources = findMatchingDataSources(id);
>     if (dataSources != null) {
>         jtaDataSourceId = dataSources[0];
>         nonJtaDataSourceId = dataSources[1];
>         break;
> }
> 
> Also, I did added a PersistenceModule.getModuleId() case (with a TODO), so
>  it will probably have to be removed.
> 
> Anyway, the tests are covering all cases (except for
> PersistenceModule.getModuleId()), and I think the issue is resolved...
> 
> Please, let me know if anything changes...
> 
> --
> Luis Fernando Planella Gonzalez
Re: Resolve datasource from the application name Luis Fernando Planella Gonzalez <lfpg.dev@gmail.com> urn:uuid:%3c200912071142-14068-lfpg-dev@gmail-com%3e 2009-12-07T13:42:13Z 
Actually, I was off for 2 weeks. And yes, she's the first baby. Thanks God she's 
very calm....

Well, returning to the issue: Sorry, with hundreds of mails after those 2 
weeks, I've actually seen your answer after I've attached the patch to 
https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12426288

Please, check the comment on the issue.

The code is there needing a review, but I did implemented it several ifs, but 
it could be replaced by something like:

// Collect which data sources will be searched
List<String> ids = new ArrayList<String>();
ids.add(unit.getName());
for (WebModule webModule : app.getWebModules()) {
    ids.add(webModule.getId());
    ids.add(webModule.getContextRoot());
}
ids.add(app.getModuleId());
// Search for a matching data source
for(String id : ids) {
    dataSources = findMatchingDataSources(id);
    if (dataSources != null) {
        jtaDataSourceId = dataSources[0];
        nonJtaDataSourceId = dataSources[1];
        break;
}

Also, I did added a PersistenceModule.getModuleId() case (with a TODO), so it 
will probably have to be removed. 

Anyway, the tests are covering all cases (except for 
PersistenceModule.getModuleId()), and I think the issue is resolved...

Please, let me know if anything changes...

--
Luis Fernando Planella Gonzalez


Em Sexta-feira 20 Novembro 2009, às 19:57:55, David Blevins escreveu:
> On Nov 19, 2009, at 3:46 AM, Luis Fernando Planella Gonzalez wrote:
> > I'd love to keep helping on this issue...
> > However I have an imminent issue: My daughter will be born on
> > saturday, so
> > I'll be off for a week or so.
> > Afterwards, we can resume the subject.
> 
> Wow!  Congratulations!  A week or so?  Guessing this is not your first
> kid, you sound like a pro!
> 
> > Anyway, that algorithm should be used only when neither
> > jtaDataSource nor
> > nonJtaDataSource are used, right? At least for what I saw in code,
> > it's
> > possible to have only nonJtaDataSource (making a new jta datasource
> > to be
> > deployed).
> 
> Yeah, I'm not sure.  I'd have to take a look at our current
> "fanciness" and see what makes the most sense.  We'd want this sort of
> "matching loop" to work for resolving any resource ID, so that might
> change how we code it.
> 
> > So, my guess would be to make the chunk of code I added to deploy(app,
> > persistenceModule) a private method, let's say,
> > locateDataSource(id), which
> > would look for a jta data source with that name, then a non-jta,
> > then an
> > unespecified.
> >
> > So, could it be something like:
> > * if explicit datasources are used, use them
> > * if neither jta-data-source nor non-jta-data-source, try to guess:
> > *** try locateDataSource(persitenceUnit.getName())
> > *** if not found, try
> > locateDataSource(persistenceModule.getModuleId()) // Is
> > it really necessary? As I saw, PersistenceModule.getModuleId() is
> > always null
> > *** if not found, for each WebModule try
> > locateDataSource(webModule.getContextRoot())
> 
> Wasn't referring to the PersistenceModule.getModuleId(), but the
> module in which the persistence unit was found.  *Most* the time the
> persistence.xml is inside an ejb jar or webapp.  We don't retain that
> information when we create the PersistenceModule now, but we could
> maybe link it to the EjbModule or WebModule if it was.  But we can add
> that as a separate step.
> 
> Definitely we would want this as some sort of loop of strings to check
> rather than as a bunch of nested if statements.  Then the same logical
> routine could work for resolving any resource ref.  For a plain
> resource ref the list of strings might be something like this:
> 
>    1. mappedName
>    2. jndi name
>    3. variable name
>    4. module name
>    5. app name
> 
> Thinking out loud of course, the code might disagree with me :)  Some
> ideas sound really good and then turn out to be too much work given
> the code.
> 
> 
> -David
>
Build failure in OpenEJB3 "Sajith H Kariyawasam" <sajhak@hotmail.com> urn:uuid:%3cBAY121-W52AE98498FEEBB2C4676B0D5950@phx-gbl%3e 2009-12-02T19:07:46Z 







Hi all, 

I tried to download OpenEJB code and build, But got the following build failure when i tried
to execute 

     mvn -o -Dmaven.{test,itest}.skip -Dassemble clean install 

from Ubuntu.

Could you please help me to figure this out ? 

Thanks 
Regards
shk

[WARNING] Warning in manifest for org.apache.openejb:openejb-core:jar:3.1.3-SNAPSHOT : Did
not find matching referal for org.quartz.*
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
     [java] Could not find org.apache.openejb.util.MakeTxLookup. Make sure you have it in
your classpath
     [java]     at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:170)
     [java]     at org.apache.tools.ant.taskdefs.Java.run(Java.java:710)
     [java]     at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:178)
     [java]     at org.apache.tools.ant.taskdefs.Java.execute(Java.java:84)
     [java]     at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
     [java]     at org.apache.tools.ant.Task.perform(Task.java:364)
     [java]     at org.apache.tools.ant.Target.execute(Target.java:341)
     [java]     at org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:108)
     [java]     at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:83)
     [java]     at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
     [java]     at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
     [java]     at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
     [java]     at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
     [java]     at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
     [java]     at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
     [java]     at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
     [java]     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
     [java]     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
     [java]     at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
     [java]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     [java]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     [java]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     [java]     at java.lang.reflect.Method.invoke(Method.java:597)
     [java]     at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
     [java]     at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
     [java]     at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
     [java]     at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

 		 	   		  
 		 	   		  
_________________________________________________________________
Keep your friends updated—even when you’re not signed in.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010
Re: InitialContext / Comms protocol recovery from a SystemException David Blevins <david.blevins@visi.com> urn:uuid:%3c70781C23-47A8-4D08-A2A4-A6CFB1445C1D@visi-com%3e 2009-12-01T22:21:22Z 
Missed this followup.

On Nov 4, 2009, at 4:00 AM, Quintin Beukes wrote:

> Though, isn't there a way if a 3rd party SecurityService fails for  
> some
> reason for OpenEJB to recover from it?

I'm not sure of the nature of the failure.  If the SecurityService  
throws an exception each time we call isCallerAuthorized() then there  
is no way for let the call through.  Do you know if that is the case  
or are subsequent calls to the SecurityService succeeding but failures  
still occurring downstream?

And just for good measure, what is the "your fault" part?  If there's  
something we can do to check for bad input or user error, we should do  
it.

-David

> On Tue, Nov 3, 2009 at 11:12 PM, David Blevins  
> <david.blevins@visi.com>wrote:
>
>> Haven't seen this before, looks like the null is coming from the
>> GeronimoSecurityService.
>>
>> We test system and application exceptions in the itests for each  
>> bean type
>> on both the remote and local servers as well as on Tomcat.  We  
>> don't run
>> those on Geronimo though, which we really should. There was some  
>> code in
>> Geronimo to do that at one point, but it got axed as being too hard  
>> to
>> maintain quite a while ago.  I think we should bring it back.
>>
>> I'm not sure what it might take Geronimo plan-wise, but here's the  
>> app:
>>
>>
>> http://repo2.maven.org/maven2/org/apache/openejb/openejb-itests-beans/3.1.2/openejb-itests-beans-3.1.2.jar
>>
>> And the client which includes all deps and is an executable jar:
>>
>>
>> http://repo2.maven.org/maven2/org/apache/openejb/openejb-itests-standalone-client/3.1.2/openejb-itests-standalone-client-3.1.2.jar
>>
>> -David
>>
>>
>> On Nov 2, 2009, at 10:44 AM, Quintin Beukes wrote:
>>
>> Hey,
>>>
>>> When I get a SystemException from the container during remote EJB
>>> invocation, all future requests for the InitialContext are  
>>> "broken". My
>>> exact situation (reason for causing the SystemException) is on my  
>>> fault,
>>> but
>>> if there is another reason I think it's good to recover from it so  
>>> to be
>>> able to continue serving requests. I got the following by invoking  
>>> on a
>>> method which isn't in the remote EJB class/Remote interface.
>>>
>>> This is what I got:
>>> ------- SNIP -------
>>> 02 Nov 2009 20:28:33,649 ERROR -- Exception: Error deleting  
>>> employee:
>>> XXXXXX
>>> (javax.ejb.EJBException)
>>> javax.ejb.EJBException: Container has suffered a SystemException
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:178)
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client 
>>> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>>  $Proxy7.deletePerson(Unknown Source)
>>>
>>>
>>> net 
>>> .kunye 
>>> .personnel 
>>> .client 
>>> .employees 
>>> .delete 
>>> .DeleteEmployeeWizardAction 
>>> .performAction(DeleteEmployeeWizardAction.java:87)
>>>
>>>
>>> net 
>>> .kunye 
>>> .personnel 
>>> .client 
>>> .employees 
>>> .delete 
>>> .DeleteEmployeeWizardAction 
>>> .performAction(DeleteEmployeeWizardAction.java:55)
>>>
>>>
>>> org.openide.util.actions.NodeAction$DelegateAction 
>>> $1.run(NodeAction.java:589)
>>>
>>>
>>> org 
>>> .netbeans 
>>> .modules 
>>> .openide.util.ActionsBridge.doPerformAction(ActionsBridge.java:77)
>>>
>>>
>>> org.openide.util.actions.NodeAction 
>>> $DelegateAction.actionPerformed(NodeAction.java:585)
>>>   
>>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java: 
>>> 1995)
>>>
>>>
>>> javax.swing.AbstractButton 
>>> $Handler.actionPerformed(AbstractButton.java:2318)
>>>
>>>
>>> javax 
>>> .swing 
>>> .DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
>>>  javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java: 
>>> 242)
>>>  javax.swing.AbstractButton.doClick(AbstractButton.java:357)
>>>
>>> javax 
>>> .swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1220)
>>>
>>>
>>> javax.swing.plaf.basic.BasicMenuItemUI 
>>> $Handler.mouseReleased(BasicMenuItemUI.java:1261)
>>>  java.awt.Component.processMouseEvent(Component.java:6041)
>>>  javax.swing.JComponent.processMouseEvent(JComponent.java:3265)
>>>  java.awt.Component.processEvent(Component.java:5806)
>>>  java.awt.Container.processEvent(Container.java:2058)
>>>  java.awt.Component.dispatchEventImpl(Component.java:4413)
>>>  java.awt.Container.dispatchEventImpl(Container.java:2116)
>>>  java.awt.Component.dispatchEvent(Component.java:4243)
>>>  java.awt.LightweightDispatcher.retargetMouseEvent(Container.java: 
>>> 4322)
>>>  java.awt.LightweightDispatcher.processMouseEvent(Container.java: 
>>> 3986)
>>>  java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916)
>>>  java.awt.Container.dispatchEventImpl(Container.java:2102)
>>>  java.awt.Window.dispatchEventImpl(Window.java:2440)
>>>  java.awt.Component.dispatchEvent(Component.java:4243)
>>>  java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
>>>
>>>
>>> org 
>>> .netbeans 
>>> .core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:104)
>>>
>>>
>>> java 
>>> .awt 
>>> .EventDispatchThread 
>>> .pumpOneEventForFilters(EventDispatchThread.java:273)
>>>
>>>
>>> java 
>>> .awt 
>>> .EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java: 
>>> 183)
>>>
>>>
>>> java 
>>> .awt 
>>> .EventDispatchThread 
>>> .pumpEventsForHierarchy(EventDispatchThread.java:173)
>>>  java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java: 
>>> 168)
>>>  java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java: 
>>> 160)
>>>  java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
>>>
>>> java.rmi.RemoteException: The server has encountered a fatal error:
>>> Unknown
>>> error in container java.lang.NullPointerException; nested  
>>> exception is:
>>> java.lang.NullPointerException
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .server 
>>> .ejbd.EjbRequestHandler.replyWithFatalError(EjbRequestHandler.java: 
>>> 425)
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .server 
>>> .ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:205)
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
>>>  org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java: 
>>> 149)
>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
>>>
>>>
>>> org.apache.openejb.server.ejbd.KeepAliveServer 
>>> $Session.service(KeepAliveServer.java:213)
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java: 
>>> 233)
>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
>>>  org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>>>  org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>>>
>>>
>>> java.util.concurrent.ThreadPoolExecutor 
>>> $Worker.runTask(ThreadPoolExecutor.java:886)
>>>
>>>
>>> java.util.concurrent.ThreadPoolExecutor 
>>> $Worker.run(ThreadPoolExecutor.java:908)
>>>  java.lang.Thread.run(Thread.java:619)
>>>
>>> java.lang.NullPointerException: null
>>>
>>>
>>> org 
>>> .apache 
>>> .geronimo 
>>> .openejb 
>>> .GeronimoSecurityService 
>>> .isCallerAuthorized(GeronimoSecurityService.java:96)
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .core.stateless.StatelessContainer.invoke(StatelessContainer.java: 
>>> 151)
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .core.stateless.StatelessContainer.invoke(StatelessContainer.java: 
>>> 136)
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .server 
>>> .ejbd 
>>> .EjbRequestHandler 
>>> .doEjbObject_BUSINESS_METHOD(EjbRequestHandler.java:238)
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .server 
>>> .ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:129)
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
>>>  org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java: 
>>> 149)
>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
>>>
>>>
>>> org.apache.openejb.server.ejbd.KeepAliveServer 
>>> $Session.service(KeepAliveServer.java:213)
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java: 
>>> 233)
>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
>>>  org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>>>  org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>>>
>>>
>>> java.util.concurrent.ThreadPoolExecutor 
>>> $Worker.runTask(ThreadPoolExecutor.java:886)
>>>
>>>
>>> java.util.concurrent.ThreadPoolExecutor 
>>> $Worker.run(ThreadPoolExecutor.java:908)
>>>  java.lang.Thread.run(Thread.java:619)
>>>
>>> ------- SNIP -------
>>>
>>> There after, when I try to invoke OTHER methods, I get this:
>>>
>>>
>>>
>>> 02 Nov 2009 20:29:45,990 ERROR -- Exception: Error creating new  
>>> employee:
>>> XXXXXX (javax.ejb.EJBException)
>>> javax.ejb.EJBException: Unknown Container Exception:
>>> java.rmi.RemoteException: Received invalid response code from  
>>> server: -1
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:184)
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client 
>>> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>>  $Proxy7.registerPerson(Unknown Source)
>>>
>>>
>>> net 
>>> .kunye 
>>> .personnel 
>>> .client 
>>> .employees 
>>> .add 
>>> .AddEmployeeWizardAction 
>>> .performAction(AddEmployeeWizardAction.java:69)
>>>
>>>
>>> net 
>>> .kunye 
>>> .personnel 
>>> .client 
>>> .employees 
>>> .add 
>>> .AddEmployeeWizardAction.openWizard(AddEmployeeWizardAction.java:47)
>>>
>>>
>>> net 
>>> .kunye 
>>> .personnel 
>>> .client 
>>> .navigation 
>>> .NavigationRootTopComponent 
>>> .btnAddEmployeeActionPerformed(NavigationRootTopComponent.java:107)
>>>
>>>
>>> net 
>>> .kunye 
>>> .personnel.client.navigation.NavigationRootTopComponent.access 
>>> $000(NavigationRootTopComponent.java:36)
>>>
>>>
>>> net.kunye.personnel.client.navigation.NavigationRootTopComponent 
>>> $1.actionPerformed(NavigationRootTopComponent.java:67)
>>>   
>>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java: 
>>> 1995)
>>>
>>>
>>> javax.swing.AbstractButton 
>>> $Handler.actionPerformed(AbstractButton.java:2318)
>>>
>>>
>>> javax 
>>> .swing 
>>> .DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
>>>  javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java: 
>>> 242)
>>>
>>>
>>> javax 
>>> .swing 
>>> .plaf 
>>> .basic.BasicButtonListener.mouseReleased(BasicButtonListener.java: 
>>> 236)
>>>  java.awt.Component.processMouseEvent(Component.java:6041)
>>>  javax.swing.JComponent.processMouseEvent(JComponent.java:3265)
>>>  java.awt.Component.processEvent(Component.java:5806)
>>>  java.awt.Container.processEvent(Container.java:2058)
>>>  java.awt.Component.dispatchEventImpl(Component.java:4413)
>>>  java.awt.Container.dispatchEventImpl(Container.java:2116)
>>>  java.awt.Component.dispatchEvent(Component.java:4243)
>>>  java.awt.LightweightDispatcher.retargetMouseEvent(Container.java: 
>>> 4322)
>>>  java.awt.LightweightDispatcher.processMouseEvent(Container.java: 
>>> 3986)
>>>  java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916)
>>>  java.awt.Container.dispatchEventImpl(Container.java:2102)
>>>  java.awt.Window.dispatchEventImpl(Window.java:2440)
>>>  java.awt.Component.dispatchEvent(Component.java:4243)
>>>  java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
>>>
>>>
>>> org 
>>> .netbeans 
>>> .core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:104)
>>>
>>>
>>> java 
>>> .awt 
>>> .EventDispatchThread 
>>> .pumpOneEventForFilters(EventDispatchThread.java:273)
>>>
>>>
>>> java 
>>> .awt 
>>> .EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java: 
>>> 183)
>>>
>>>
>>> java 
>>> .awt 
>>> .EventDispatchThread 
>>> .pumpEventsForHierarchy(EventDispatchThread.java:173)
>>>  java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java: 
>>> 168)
>>>  java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java: 
>>> 160)
>>>  java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
>>>
>>> java.rmi.RemoteException: Received invalid response code from  
>>> server: -1
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client.EJBObjectHandler.businessMethod(EJBObjectHandler.java:239)
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:157)
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client 
>>> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>>  $Proxy7.registerPerson(Unknown Source)
>>>
>>>
>>> net 
>>> .kunye 
>>> .personnel 
>>> .client 
>>> .employees 
>>> .add 
>>> .AddEmployeeWizardAction 
>>> .performAction(AddEmployeeWizardAction.java:69)
>>>
>>>
>>> net 
>>> .kunye 
>>> .personnel 
>>> .client 
>>> .employees 
>>> .add 
>>> .AddEmployeeWizardAction.openWizard(AddEmployeeWizardAction.java:47)
>>>
>>>
>>> net 
>>> .kunye 
>>> .personnel 
>>> .client 
>>> .navigation 
>>> .NavigationRootTopComponent 
>>> .btnAddEmployeeActionPerformed(NavigationRootTopComponent.java:107)
>>>
>>>
>>> net 
>>> .kunye 
>>> .personnel.client.navigation.NavigationRootTopComponent.access 
>>> $000(NavigationRootTopComponent.java:36)
>>>
>>>
>>> net.kunye.personnel.client.navigation.NavigationRootTopComponent 
>>> $1.actionPerformed(NavigationRootTopComponent.java:67)
>>>   
>>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java: 
>>> 1995)
>>>
>>>
>>> javax.swing.AbstractButton 
>>> $Handler.actionPerformed(AbstractButton.java:2318)
>>>
>>>
>>> javax 
>>> .swing 
>>> .DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
>>>  javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java: 
>>> 242)
>>>
>>>
>>> javax 
>>> .swing 
>>> .plaf 
>>> .basic.BasicButtonListener.mouseReleased(BasicButtonListener.java: 
>>> 236)
>>>  java.awt.Component.processMouseEvent(Component.java:6041)
>>>  javax.swing.JComponent.processMouseEvent(JComponent.java:3265)
>>>  java.awt.Component.processEvent(Component.java:5806)
>>>  java.awt.Container.processEvent(Container.java:2058)
>>>  java.awt.Component.dispatchEventImpl(Component.java:4413)
>>>  java.awt.Container.dispatchEventImpl(Container.java:2116)
>>>  java.awt.Component.dispatchEvent(Component.java:4243)
>>>  java.awt.LightweightDispatcher.retargetMouseEvent(Container.java: 
>>> 4322)
>>>  java.awt.LightweightDispatcher.processMouseEvent(Container.java: 
>>> 3986)
>>>  java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916)
>>>  java.awt.Container.dispatchEventImpl(Container.java:2102)
>>>  java.awt.Window.dispatchEventImpl(Window.java:2440)
>>>  java.awt.Component.dispatchEvent(Component.java:4243)
>>>  java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
>>>
>>>
>>> org 
>>> .netbeans 
>>> .core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:104)
>>>
>>>
>>> java 
>>> .awt 
>>> .EventDispatchThread 
>>> .pumpOneEventForFilters(EventDispatchThread.java:273)
>>>
>>>
>>> java 
>>> .awt 
>>> .EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java: 
>>> 183)
>>>
>>>
>>> java 
>>> .awt 
>>> .EventDispatchThread 
>>> .pumpEventsForHierarchy(EventDispatchThread.java:173)
>>>  java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java: 
>>> 168)
>>>  java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java: 
>>> 160)
>>>  java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
>>>
>>> Quintin Beukes
>>>
>>
>>
Re: Connection Recovery David Blevins <david.blevins@visi.com> urn:uuid:%3c178008F4-E628-4385-A380-BEF84664E2A0@visi-com%3e 2009-12-01T22:13:30Z 

On Nov 24, 2009, at 12:48 AM, Quintin Beukes wrote:

> :> Original problem. I'm just trying to understand why it would take
> so long even after newly started apps are working fine.

Not sure how long your app takes to undeploy and then fully deploy  
again.  The delay shouldn't be any longer than that.  If there is more  
delay beyond that, I'm not sure what would cause it.

If you want to dig in, the first thing I'd check is to see if the  
client is waiting to read or waiting to write, or exactly what the  
client is doing in this time.

-David

> The "cross over server" sounds like a very good idea, though I would
> still like to know how this works.
>
> Quintin Beukes
>
>
>
> On Tue, Nov 24, 2009 at 10:36 AM, David Blevins <david.blevins@visi.com 
> > wrote:
>>
>> On Nov 24, 2009, at 12:14 AM, Quintin Beukes wrote:
>>
>>> But the problem is that after I redeployed the requests fail for  
>>> up to
>>> 6 minutes there after if the app was running prior even while newly
>>> booted clients are working fine? So I would do this:
>>>
>>> 1. Run clientA
>>> 2. Undeploy, deploy app - deploy completed successfully
>>> 3. ClientA fails
>>> 4. Run ClientB
>>> 5. ClientB succeeds
>>> 6. ClientA fails stills
>>> 7. 5-6 minutes later clientA starts succeeding.
>>>
>>> Why is this? After the 5 minute period, what triggers the recovery  
>>> to
>>> start?
>>
>> Just so I make sure I'm on the same page, the above is a recap of the
>> original problem?  Or are you now seeing 5-6 minute delays in the  
>> failover
>> logic from one server to the next?
>>
>> -David
>>
>>> On Mon, Nov 23, 2009 at 10:32 PM, David Blevins <david.blevins@visi.com 
>>> >
>>> wrote:
>>>>
>>>> This is because there is no concept of blocking connections for
>>>> applications
>>>> that are being redeployed.  In fact our (geronimo and openejb)  
>>>> redeploy
>>>> is
>>>> just an undeploy followed by a deploy, so there's no special  
>>>> concept
>>>> propagated throughout the architecture that something is only  
>>>> temporarily
>>>> gone and will be coming back.
>>>>
>>>> That said, if we added all that, you'd still have to wait the  
>>>> exact same
>>>> amount of time for the undeploy/deploy process plus a small shave  
>>>> off of
>>>> total throughput for the synchronization we'd have to add to make  
>>>> the
>>>> wait-for-redeploy logic work.  The bigger your app gets, the  
>>>> longer the
>>>> time
>>>> your client spends waiting, which is probably going to drive you to
>>>> splinter
>>>> your app into tiny fragments which only complicates things more  
>>>> and adds
>>>> even more overhead.
>>>>
>>>> This is one of those "change the problem" types of situations.   
>>>> Instead
>>>> enable multicast discovery on your server and just let it run.   
>>>> When you
>>>> want to "redeploy", just boot a new server with the new version  
>>>> of the
>>>> app.
>>>>  When you get that server running to your liking -- almost  
>>>> everyone has
>>>> some
>>>> sort of initialization they like to do in their apps -- just shut  
>>>> down
>>>> the
>>>> first server and the client will immediately roll over to the  
>>>> second
>>>> server.
>>>>  No time spent waiting on redeploy and you actually get a chance  
>>>> to pound
>>>> on
>>>> your new server a bit before it goes live, so no more risk that  
>>>> the app
>>>> doesn't quite work after the redeploy.
>>>>
>>>> You can do this all on the same machine with a shell script or  
>>>> ant script
>>>> that is only slightly fancier than your standard start, deploy,  
>>>> run type
>>>> of
>>>> script.
>>>>
>>>> -David
>>>>
>>>> On Nov 23, 2009, at 6:20 AM, Quintin Beukes wrote:
>>>>
>>>>> Hey,
>>>>>
>>>>> One of the big motivations for shifting to OpenEJB 3.1.2 from GF  
>>>>> was
>>>>> the connection recovery built into it. My inquiry was specifically
>>>>> about failed remote EJB connections because a server restarts or a
>>>>> network hiccup. We've always had problems with this, especially  
>>>>> with
>>>>> networks running from surface to underground.
>>>>>
>>>>> This seems to be working. Great job!! Thanks alot. I'm aiming for
>>>>> complete recovery in the following situations.
>>>>> 1. System exception (any failure on the part of OpenEJB, even if  
>>>>> the
>>>>> cause was my own)
>>>>> 2. Dropped connections due to network
>>>>> 3. Dropped connections from server restart
>>>>> 4. Dropped connections from redeploy (basically the same as (3) I
>>>>> assume).
>>>>>
>>>>> Though I have a query though. Every time I redeploy, for ex, I  
>>>>> have to
>>>>> manually go and restart all services because it takes very long  
>>>>> for
>>>>> OpenEJB client to notice something is wrong and recover.
>>>>>
>>>>> Here is an example: If I undeploy, I get something like the  
>>>>> following
>>>>> on a client.
>>>>>
>>>>> --------- SNIP -----------
>>>>>
>>>>> javax.ejb.EJBException: Container has suffered a SystemException
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java: 
>>>>> 178)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .client 
>>>>> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java: 
>>>>> 52)
>>>>>  $Proxy2.captureLamp(Unknown Source)
>>>>>
>>>>>
>>>>> net 
>>>>> .kunye 
>>>>> .vds 
>>>>> .server 
>>>>> .services 
>>>>> .configuration 
>>>>> .ConfigurationService.service(ConfigurationService.java:73)
>>>>>   
>>>>> net 
>>>>> .kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>>>>
>>>>> java.rmi.RemoteException: The server has encountered a fatal  
>>>>> error: No
>>>>> such deployment java.rmi.RemoteException: No deployment:
>>>>> VDS-lamps-ejb-3.0.jar/LampCaptureBean; nested exception is:
>>>>>       java.rmi.RemoteException: No deployment:
>>>>> VDS-lamps-ejb-3.0.jar/LampCaptureBean
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .server 
>>>>> .ejbd 
>>>>> .EjbRequestHandler.replyWithFatalError(EjbRequestHandler.java:425)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .server 
>>>>> .ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:81)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java: 
>>>>> 196)
>>>>>  org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java: 
>>>>> 149)
>>>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java: 
>>>>> 71)
>>>>>
>>>>>
>>>>> org.apache.openejb.server.ejbd.KeepAliveServer 
>>>>> $Session.service(KeepAliveServer.java:213)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
>>>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java: 
>>>>> 66)
>>>>>  org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>>>>>  org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>>>>>
>>>>>
>>>>> java.util.concurrent.ThreadPoolExecutor 
>>>>> $Worker.runTask(ThreadPoolExecutor.java:886)
>>>>>
>>>>>
>>>>> java.util.concurrent.ThreadPoolExecutor 
>>>>> $Worker.run(ThreadPoolExecutor.java:908)
>>>>>  java.lang.Thread.run(Thread.java:619)
>>>>>
>>>>> java.rmi.RemoteException: No deployment:
>>>>> VDS-lamps-ejb-3.0.jar/LampCaptureBean
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb.server.ejbd.EjbDaemon.getDeployment(EjbDaemon.java:191)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .server 
>>>>> .ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:79)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java: 
>>>>> 196)
>>>>>  org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java: 
>>>>> 149)
>>>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java: 
>>>>> 71)
>>>>>
>>>>>
>>>>> org.apache.openejb.server.ejbd.KeepAliveServer 
>>>>> $Session.service(KeepAliveServer.java:213)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
>>>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java: 
>>>>> 66)
>>>>>  org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>>>>>  org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>>>>>
>>>>>
>>>>> java.util.concurrent.ThreadPoolExecutor 
>>>>> $Worker.runTask(ThreadPoolExecutor.java:886)
>>>>>
>>>>>
>>>>> java.util.concurrent.ThreadPoolExecutor 
>>>>> $Worker.run(ThreadPoolExecutor.java:908)
>>>>>  java.lang.Thread.run(Thread.java:619)
>>>>>
>>>>>
>>>>> 23 Nov 2009 15:59:20,039 ERROR -- Exception: Service
>>>>> ConfigurationService failed for instance
>>>>> ConfigurationService[/10.0.0.25] (java.lang.Exception)
>>>>> java.lang.Exception: ConfigurationService has an unknown failure  
>>>>> while
>>>>> servicing a request.
>>>>>
>>>>>
>>>>> net 
>>>>> .kunye 
>>>>> .vds 
>>>>> .server 
>>>>> .services 
>>>>> .configuration 
>>>>> .ConfigurationService.service(ConfigurationService.java:84)
>>>>>   
>>>>> net 
>>>>> .kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>>>>
>>>>> javax.ejb.EJBException: Container has suffered a SystemException
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java: 
>>>>> 178)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .client 
>>>>> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java: 
>>>>> 52)
>>>>>  $Proxy2.captureLamp(Unknown Source)
>>>>>
>>>>>
>>>>> net 
>>>>> .kunye 
>>>>> .vds 
>>>>> .server 
>>>>> .services 
>>>>> .configuration 
>>>>> .ConfigurationService.service(ConfigurationService.java:73)
>>>>>   
>>>>> net 
>>>>> .kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>>>>
>>>>> java.rmi.RemoteException: The server has encountered a fatal  
>>>>> error: No
>>>>> such deployment java.rmi.RemoteException: No deployment:
>>>>> VDS-lamps-ejb-3.0.jar/LampCaptureBean; nested exception is:
>>>>>       java.rmi.RemoteException: No deployment:
>>>>> VDS-lamps-ejb-3.0.jar/LampCaptureBean
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .server 
>>>>> .ejbd 
>>>>> .EjbRequestHandler.replyWithFatalError(EjbRequestHandler.java:425)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .server 
>>>>> .ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:81)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java: 
>>>>> 196)
>>>>>  org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java: 
>>>>> 149)
>>>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java: 
>>>>> 71)
>>>>>
>>>>>
>>>>> org.apache.openejb.server.ejbd.KeepAliveServer 
>>>>> $Session.service(KeepAliveServer.java:213)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
>>>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java: 
>>>>> 66)
>>>>>  org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>>>>>  org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>>>>>
>>>>>
>>>>> java.util.concurrent.ThreadPoolExecutor 
>>>>> $Worker.runTask(ThreadPoolExecutor.java:886)
>>>>>
>>>>>
>>>>> java.util.concurrent.ThreadPoolExecutor 
>>>>> $Worker.run(ThreadPoolExecutor.java:908)
>>>>>  java.lang.Thread.run(Thread.java:619)
>>>>>
>>>>> java.rmi.RemoteException: No deployment:
>>>>> VDS-lamps-ejb-3.0.jar/LampCaptureBean
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb.server.ejbd.EjbDaemon.getDeployment(EjbDaemon.java:191)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .server 
>>>>> .ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:79)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java: 
>>>>> 196)
>>>>>  org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java: 
>>>>> 149)
>>>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java: 
>>>>> 71)
>>>>>
>>>>>
>>>>> org.apache.openejb.server.ejbd.KeepAliveServer 
>>>>> $Session.service(KeepAliveServer.java:213)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
>>>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java: 
>>>>> 66)
>>>>>  org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>>>>>  org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>>>>>
>>>>>
>>>>> java.util.concurrent.ThreadPoolExecutor 
>>>>> $Worker.runTask(ThreadPoolExecutor.java:886)
>>>>>
>>>>>
>>>>> java.util.concurrent.ThreadPoolExecutor 
>>>>> $Worker.run(ThreadPoolExecutor.java:908)
>>>>>  java.lang.Thread.run(Thread.java:619)
>>>>>
>>>>> --------- SNIP -----------
>>>>>
>>>>> Then, for a while, even after the EJB service started up  
>>>>> completely
>>>>> and even though I'm creating new InitialContext instances I get  
>>>>> the
>>>>> following. This isn't too bad, though it does take a few minutes
>>>>> (between 3 and 5) to recover.
>>>>>
>>>>> --------- SNIP -----------
>>>>>
>>>>> 23 Nov 2009 16:00:24,802 TRACE -- Received packet
>>>>> [R0010088220000000000000000]
>>>>> 23 Nov 2009 16:00:24,804 ERROR -- Exception: Unknown failure  
>>>>> servicing
>>>>> the request (javax.ejb.EJBException)
>>>>> javax.ejb.EJBException: Unknown Container Exception:
>>>>> java.rmi.RemoteException: Received invalid response code from  
>>>>> server:
>>>>> -1
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java: 
>>>>> 184)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .client 
>>>>> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java: 
>>>>> 52)
>>>>>  $Proxy2.captureLamp(Unknown Source)
>>>>>
>>>>>
>>>>> net 
>>>>> .kunye 
>>>>> .vds 
>>>>> .server 
>>>>> .services 
>>>>> .configuration 
>>>>> .ConfigurationService.service(ConfigurationService.java:73)
>>>>>   
>>>>> net 
>>>>> .kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>>>>
>>>>> java.rmi.RemoteException: Received invalid response code from  
>>>>> server: -1
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .client.EJBObjectHandler.businessMethod(EJBObjectHandler.java:239)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java: 
>>>>> 157)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .client 
>>>>> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java: 
>>>>> 52)
>>>>>  $Proxy2.captureLamp(Unknown Source)
>>>>>
>>>>>
>>>>> net 
>>>>> .kunye 
>>>>> .vds 
>>>>> .server 
>>>>> .services 
>>>>> .configuration 
>>>>> .ConfigurationService.service(ConfigurationService.java:73)
>>>>>   
>>>>> net 
>>>>> .kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>>>>
>>>>>
>>>>> 23 Nov 2009 16:00:24,804 ERROR -- Exception: Service
>>>>> ConfigurationService failed for instance
>>>>> ConfigurationService[/10.0.0.25] (java.lang.Exception)
>>>>> java.lang.Exception: ConfigurationService has an unknown failure  
>>>>> while
>>>>> servicing a request.
>>>>>
>>>>>
>>>>> net 
>>>>> .kunye 
>>>>> .vds 
>>>>> .server 
>>>>> .services 
>>>>> .configuration 
>>>>> .ConfigurationService.service(ConfigurationService.java:84)
>>>>>   
>>>>> net 
>>>>> .kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>>>>
>>>>> javax.ejb.EJBException: Unknown Container Exception:
>>>>> java.rmi.RemoteException: Received invalid response code from  
>>>>> server:
>>>>> -1
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java: 
>>>>> 184)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .client 
>>>>> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java: 
>>>>> 52)
>>>>>  $Proxy2.captureLamp(Unknown Source)
>>>>>
>>>>>
>>>>> net 
>>>>> .kunye 
>>>>> .vds 
>>>>> .server 
>>>>> .services 
>>>>> .configuration 
>>>>> .ConfigurationService.service(ConfigurationService.java:73)
>>>>>   
>>>>> net 
>>>>> .kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>>>>
>>>>> java.rmi.RemoteException: Received invalid response code from  
>>>>> server: -1
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .client.EJBObjectHandler.businessMethod(EJBObjectHandler.java:239)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java: 
>>>>> 157)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>>>
>>>>>
>>>>> org 
>>>>> .apache 
>>>>> .openejb 
>>>>> .client 
>>>>> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java: 
>>>>> 52)
>>>>>  $Proxy2.captureLamp(Unknown Source)
>>>>>
>>>>>
>>>>> net 
>>>>> .kunye 
>>>>> .vds 
>>>>> .server 
>>>>> .services 
>>>>> .configuration 
>>>>> .ConfigurationService.service(ConfigurationService.java:73)
>>>>>   
>>>>> net 
>>>>> .kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>>>>
>>>>> --------- SNIP -----------
>>>>>
>>>>> After it recovers from the above, all is back to normal.
>>>>>
>>>>> This is quite serious. How I can get around this, even if I have  
>>>>> to
>>>>> make some code changes?
>>>>>
>>>>> Thanks again. I'm so relieved this problem is finally over.  
>>>>> Previously
>>>>> I've had to do some serious recovery just because a client was  
>>>>> left
>>>>> running and Glassfish's client library opened so many file  
>>>>> descriptors
>>>>> for each failure that the server crashed with a No Space Left on
>>>>> Device error.
>>>>>
>>>>> Quintin Beukes
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: openejb-client has OSGi Require-Bundle without a maven dependency. David Blevins <david.blevins@visi.com> urn:uuid:%3c3D532476-51AF-47E8-B510-F9B9115AC8B4@visi-com%3e 2009-12-01T21:58:45Z 

On Nov 3, 2009, at 12:12 PM, David Blevins wrote:

>
> On Nov 3, 2009, at 7:27 AM, Rick McGuire wrote:
>
>> I ran into a little issue with the bundlized version of the openejb- 
>> client jar.  This jar has a Require-Bundle dependency on  
>> org.apache.openejb.openebj-core, but the project pom does not  
>> specify a maven dependency on openejb-core.  This is causing a bit  
>> of an issue when used in Geronimo 3.0 because the framework is  
>> using the maven dependencies to determine the install/start order  
>> for the different bundles we're using.  Since there's no maven  
>> dependency, the openejb-client is giving a resolution constraint  
>> failure on the required jar depending on the relative order the  
>> different openejb bundles get started.  Having the correct maven  
>> dependency in the pom would sort all of that out.
>>
>> Is there some reason why this was done this way, or is it just an  
>> oversight?
>
> I'm not sure why there is a Require-Bundle dep on openejb-core.   
> Maybe someone else can comment on that.
>
> Code-wise, the client jar is designed to work without any other  
> OpenEJB libraries or third party dependencies (except for specs), so  
> that explains why there is not a maven dep.

Still looking for some followup.  As mentioned the openejb-client  
module does not need and should not be allowed to use the code in  
openejb-core.  Going to remove that dependency.

-David
Re: Connection Recovery Quintin Beukes <quintin@skywalk.co.za> urn:uuid:%3c1f3854d50911240048x6b5424c2y53da75f7384a9617@mail-gmail-com%3e 2009-11-24T08:48:39Z 
:> Original problem. I'm just trying to understand why it would take
so long even after newly started apps are working fine.

The "cross over server" sounds like a very good idea, though I would
still like to know how this works.

Quintin Beukes



On Tue, Nov 24, 2009 at 10:36 AM, David Blevins <david.blevins@visi.com> wrote:
>
> On Nov 24, 2009, at 12:14 AM, Quintin Beukes wrote:
>
>> But the problem is that after I redeployed the requests fail for up to
>> 6 minutes there after if the app was running prior even while newly
>> booted clients are working fine? So I would do this:
>>
>> 1. Run clientA
>> 2. Undeploy, deploy app - deploy completed successfully
>> 3. ClientA fails
>> 4. Run ClientB
>> 5. ClientB succeeds
>> 6. ClientA fails stills
>> 7. 5-6 minutes later clientA starts succeeding.
>>
>> Why is this? After the 5 minute period, what triggers the recovery to
>> start?
>
> Just so I make sure I'm on the same page, the above is a recap of the
> original problem?  Or are you now seeing 5-6 minute delays in the failover
> logic from one server to the next?
>
> -David
>
>> On Mon, Nov 23, 2009 at 10:32 PM, David Blevins <david.blevins@visi.com>
>> wrote:
>>>
>>> This is because there is no concept of blocking connections for
>>> applications
>>> that are being redeployed.  In fact our (geronimo and openejb) redeploy
>>> is
>>> just an undeploy followed by a deploy, so there's no special concept
>>> propagated throughout the architecture that something is only temporarily
>>> gone and will be coming back.
>>>
>>> That said, if we added all that, you'd still have to wait the exact same
>>> amount of time for the undeploy/deploy process plus a small shave off of
>>> total throughput for the synchronization we'd have to add to make the
>>> wait-for-redeploy logic work.  The bigger your app gets, the longer the
>>> time
>>> your client spends waiting, which is probably going to drive you to
>>> splinter
>>> your app into tiny fragments which only complicates things more and adds
>>> even more overhead.
>>>
>>> This is one of those "change the problem" types of situations.  Instead
>>> enable multicast discovery on your server and just let it run.  When you
>>> want to "redeploy", just boot a new server with the new version of the
>>> app.
>>>  When you get that server running to your liking -- almost everyone has
>>> some
>>> sort of initialization they like to do in their apps -- just shut down
>>> the
>>> first server and the client will immediately roll over to the second
>>> server.
>>>  No time spent waiting on redeploy and you actually get a chance to pound
>>> on
>>> your new server a bit before it goes live, so no more risk that the app
>>> doesn't quite work after the redeploy.
>>>
>>> You can do this all on the same machine with a shell script or ant script
>>> that is only slightly fancier than your standard start, deploy, run type
>>> of
>>> script.
>>>
>>> -David
>>>
>>> On Nov 23, 2009, at 6:20 AM, Quintin Beukes wrote:
>>>
>>>> Hey,
>>>>
>>>> One of the big motivations for shifting to OpenEJB 3.1.2 from GF was
>>>> the connection recovery built into it. My inquiry was specifically
>>>> about failed remote EJB connections because a server restarts or a
>>>> network hiccup. We've always had problems with this, especially with
>>>> networks running from surface to underground.
>>>>
>>>> This seems to be working. Great job!! Thanks alot. I'm aiming for
>>>> complete recovery in the following situations.
>>>> 1. System exception (any failure on the part of OpenEJB, even if the
>>>> cause was my own)
>>>> 2. Dropped connections due to network
>>>> 3. Dropped connections from server restart
>>>> 4. Dropped connections from redeploy (basically the same as (3) I
>>>> assume).
>>>>
>>>> Though I have a query though. Every time I redeploy, for ex, I have to
>>>> manually go and restart all services because it takes very long for
>>>> OpenEJB client to notice something is wrong and recover.
>>>>
>>>> Here is an example: If I undeploy, I get something like the following
>>>> on a client.
>>>>
>>>> --------- SNIP -----------
>>>>
>>>> javax.ejb.EJBException: Container has suffered a SystemException
>>>>
>>>>
>>>> org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:178)
>>>>
>>>>
>>>> org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>>
>>>>
>>>> org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>>>  $Proxy2.captureLamp(Unknown Source)
>>>>
>>>>
>>>> net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:73)
>>>>  net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>>>
>>>> java.rmi.RemoteException: The server has encountered a fatal error: No
>>>> such deployment java.rmi.RemoteException: No deployment:
>>>> VDS-lamps-ejb-3.0.jar/LampCaptureBean; nested exception is:
>>>>       java.rmi.RemoteException: No deployment:
>>>> VDS-lamps-ejb-3.0.jar/LampCaptureBean
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.EjbRequestHandler.replyWithFatalError(EjbRequestHandler.java:425)
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:81)
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
>>>>  org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:149)
>>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.KeepAliveServer$Session.service(KeepAliveServer.java:213)
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
>>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
>>>>  org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>>>>  org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>>>>
>>>>
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>>>
>>>>
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>>>  java.lang.Thread.run(Thread.java:619)
>>>>
>>>> java.rmi.RemoteException: No deployment:
>>>> VDS-lamps-ejb-3.0.jar/LampCaptureBean
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.EjbDaemon.getDeployment(EjbDaemon.java:191)
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:79)
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
>>>>  org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:149)
>>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.KeepAliveServer$Session.service(KeepAliveServer.java:213)
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
>>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
>>>>  org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>>>>  org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>>>>
>>>>
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>>>
>>>>
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>>>  java.lang.Thread.run(Thread.java:619)
>>>>
>>>>
>>>> 23 Nov 2009 15:59:20,039 ERROR -- Exception: Service
>>>> ConfigurationService failed for instance
>>>> ConfigurationService[/10.0.0.25] (java.lang.Exception)
>>>> java.lang.Exception: ConfigurationService has an unknown failure while
>>>> servicing a request.
>>>>
>>>>
>>>> net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:84)
>>>>  net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>>>
>>>> javax.ejb.EJBException: Container has suffered a SystemException
>>>>
>>>>
>>>> org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:178)
>>>>
>>>>
>>>> org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>>
>>>>
>>>> org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>>>  $Proxy2.captureLamp(Unknown Source)
>>>>
>>>>
>>>> net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:73)
>>>>  net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>>>
>>>> java.rmi.RemoteException: The server has encountered a fatal error: No
>>>> such deployment java.rmi.RemoteException: No deployment:
>>>> VDS-lamps-ejb-3.0.jar/LampCaptureBean; nested exception is:
>>>>       java.rmi.RemoteException: No deployment:
>>>> VDS-lamps-ejb-3.0.jar/LampCaptureBean
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.EjbRequestHandler.replyWithFatalError(EjbRequestHandler.java:425)
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:81)
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
>>>>  org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:149)
>>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.KeepAliveServer$Session.service(KeepAliveServer.java:213)
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
>>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
>>>>  org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>>>>  org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>>>>
>>>>
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>>>
>>>>
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>>>  java.lang.Thread.run(Thread.java:619)
>>>>
>>>> java.rmi.RemoteException: No deployment:
>>>> VDS-lamps-ejb-3.0.jar/LampCaptureBean
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.EjbDaemon.getDeployment(EjbDaemon.java:191)
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:79)
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
>>>>  org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:149)
>>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.KeepAliveServer$Session.service(KeepAliveServer.java:213)
>>>>
>>>>
>>>> org.apache.openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
>>>>  org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
>>>>  org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>>>>  org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>>>>
>>>>
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>>>
>>>>
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>>>  java.lang.Thread.run(Thread.java:619)
>>>>
>>>> --------- SNIP -----------
>>>>
>>>> Then, for a while, even after the EJB service started up completely
>>>> and even though I'm creating new InitialContext instances I get the
>>>> following. This isn't too bad, though it does take a few minutes
>>>> (between 3 and 5) to recover.
>>>>
>>>> --------- SNIP -----------
>>>>
>>>> 23 Nov 2009 16:00:24,802 TRACE -- Received packet
>>>> [R0010088220000000000000000]
>>>> 23 Nov 2009 16:00:24,804 ERROR -- Exception: Unknown failure servicing
>>>> the request (javax.ejb.EJBException)
>>>> javax.ejb.EJBException: Unknown Container Exception:
>>>> java.rmi.RemoteException: Received invalid response code from server:
>>>> -1
>>>>
>>>>
>>>> org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:184)
>>>>
>>>>
>>>> org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>>
>>>>
>>>> org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>>>  $Proxy2.captureLamp(Unknown Source)
>>>>
>>>>
>>>> net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:73)
>>>>  net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>>>
>>>> java.rmi.RemoteException: Received invalid response code from server: -1
>>>>
>>>>
>>>> org.apache.openejb.client.EJBObjectHandler.businessMethod(EJBObjectHandler.java:239)
>>>>
>>>>
>>>> org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:157)
>>>>
>>>>
>>>> org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>>
>>>>
>>>> org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>>>  $Proxy2.captureLamp(Unknown Source)
>>>>
>>>>
>>>> net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:73)
>>>>  net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>>>
>>>>
>>>> 23 Nov 2009 16:00:24,804 ERROR -- Exception: Service
>>>> ConfigurationService failed for instance
>>>> ConfigurationService[/10.0.0.25] (java.lang.Exception)
>>>> java.lang.Exception: ConfigurationService has an unknown failure while
>>>> servicing a request.
>>>>
>>>>
>>>> net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:84)
>>>>  net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>>>
>>>> javax.ejb.EJBException: Unknown Container Exception:
>>>> java.rmi.RemoteException: Received invalid response code from server:
>>>> -1
>>>>
>>>>
>>>> org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:184)
>>>>
>>>>
>>>> org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>>
>>>>
>>>> org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>>>  $Proxy2.captureLamp(Unknown Source)
>>>>
>>>>
>>>> net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:73)
>>>>  net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>>>
>>>> java.rmi.RemoteException: Received invalid response code from server: -1
>>>>
>>>>
>>>> org.apache.openejb.client.EJBObjectHandler.businessMethod(EJBObjectHandler.java:239)
>>>>
>>>>
>>>> org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:157)
>>>>
>>>>
>>>> org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>>
>>>>
>>>> org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>>>  $Proxy2.captureLamp(Unknown Source)
>>>>
>>>>
>>>> net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:73)
>>>>  net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>>>
>>>> --------- SNIP -----------
>>>>
>>>> After it recovers from the above, all is back to normal.
>>>>
>>>> This is quite serious. How I can get around this, even if I have to
>>>> make some code changes?
>>>>
>>>> Thanks again. I'm so relieved this problem is finally over. Previously
>>>> I've had to do some serious recovery just because a client was left
>>>> running and Glassfish's client library opened so many file descriptors
>>>> for each failure that the server crashed with a No Space Left on
>>>> Device error.
>>>>
>>>> Quintin Beukes
>>>>
>>>
>>>
>>
>
>
Re: Connection Recovery David Blevins <david.blevins@visi.com> urn:uuid:%3c1822D2DE-E377-4A5A-A6DC-3020ABAA97DB@visi-com%3e 2009-11-24T08:36:16Z 

On Nov 24, 2009, at 12:14 AM, Quintin Beukes wrote:

> But the problem is that after I redeployed the requests fail for up to
> 6 minutes there after if the app was running prior even while newly
> booted clients are working fine? So I would do this:
>
> 1. Run clientA
> 2. Undeploy, deploy app - deploy completed successfully
> 3. ClientA fails
> 4. Run ClientB
> 5. ClientB succeeds
> 6. ClientA fails stills
> 7. 5-6 minutes later clientA starts succeeding.
>
> Why is this? After the 5 minute period, what triggers the recovery  
> to start?

Just so I make sure I'm on the same page, the above is a recap of the  
original problem?  Or are you now seeing 5-6 minute delays in the  
failover logic from one server to the next?

-David

> On Mon, Nov 23, 2009 at 10:32 PM, David Blevins <david.blevins@visi.com 
> > wrote:
>> This is because there is no concept of blocking connections for  
>> applications
>> that are being redeployed.  In fact our (geronimo and openejb)  
>> redeploy is
>> just an undeploy followed by a deploy, so there's no special concept
>> propagated throughout the architecture that something is only  
>> temporarily
>> gone and will be coming back.
>>
>> That said, if we added all that, you'd still have to wait the exact  
>> same
>> amount of time for the undeploy/deploy process plus a small shave  
>> off of
>> total throughput for the synchronization we'd have to add to make the
>> wait-for-redeploy logic work.  The bigger your app gets, the longer  
>> the time
>> your client spends waiting, which is probably going to drive you to  
>> splinter
>> your app into tiny fragments which only complicates things more and  
>> adds
>> even more overhead.
>>
>> This is one of those "change the problem" types of situations.   
>> Instead
>> enable multicast discovery on your server and just let it run.   
>> When you
>> want to "redeploy", just boot a new server with the new version of  
>> the app.
>>  When you get that server running to your liking -- almost everyone  
>> has some
>> sort of initialization they like to do in their apps -- just shut  
>> down the
>> first server and the client will immediately roll over to the  
>> second server.
>>  No time spent waiting on redeploy and you actually get a chance to  
>> pound on
>> your new server a bit before it goes live, so no more risk that the  
>> app
>> doesn't quite work after the redeploy.
>>
>> You can do this all on the same machine with a shell script or ant  
>> script
>> that is only slightly fancier than your standard start, deploy, run  
>> type of
>> script.
>>
>> -David
>>
>> On Nov 23, 2009, at 6:20 AM, Quintin Beukes wrote:
>>
>>> Hey,
>>>
>>> One of the big motivations for shifting to OpenEJB 3.1.2 from GF was
>>> the connection recovery built into it. My inquiry was specifically
>>> about failed remote EJB connections because a server restarts or a
>>> network hiccup. We've always had problems with this, especially with
>>> networks running from surface to underground.
>>>
>>> This seems to be working. Great job!! Thanks alot. I'm aiming for
>>> complete recovery in the following situations.
>>> 1. System exception (any failure on the part of OpenEJB, even if the
>>> cause was my own)
>>> 2. Dropped connections due to network
>>> 3. Dropped connections from server restart
>>> 4. Dropped connections from redeploy (basically the same as (3) I  
>>> assume).
>>>
>>> Though I have a query though. Every time I redeploy, for ex, I  
>>> have to
>>> manually go and restart all services because it takes very long for
>>> OpenEJB client to notice something is wrong and recover.
>>>
>>> Here is an example: If I undeploy, I get something like the  
>>> following
>>> on a client.
>>>
>>> --------- SNIP -----------
>>>
>>> javax.ejb.EJBException: Container has suffered a SystemException
>>>
>>> org 
>>> .apache 
>>> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:178)
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client 
>>> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>>   $Proxy2.captureLamp(Unknown Source)
>>>
>>> net 
>>> .kunye 
>>> .vds 
>>> .server 
>>> .services 
>>> .configuration 
>>> .ConfigurationService.service(ConfigurationService.java:73)
>>>    
>>> net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java: 
>>> 86)
>>>
>>> java.rmi.RemoteException: The server has encountered a fatal  
>>> error: No
>>> such deployment java.rmi.RemoteException: No deployment:
>>> VDS-lamps-ejb-3.0.jar/LampCaptureBean; nested exception is:
>>>        java.rmi.RemoteException: No deployment:
>>> VDS-lamps-ejb-3.0.jar/LampCaptureBean
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .server 
>>> .ejbd.EjbRequestHandler.replyWithFatalError(EjbRequestHandler.java: 
>>> 425)
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .server 
>>> .ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:81)
>>>
>>> org 
>>> .apache 
>>> .openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
>>>   org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java: 
>>> 149)
>>>   org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java: 
>>> 71)
>>>
>>> org.apache.openejb.server.ejbd.KeepAliveServer 
>>> $Session.service(KeepAliveServer.java:213)
>>>
>>> org 
>>> .apache 
>>> .openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java: 
>>> 233)
>>>   org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java: 
>>> 66)
>>>   org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>>>   org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>>>
>>> java.util.concurrent.ThreadPoolExecutor 
>>> $Worker.runTask(ThreadPoolExecutor.java:886)
>>>
>>> java.util.concurrent.ThreadPoolExecutor 
>>> $Worker.run(ThreadPoolExecutor.java:908)
>>>   java.lang.Thread.run(Thread.java:619)
>>>
>>> java.rmi.RemoteException: No deployment:
>>> VDS-lamps-ejb-3.0.jar/LampCaptureBean
>>>
>>> org 
>>> .apache.openejb.server.ejbd.EjbDaemon.getDeployment(EjbDaemon.java: 
>>> 191)
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .server 
>>> .ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:79)
>>>
>>> org 
>>> .apache 
>>> .openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
>>>   org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java: 
>>> 149)
>>>   org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java: 
>>> 71)
>>>
>>> org.apache.openejb.server.ejbd.KeepAliveServer 
>>> $Session.service(KeepAliveServer.java:213)
>>>
>>> org 
>>> .apache 
>>> .openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java: 
>>> 233)
>>>   org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java: 
>>> 66)
>>>   org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>>>   org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>>>
>>> java.util.concurrent.ThreadPoolExecutor 
>>> $Worker.runTask(ThreadPoolExecutor.java:886)
>>>
>>> java.util.concurrent.ThreadPoolExecutor 
>>> $Worker.run(ThreadPoolExecutor.java:908)
>>>   java.lang.Thread.run(Thread.java:619)
>>>
>>>
>>> 23 Nov 2009 15:59:20,039 ERROR -- Exception: Service
>>> ConfigurationService failed for instance
>>> ConfigurationService[/10.0.0.25] (java.lang.Exception)
>>> java.lang.Exception: ConfigurationService has an unknown failure  
>>> while
>>> servicing a request.
>>>
>>> net 
>>> .kunye 
>>> .vds 
>>> .server 
>>> .services 
>>> .configuration 
>>> .ConfigurationService.service(ConfigurationService.java:84)
>>>    
>>> net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java: 
>>> 86)
>>>
>>> javax.ejb.EJBException: Container has suffered a SystemException
>>>
>>> org 
>>> .apache 
>>> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:178)
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client 
>>> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>>   $Proxy2.captureLamp(Unknown Source)
>>>
>>> net 
>>> .kunye 
>>> .vds 
>>> .server 
>>> .services 
>>> .configuration 
>>> .ConfigurationService.service(ConfigurationService.java:73)
>>>    
>>> net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java: 
>>> 86)
>>>
>>> java.rmi.RemoteException: The server has encountered a fatal  
>>> error: No
>>> such deployment java.rmi.RemoteException: No deployment:
>>> VDS-lamps-ejb-3.0.jar/LampCaptureBean; nested exception is:
>>>        java.rmi.RemoteException: No deployment:
>>> VDS-lamps-ejb-3.0.jar/LampCaptureBean
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .server 
>>> .ejbd.EjbRequestHandler.replyWithFatalError(EjbRequestHandler.java: 
>>> 425)
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .server 
>>> .ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:81)
>>>
>>> org 
>>> .apache 
>>> .openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
>>>   org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java: 
>>> 149)
>>>   org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java: 
>>> 71)
>>>
>>> org.apache.openejb.server.ejbd.KeepAliveServer 
>>> $Session.service(KeepAliveServer.java:213)
>>>
>>> org 
>>> .apache 
>>> .openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java: 
>>> 233)
>>>   org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java: 
>>> 66)
>>>   org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>>>   org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>>>
>>> java.util.concurrent.ThreadPoolExecutor 
>>> $Worker.runTask(ThreadPoolExecutor.java:886)
>>>
>>> java.util.concurrent.ThreadPoolExecutor 
>>> $Worker.run(ThreadPoolExecutor.java:908)
>>>   java.lang.Thread.run(Thread.java:619)
>>>
>>> java.rmi.RemoteException: No deployment:
>>> VDS-lamps-ejb-3.0.jar/LampCaptureBean
>>>
>>> org 
>>> .apache.openejb.server.ejbd.EjbDaemon.getDeployment(EjbDaemon.java: 
>>> 191)
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .server 
>>> .ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:79)
>>>
>>> org 
>>> .apache 
>>> .openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
>>>   org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java: 
>>> 149)
>>>   org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java: 
>>> 71)
>>>
>>> org.apache.openejb.server.ejbd.KeepAliveServer 
>>> $Session.service(KeepAliveServer.java:213)
>>>
>>> org 
>>> .apache 
>>> .openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java: 
>>> 233)
>>>   org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java: 
>>> 66)
>>>   org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>>>   org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>>>
>>> java.util.concurrent.ThreadPoolExecutor 
>>> $Worker.runTask(ThreadPoolExecutor.java:886)
>>>
>>> java.util.concurrent.ThreadPoolExecutor 
>>> $Worker.run(ThreadPoolExecutor.java:908)
>>>   java.lang.Thread.run(Thread.java:619)
>>>
>>> --------- SNIP -----------
>>>
>>> Then, for a while, even after the EJB service started up completely
>>> and even though I'm creating new InitialContext instances I get the
>>> following. This isn't too bad, though it does take a few minutes
>>> (between 3 and 5) to recover.
>>>
>>> --------- SNIP -----------
>>>
>>> 23 Nov 2009 16:00:24,802 TRACE -- Received packet
>>> [R0010088220000000000000000]
>>> 23 Nov 2009 16:00:24,804 ERROR -- Exception: Unknown failure  
>>> servicing
>>> the request (javax.ejb.EJBException)
>>> javax.ejb.EJBException: Unknown Container Exception:
>>> java.rmi.RemoteException: Received invalid response code from  
>>> server:
>>> -1
>>>
>>> org 
>>> .apache 
>>> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:184)
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client 
>>> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>>   $Proxy2.captureLamp(Unknown Source)
>>>
>>> net 
>>> .kunye 
>>> .vds 
>>> .server 
>>> .services 
>>> .configuration 
>>> .ConfigurationService.service(ConfigurationService.java:73)
>>>    
>>> net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java: 
>>> 86)
>>>
>>> java.rmi.RemoteException: Received invalid response code from  
>>> server: -1
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client.EJBObjectHandler.businessMethod(EJBObjectHandler.java:239)
>>>
>>> org 
>>> .apache 
>>> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:157)
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client 
>>> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>>   $Proxy2.captureLamp(Unknown Source)
>>>
>>> net 
>>> .kunye 
>>> .vds 
>>> .server 
>>> .services 
>>> .configuration 
>>> .ConfigurationService.service(ConfigurationService.java:73)
>>>    
>>> net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java: 
>>> 86)
>>>
>>>
>>> 23 Nov 2009 16:00:24,804 ERROR -- Exception: Service
>>> ConfigurationService failed for instance
>>> ConfigurationService[/10.0.0.25] (java.lang.Exception)
>>> java.lang.Exception: ConfigurationService has an unknown failure  
>>> while
>>> servicing a request.
>>>
>>> net 
>>> .kunye 
>>> .vds 
>>> .server 
>>> .services 
>>> .configuration 
>>> .ConfigurationService.service(ConfigurationService.java:84)
>>>    
>>> net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java: 
>>> 86)
>>>
>>> javax.ejb.EJBException: Unknown Container Exception:
>>> java.rmi.RemoteException: Received invalid response code from  
>>> server:
>>> -1
>>>
>>> org 
>>> .apache 
>>> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:184)
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client 
>>> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>>   $Proxy2.captureLamp(Unknown Source)
>>>
>>> net 
>>> .kunye 
>>> .vds 
>>> .server 
>>> .services 
>>> .configuration 
>>> .ConfigurationService.service(ConfigurationService.java:73)
>>>    
>>> net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java: 
>>> 86)
>>>
>>> java.rmi.RemoteException: Received invalid response code from  
>>> server: -1
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client.EJBObjectHandler.businessMethod(EJBObjectHandler.java:239)
>>>
>>> org 
>>> .apache 
>>> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:157)
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>>
>>> org 
>>> .apache 
>>> .openejb 
>>> .client 
>>> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>>   $Proxy2.captureLamp(Unknown Source)
>>>
>>> net 
>>> .kunye 
>>> .vds 
>>> .server 
>>> .services 
>>> .configuration 
>>> .ConfigurationService.service(ConfigurationService.java:73)
>>>    
>>> net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java: 
>>> 86)
>>>
>>> --------- SNIP -----------
>>>
>>> After it recovers from the above, all is back to normal.
>>>
>>> This is quite serious. How I can get around this, even if I have to
>>> make some code changes?
>>>
>>> Thanks again. I'm so relieved this problem is finally over.  
>>> Previously
>>> I've had to do some serious recovery just because a client was left
>>> running and Glassfish's client library opened so many file  
>>> descriptors
>>> for each failure that the server crashed with a No Space Left on
>>> Device error.
>>>
>>> Quintin Beukes
>>>
>>
>>
>
Re: Connection Recovery Quintin Beukes <quintin@skywalk.co.za> urn:uuid:%3c1f3854d50911240014s3627f9ffv102b6f3fe2816bb6@mail-gmail-com%3e 2009-11-24T08:14:12Z 
But the problem is that after I redeployed the requests fail for up to
6 minutes there after if the app was running prior even while newly
booted clients are working fine? So I would do this:

1. Run clientA
2. Undeploy, deploy app - deploy completed successfully
3. ClientA fails
4. Run ClientB
5. ClientB succeeds
6. ClientA fails stills
7. 5-6 minutes later clientA starts succeeding.

Why is this? After the 5 minute period, what triggers the recovery to start?

Quintin Beukes



On Mon, Nov 23, 2009 at 10:32 PM, David Blevins <david.blevins@visi.com> wrote:
> This is because there is no concept of blocking connections for applications
> that are being redeployed.  In fact our (geronimo and openejb) redeploy is
> just an undeploy followed by a deploy, so there's no special concept
> propagated throughout the architecture that something is only temporarily
> gone and will be coming back.
>
> That said, if we added all that, you'd still have to wait the exact same
> amount of time for the undeploy/deploy process plus a small shave off of
> total throughput for the synchronization we'd have to add to make the
> wait-for-redeploy logic work.  The bigger your app gets, the longer the time
> your client spends waiting, which is probably going to drive you to splinter
> your app into tiny fragments which only complicates things more and adds
> even more overhead.
>
> This is one of those "change the problem" types of situations.  Instead
> enable multicast discovery on your server and just let it run.  When you
> want to "redeploy", just boot a new server with the new version of the app.
>  When you get that server running to your liking -- almost everyone has some
> sort of initialization they like to do in their apps -- just shut down the
> first server and the client will immediately roll over to the second server.
>  No time spent waiting on redeploy and you actually get a chance to pound on
> your new server a bit before it goes live, so no more risk that the app
> doesn't quite work after the redeploy.
>
> You can do this all on the same machine with a shell script or ant script
> that is only slightly fancier than your standard start, deploy, run type of
> script.
>
> -David
>
> On Nov 23, 2009, at 6:20 AM, Quintin Beukes wrote:
>
>> Hey,
>>
>> One of the big motivations for shifting to OpenEJB 3.1.2 from GF was
>> the connection recovery built into it. My inquiry was specifically
>> about failed remote EJB connections because a server restarts or a
>> network hiccup. We've always had problems with this, especially with
>> networks running from surface to underground.
>>
>> This seems to be working. Great job!! Thanks alot. I'm aiming for
>> complete recovery in the following situations.
>> 1. System exception (any failure on the part of OpenEJB, even if the
>> cause was my own)
>> 2. Dropped connections due to network
>> 3. Dropped connections from server restart
>> 4. Dropped connections from redeploy (basically the same as (3) I assume).
>>
>> Though I have a query though. Every time I redeploy, for ex, I have to
>> manually go and restart all services because it takes very long for
>> OpenEJB client to notice something is wrong and recover.
>>
>> Here is an example: If I undeploy, I get something like the following
>> on a client.
>>
>> --------- SNIP -----------
>>
>> javax.ejb.EJBException: Container has suffered a SystemException
>>
>> org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:178)
>>
>> org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>
>> org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>   $Proxy2.captureLamp(Unknown Source)
>>
>> net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:73)
>>   net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>
>> java.rmi.RemoteException: The server has encountered a fatal error: No
>> such deployment java.rmi.RemoteException: No deployment:
>> VDS-lamps-ejb-3.0.jar/LampCaptureBean; nested exception is:
>>        java.rmi.RemoteException: No deployment:
>> VDS-lamps-ejb-3.0.jar/LampCaptureBean
>>
>> org.apache.openejb.server.ejbd.EjbRequestHandler.replyWithFatalError(EjbRequestHandler.java:425)
>>
>> org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:81)
>>
>> org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
>>   org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:149)
>>   org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
>>
>> org.apache.openejb.server.ejbd.KeepAliveServer$Session.service(KeepAliveServer.java:213)
>>
>> org.apache.openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
>>   org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
>>   org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>>   org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>   java.lang.Thread.run(Thread.java:619)
>>
>> java.rmi.RemoteException: No deployment:
>> VDS-lamps-ejb-3.0.jar/LampCaptureBean
>>
>> org.apache.openejb.server.ejbd.EjbDaemon.getDeployment(EjbDaemon.java:191)
>>
>> org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:79)
>>
>> org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
>>   org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:149)
>>   org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
>>
>> org.apache.openejb.server.ejbd.KeepAliveServer$Session.service(KeepAliveServer.java:213)
>>
>> org.apache.openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
>>   org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
>>   org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>>   org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>   java.lang.Thread.run(Thread.java:619)
>>
>>
>> 23 Nov 2009 15:59:20,039 ERROR -- Exception: Service
>> ConfigurationService failed for instance
>> ConfigurationService[/10.0.0.25] (java.lang.Exception)
>> java.lang.Exception: ConfigurationService has an unknown failure while
>> servicing a request.
>>
>> net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:84)
>>   net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>
>> javax.ejb.EJBException: Container has suffered a SystemException
>>
>> org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:178)
>>
>> org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>
>> org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>   $Proxy2.captureLamp(Unknown Source)
>>
>> net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:73)
>>   net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>
>> java.rmi.RemoteException: The server has encountered a fatal error: No
>> such deployment java.rmi.RemoteException: No deployment:
>> VDS-lamps-ejb-3.0.jar/LampCaptureBean; nested exception is:
>>        java.rmi.RemoteException: No deployment:
>> VDS-lamps-ejb-3.0.jar/LampCaptureBean
>>
>> org.apache.openejb.server.ejbd.EjbRequestHandler.replyWithFatalError(EjbRequestHandler.java:425)
>>
>> org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:81)
>>
>> org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
>>   org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:149)
>>   org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
>>
>> org.apache.openejb.server.ejbd.KeepAliveServer$Session.service(KeepAliveServer.java:213)
>>
>> org.apache.openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
>>   org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
>>   org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>>   org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>   java.lang.Thread.run(Thread.java:619)
>>
>> java.rmi.RemoteException: No deployment:
>> VDS-lamps-ejb-3.0.jar/LampCaptureBean
>>
>> org.apache.openejb.server.ejbd.EjbDaemon.getDeployment(EjbDaemon.java:191)
>>
>> org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:79)
>>
>> org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
>>   org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:149)
>>   org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
>>
>> org.apache.openejb.server.ejbd.KeepAliveServer$Session.service(KeepAliveServer.java:213)
>>
>> org.apache.openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
>>   org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
>>   org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>>   org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>   java.lang.Thread.run(Thread.java:619)
>>
>> --------- SNIP -----------
>>
>> Then, for a while, even after the EJB service started up completely
>> and even though I'm creating new InitialContext instances I get the
>> following. This isn't too bad, though it does take a few minutes
>> (between 3 and 5) to recover.
>>
>> --------- SNIP -----------
>>
>> 23 Nov 2009 16:00:24,802 TRACE -- Received packet
>> [R0010088220000000000000000]
>> 23 Nov 2009 16:00:24,804 ERROR -- Exception: Unknown failure servicing
>> the request (javax.ejb.EJBException)
>> javax.ejb.EJBException: Unknown Container Exception:
>> java.rmi.RemoteException: Received invalid response code from server:
>> -1
>>
>> org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:184)
>>
>> org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>
>> org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>   $Proxy2.captureLamp(Unknown Source)
>>
>> net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:73)
>>   net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>
>> java.rmi.RemoteException: Received invalid response code from server: -1
>>
>> org.apache.openejb.client.EJBObjectHandler.businessMethod(EJBObjectHandler.java:239)
>>
>> org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:157)
>>
>> org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>
>> org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>   $Proxy2.captureLamp(Unknown Source)
>>
>> net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:73)
>>   net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>
>>
>> 23 Nov 2009 16:00:24,804 ERROR -- Exception: Service
>> ConfigurationService failed for instance
>> ConfigurationService[/10.0.0.25] (java.lang.Exception)
>> java.lang.Exception: ConfigurationService has an unknown failure while
>> servicing a request.
>>
>> net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:84)
>>   net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>
>> javax.ejb.EJBException: Unknown Container Exception:
>> java.rmi.RemoteException: Received invalid response code from server:
>> -1
>>
>> org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:184)
>>
>> org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>
>> org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>   $Proxy2.captureLamp(Unknown Source)
>>
>> net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:73)
>>   net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>
>> java.rmi.RemoteException: Received invalid response code from server: -1
>>
>> org.apache.openejb.client.EJBObjectHandler.businessMethod(EJBObjectHandler.java:239)
>>
>> org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:157)
>>
>> org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>>
>> org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>>   $Proxy2.captureLamp(Unknown Source)
>>
>> net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:73)
>>   net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)
>>
>> --------- SNIP -----------
>>
>> After it recovers from the above, all is back to normal.
>>
>> This is quite serious. How I can get around this, even if I have to
>> make some code changes?
>>
>> Thanks again. I'm so relieved this problem is finally over. Previously
>> I've had to do some serious recovery just because a client was left
>> running and Glassfish's client library opened so many file descriptors
>> for each failure that the server crashed with a No Space Left on
>> Device error.
>>
>> Quintin Beukes
>>
>
>
Re: Connection Recovery David Blevins <david.blevins@visi.com> urn:uuid:%3cC08F635E-CF58-4310-BCCA-DD26046BD259@visi-com%3e 2009-11-23T20:32:45Z 
This is because there is no concept of blocking connections for  
applications that are being redeployed.  In fact our (geronimo and  
openejb) redeploy is just an undeploy followed by a deploy, so there's  
no special concept propagated throughout the architecture that  
something is only temporarily gone and will be coming back.

That said, if we added all that, you'd still have to wait the exact  
same amount of time for the undeploy/deploy process plus a small shave  
off of total throughput for the synchronization we'd have to add to  
make the wait-for-redeploy logic work.  The bigger your app gets, the  
longer the time your client spends waiting, which is probably going to  
drive you to splinter your app into tiny fragments which only  
complicates things more and adds even more overhead.

This is one of those "change the problem" types of situations.   
Instead enable multicast discovery on your server and just let it  
run.  When you want to "redeploy", just boot a new server with the new  
version of the app.  When you get that server running to your liking  
-- almost everyone has some sort of initialization they like to do in  
their apps -- just shut down the first server and the client will  
immediately roll over to the second server.  No time spent waiting on  
redeploy and you actually get a chance to pound on your new server a  
bit before it goes live, so no more risk that the app doesn't quite  
work after the redeploy.

You can do this all on the same machine with a shell script or ant  
script that is only slightly fancier than your standard start, deploy,  
run type of script.

-David

On Nov 23, 2009, at 6:20 AM, Quintin Beukes wrote:

> Hey,
>
> One of the big motivations for shifting to OpenEJB 3.1.2 from GF was
> the connection recovery built into it. My inquiry was specifically
> about failed remote EJB connections because a server restarts or a
> network hiccup. We've always had problems with this, especially with
> networks running from surface to underground.
>
> This seems to be working. Great job!! Thanks alot. I'm aiming for
> complete recovery in the following situations.
> 1. System exception (any failure on the part of OpenEJB, even if the
> cause was my own)
> 2. Dropped connections due to network
> 3. Dropped connections from server restart
> 4. Dropped connections from redeploy (basically the same as (3) I  
> assume).
>
> Though I have a query though. Every time I redeploy, for ex, I have to
> manually go and restart all services because it takes very long for
> OpenEJB client to notice something is wrong and recover.
>
> Here is an example: If I undeploy, I get something like the following
> on a client.
>
> --------- SNIP -----------
>
> javax.ejb.EJBException: Container has suffered a SystemException
>     
> org 
> .apache 
> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:178)
>     
> org 
> .apache 
> .openejb 
> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>     
> org 
> .apache 
> .openejb 
> .client 
> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>    $Proxy2.captureLamp(Unknown Source)
>     
> net 
> .kunye 
> .vds 
> .server 
> .services 
> .configuration 
> .ConfigurationService.service(ConfigurationService.java:73)
>    net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java: 
> 86)
>
> java.rmi.RemoteException: The server has encountered a fatal error: No
> such deployment java.rmi.RemoteException: No deployment:
> VDS-lamps-ejb-3.0.jar/LampCaptureBean; nested exception is:
> 	java.rmi.RemoteException: No deployment: VDS-lamps-ejb-3.0.jar/ 
> LampCaptureBean
>     
> org 
> .apache 
> .openejb 
> .server 
> .ejbd.EjbRequestHandler.replyWithFatalError(EjbRequestHandler.java: 
> 425)
>     
> org 
> .apache 
> .openejb 
> .server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java: 
> 81)
>     
> org 
> .apache 
> .openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
>    org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java: 
> 149)
>    org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
>    org.apache.openejb.server.ejbd.KeepAliveServer 
> $Session.service(KeepAliveServer.java:213)
>     
> org 
> .apache 
> .openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
>    org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
>    org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>    org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>    java.util.concurrent.ThreadPoolExecutor 
> $Worker.runTask(ThreadPoolExecutor.java:886)
>    java.util.concurrent.ThreadPoolExecutor 
> $Worker.run(ThreadPoolExecutor.java:908)
>    java.lang.Thread.run(Thread.java:619)
>
> java.rmi.RemoteException: No deployment: VDS-lamps-ejb-3.0.jar/ 
> LampCaptureBean
>     
> org 
> .apache.openejb.server.ejbd.EjbDaemon.getDeployment(EjbDaemon.java: 
> 191)
>     
> org 
> .apache 
> .openejb 
> .server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java: 
> 79)
>     
> org 
> .apache 
> .openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
>    org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java: 
> 149)
>    org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
>    org.apache.openejb.server.ejbd.KeepAliveServer 
> $Session.service(KeepAliveServer.java:213)
>     
> org 
> .apache 
> .openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
>    org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
>    org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>    org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>    java.util.concurrent.ThreadPoolExecutor 
> $Worker.runTask(ThreadPoolExecutor.java:886)
>    java.util.concurrent.ThreadPoolExecutor 
> $Worker.run(ThreadPoolExecutor.java:908)
>    java.lang.Thread.run(Thread.java:619)
>
>
> 23 Nov 2009 15:59:20,039 ERROR -- Exception: Service
> ConfigurationService failed for instance
> ConfigurationService[/10.0.0.25] (java.lang.Exception)
> java.lang.Exception: ConfigurationService has an unknown failure while
> servicing a request.
>     
> net 
> .kunye 
> .vds 
> .server 
> .services 
> .configuration 
> .ConfigurationService.service(ConfigurationService.java:84)
>    net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java: 
> 86)
>
> javax.ejb.EJBException: Container has suffered a SystemException
>     
> org 
> .apache 
> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:178)
>     
> org 
> .apache 
> .openejb 
> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>     
> org 
> .apache 
> .openejb 
> .client 
> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>    $Proxy2.captureLamp(Unknown Source)
>     
> net 
> .kunye 
> .vds 
> .server 
> .services 
> .configuration 
> .ConfigurationService.service(ConfigurationService.java:73)
>    net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java: 
> 86)
>
> java.rmi.RemoteException: The server has encountered a fatal error: No
> such deployment java.rmi.RemoteException: No deployment:
> VDS-lamps-ejb-3.0.jar/LampCaptureBean; nested exception is:
> 	java.rmi.RemoteException: No deployment: VDS-lamps-ejb-3.0.jar/ 
> LampCaptureBean
>     
> org 
> .apache 
> .openejb 
> .server 
> .ejbd.EjbRequestHandler.replyWithFatalError(EjbRequestHandler.java: 
> 425)
>     
> org 
> .apache 
> .openejb 
> .server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java: 
> 81)
>     
> org 
> .apache 
> .openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
>    org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java: 
> 149)
>    org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
>    org.apache.openejb.server.ejbd.KeepAliveServer 
> $Session.service(KeepAliveServer.java:213)
>     
> org 
> .apache 
> .openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
>    org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
>    org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>    org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>    java.util.concurrent.ThreadPoolExecutor 
> $Worker.runTask(ThreadPoolExecutor.java:886)
>    java.util.concurrent.ThreadPoolExecutor 
> $Worker.run(ThreadPoolExecutor.java:908)
>    java.lang.Thread.run(Thread.java:619)
>
> java.rmi.RemoteException: No deployment: VDS-lamps-ejb-3.0.jar/ 
> LampCaptureBean
>     
> org 
> .apache.openejb.server.ejbd.EjbDaemon.getDeployment(EjbDaemon.java: 
> 191)
>     
> org 
> .apache 
> .openejb 
> .server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java: 
> 79)
>     
> org 
> .apache 
> .openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
>    org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java: 
> 149)
>    org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
>    org.apache.openejb.server.ejbd.KeepAliveServer 
> $Session.service(KeepAliveServer.java:213)
>     
> org 
> .apache 
> .openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
>    org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
>    org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>    org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>    java.util.concurrent.ThreadPoolExecutor 
> $Worker.runTask(ThreadPoolExecutor.java:886)
>    java.util.concurrent.ThreadPoolExecutor 
> $Worker.run(ThreadPoolExecutor.java:908)
>    java.lang.Thread.run(Thread.java:619)
>
> --------- SNIP -----------
>
> Then, for a while, even after the EJB service started up completely
> and even though I'm creating new InitialContext instances I get the
> following. This isn't too bad, though it does take a few minutes
> (between 3 and 5) to recover.
>
> --------- SNIP -----------
>
> 23 Nov 2009 16:00:24,802 TRACE -- Received packet  
> [R0010088220000000000000000]
> 23 Nov 2009 16:00:24,804 ERROR -- Exception: Unknown failure servicing
> the request (javax.ejb.EJBException)
> javax.ejb.EJBException: Unknown Container Exception:
> java.rmi.RemoteException: Received invalid response code from server:
> -1
>     
> org 
> .apache 
> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:184)
>     
> org 
> .apache 
> .openejb 
> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>     
> org 
> .apache 
> .openejb 
> .client 
> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>    $Proxy2.captureLamp(Unknown Source)
>     
> net 
> .kunye 
> .vds 
> .server 
> .services 
> .configuration 
> .ConfigurationService.service(ConfigurationService.java:73)
>    net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java: 
> 86)
>
> java.rmi.RemoteException: Received invalid response code from  
> server: -1
>     
> org 
> .apache 
> .openejb 
> .client.EJBObjectHandler.businessMethod(EJBObjectHandler.java:239)
>     
> org 
> .apache 
> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:157)
>     
> org 
> .apache 
> .openejb 
> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>     
> org 
> .apache 
> .openejb 
> .client 
> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>    $Proxy2.captureLamp(Unknown Source)
>     
> net 
> .kunye 
> .vds 
> .server 
> .services 
> .configuration 
> .ConfigurationService.service(ConfigurationService.java:73)
>    net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java: 
> 86)
>
>
> 23 Nov 2009 16:00:24,804 ERROR -- Exception: Service
> ConfigurationService failed for instance
> ConfigurationService[/10.0.0.25] (java.lang.Exception)
> java.lang.Exception: ConfigurationService has an unknown failure while
> servicing a request.
>     
> net 
> .kunye 
> .vds 
> .server 
> .services 
> .configuration 
> .ConfigurationService.service(ConfigurationService.java:84)
>    net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java: 
> 86)
>
> javax.ejb.EJBException: Unknown Container Exception:
> java.rmi.RemoteException: Received invalid response code from server:
> -1
>     
> org 
> .apache 
> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:184)
>     
> org 
> .apache 
> .openejb 
> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>     
> org 
> .apache 
> .openejb 
> .client 
> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>    $Proxy2.captureLamp(Unknown Source)
>     
> net 
> .kunye 
> .vds 
> .server 
> .services 
> .configuration 
> .ConfigurationService.service(ConfigurationService.java:73)
>    net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java: 
> 86)
>
> java.rmi.RemoteException: Received invalid response code from  
> server: -1
>     
> org 
> .apache 
> .openejb 
> .client.EJBObjectHandler.businessMethod(EJBObjectHandler.java:239)
>     
> org 
> .apache 
> .openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:157)
>     
> org 
> .apache 
> .openejb 
> .client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
>     
> org 
> .apache 
> .openejb 
> .client 
> .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
>    $Proxy2.captureLamp(Unknown Source)
>     
> net 
> .kunye 
> .vds 
> .server 
> .services 
> .configuration 
> .ConfigurationService.service(ConfigurationService.java:73)
>    net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java: 
> 86)
>
> --------- SNIP -----------
>
> After it recovers from the above, all is back to normal.
>
> This is quite serious. How I can get around this, even if I have to
> make some code changes?
>
> Thanks again. I'm so relieved this problem is finally over. Previously
> I've had to do some serious recovery just because a client was left
> running and Glassfish's client library opened so many file descriptors
> for each failure that the server crashed with a No Space Left on
> Device error.
>
> Quintin Beukes
>
Connection Recovery Quintin Beukes <quintin@last.za.net> urn:uuid:%3c1f3854d50911230620i4427658v113d05a7a692e248@mail-gmail-com%3e 2009-11-23T14:20:26Z 
Hey,

One of the big motivations for shifting to OpenEJB 3.1.2 from GF was
the connection recovery built into it. My inquiry was specifically
about failed remote EJB connections because a server restarts or a
network hiccup. We've always had problems with this, especially with
networks running from surface to underground.

This seems to be working. Great job!! Thanks alot. I'm aiming for
complete recovery in the following situations.
1. System exception (any failure on the part of OpenEJB, even if the
cause was my own)
2. Dropped connections due to network
3. Dropped connections from server restart
4. Dropped connections from redeploy (basically the same as (3) I assume).

Though I have a query though. Every time I redeploy, for ex, I have to
manually go and restart all services because it takes very long for
OpenEJB client to notice something is wrong and recover.

Here is an example: If I undeploy, I get something like the following
on a client.

--------- SNIP -----------

javax.ejb.EJBException: Container has suffered a SystemException
    org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:178)
    org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
    org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
    $Proxy2.captureLamp(Unknown Source)
    net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:73)
    net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)

java.rmi.RemoteException: The server has encountered a fatal error: No
such deployment java.rmi.RemoteException: No deployment:
VDS-lamps-ejb-3.0.jar/LampCaptureBean; nested exception is:
	java.rmi.RemoteException: No deployment: VDS-lamps-ejb-3.0.jar/LampCaptureBean
    org.apache.openejb.server.ejbd.EjbRequestHandler.replyWithFatalError(EjbRequestHandler.java:425)
    org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:81)
    org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
    org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:149)
    org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
    org.apache.openejb.server.ejbd.KeepAliveServer$Session.service(KeepAliveServer.java:213)
    org.apache.openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
    org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
    org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
    org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
    java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    java.lang.Thread.run(Thread.java:619)

java.rmi.RemoteException: No deployment: VDS-lamps-ejb-3.0.jar/LampCaptureBean
    org.apache.openejb.server.ejbd.EjbDaemon.getDeployment(EjbDaemon.java:191)
    org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:79)
    org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
    org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:149)
    org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
    org.apache.openejb.server.ejbd.KeepAliveServer$Session.service(KeepAliveServer.java:213)
    org.apache.openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
    org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
    org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
    org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
    java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    java.lang.Thread.run(Thread.java:619)


23 Nov 2009 15:59:20,039 ERROR -- Exception: Service
ConfigurationService failed for instance
ConfigurationService[/10.0.0.25] (java.lang.Exception)
java.lang.Exception: ConfigurationService has an unknown failure while
servicing a request.
    net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:84)
    net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)

javax.ejb.EJBException: Container has suffered a SystemException
    org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:178)
    org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
    org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
    $Proxy2.captureLamp(Unknown Source)
    net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:73)
    net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)

java.rmi.RemoteException: The server has encountered a fatal error: No
such deployment java.rmi.RemoteException: No deployment:
VDS-lamps-ejb-3.0.jar/LampCaptureBean; nested exception is:
	java.rmi.RemoteException: No deployment: VDS-lamps-ejb-3.0.jar/LampCaptureBean
    org.apache.openejb.server.ejbd.EjbRequestHandler.replyWithFatalError(EjbRequestHandler.java:425)
    org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:81)
    org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
    org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:149)
    org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
    org.apache.openejb.server.ejbd.KeepAliveServer$Session.service(KeepAliveServer.java:213)
    org.apache.openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
    org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
    org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
    org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
    java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    java.lang.Thread.run(Thread.java:619)

java.rmi.RemoteException: No deployment: VDS-lamps-ejb-3.0.jar/LampCaptureBean
    org.apache.openejb.server.ejbd.EjbDaemon.getDeployment(EjbDaemon.java:191)
    org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:79)
    org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196)
    org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:149)
    org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
    org.apache.openejb.server.ejbd.KeepAliveServer$Session.service(KeepAliveServer.java:213)
    org.apache.openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
    org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
    org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
    org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
    java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    java.lang.Thread.run(Thread.java:619)

--------- SNIP -----------

Then, for a while, even after the EJB service started up completely
and even though I'm creating new InitialContext instances I get the
following. This isn't too bad, though it does take a few minutes
(between 3 and 5) to recover.

--------- SNIP -----------

23 Nov 2009 16:00:24,802 TRACE -- Received packet [R0010088220000000000000000]
23 Nov 2009 16:00:24,804 ERROR -- Exception: Unknown failure servicing
the request (javax.ejb.EJBException)
javax.ejb.EJBException: Unknown Container Exception:
java.rmi.RemoteException: Received invalid response code from server:
-1
    org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:184)
    org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
    org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
    $Proxy2.captureLamp(Unknown Source)
    net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:73)
    net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)

java.rmi.RemoteException: Received invalid response code from server: -1
    org.apache.openejb.client.EJBObjectHandler.businessMethod(EJBObjectHandler.java:239)
    org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:157)
    org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
    org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
    $Proxy2.captureLamp(Unknown Source)
    net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:73)
    net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)


23 Nov 2009 16:00:24,804 ERROR -- Exception: Service
ConfigurationService failed for instance
ConfigurationService[/10.0.0.25] (java.lang.Exception)
java.lang.Exception: ConfigurationService has an unknown failure while
servicing a request.
    net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:84)
    net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)

javax.ejb.EJBException: Unknown Container Exception:
java.rmi.RemoteException: Received invalid response code from server:
-1
    org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:184)
    org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
    org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
    $Proxy2.captureLamp(Unknown Source)
    net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:73)
    net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)

java.rmi.RemoteException: Received invalid response code from server: -1
    org.apache.openejb.client.EJBObjectHandler.businessMethod(EJBObjectHandler.java:239)
    org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:157)
    org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:117)
    org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:52)
    $Proxy2.captureLamp(Unknown Source)
    net.kunye.vds.server.services.configuration.ConfigurationService.service(ConfigurationService.java:73)
    net.kunye.services.tcp.TCPServiceThread.run(TCPServiceThread.java:86)

--------- SNIP -----------

After it recovers from the above, all is back to normal.

This is quite serious. How I can get around this, even if I have to
make some code changes?

Thanks again. I'm so relieved this problem is finally over. Previously
I've had to do some serious recovery just because a client was left
running and Glassfish's client library opened so many file descriptors
for each failure that the server crashed with a No Space Left on
Device error.

Quintin Beukes
Re: Resolve datasource from the application name David Blevins <david.blevins@visi.com> urn:uuid:%3cC6CE8B32-313B-424A-AA56-07FB679D2C97@visi-com%3e 2009-11-20T21:57:55Z 

On Nov 19, 2009, at 3:46 AM, Luis Fernando Planella Gonzalez wrote:

> I'd love to keep helping on this issue...
> However I have an imminent issue: My daughter will be born on  
> saturday, so
> I'll be off for a week or so.
> Afterwards, we can resume the subject.

Wow!  Congratulations!  A week or so?  Guessing this is not your first  
kid, you sound like a pro!

> Anyway, that algorithm should be used only when neither  
> jtaDataSource nor
> nonJtaDataSource are used, right? At least for what I saw in code,  
> it's
> possible to have only nonJtaDataSource (making a new jta datasource  
> to be
> deployed).

Yeah, I'm not sure.  I'd have to take a look at our current  
"fanciness" and see what makes the most sense.  We'd want this sort of  
"matching loop" to work for resolving any resource ID, so that might  
change how we code it.

> So, my guess would be to make the chunk of code I added to deploy(app,
> persistenceModule) a private method, let's say,  
> locateDataSource(id), which
> would look for a jta data source with that name, then a non-jta,  
> then an
> unespecified.
>
> So, could it be something like:
> * if explicit datasources are used, use them
> * if neither jta-data-source nor non-jta-data-source, try to guess:
> *** try locateDataSource(persitenceUnit.getName())
> *** if not found, try  
> locateDataSource(persistenceModule.getModuleId()) // Is
> it really necessary? As I saw, PersistenceModule.getModuleId() is  
> always null
> *** if not found, for each WebModule try
> locateDataSource(webModule.getContextRoot())


Wasn't referring to the PersistenceModule.getModuleId(), but the  
module in which the persistence unit was found.  *Most* the time the  
persistence.xml is inside an ejb jar or webapp.  We don't retain that  
information when we create the PersistenceModule now, but we could  
maybe link it to the EjbModule or WebModule if it was.  But we can add  
that as a separate step.

Definitely we would want this as some sort of loop of strings to check  
rather than as a bunch of nested if statements.  Then the same logical  
routine could work for resolving any resource ref.  For a plain  
resource ref the list of strings might be something like this:

   1. mappedName
   2. jndi name
   3. variable name
   4. module name
   5. app name

Thinking out loud of course, the code might disagree with me :)  Some  
ideas sound really good and then turn out to be too much work given  
the code.


-David
Re: Resolve datasource from the application name Luis Fernando Planella Gonzalez <lfpg.dev@gmail.com> urn:uuid:%3c200911190946-59980-lfpg-dev@gmail-com%3e 2009-11-19T11:46:59Z 
I'd love to keep helping on this issue...
However I have an imminent issue: My daughter will be born on saturday, so 
I'll be off for a week or so.
Afterwards, we can resume the subject.

Anyway, that algorithm should be used only when neither jtaDataSource nor 
nonJtaDataSource are used, right? At least for what I saw in code, it's 
possible to have only nonJtaDataSource (making a new jta datasource to be 
deployed).

So, my guess would be to make the chunk of code I added to deploy(app, 
persistenceModule) a private method, let's say, locateDataSource(id), which 
would look for a jta data source with that name, then a non-jta, then an 
unespecified.

So, could it be something like:
* if explicit datasources are used, use them
* if neither jta-data-source nor non-jta-data-source, try to guess:
*** try locateDataSource(persitenceUnit.getName())
*** if not found, try locateDataSource(persistenceModule.getModuleId()) // Is 
it really necessary? As I saw, PersistenceModule.getModuleId() is always null
*** if not found, for each WebModule try 
locateDataSource(webModule.getContextRoot())

What do you think?

--
Luis Fernando Planella Gonzalez



Em Quinta-feira 19 Novembro 2009, às 01:20:19, David Blevins escreveu:
> On Nov 16, 2009, at 5:21 AM, Luis Fernando Planella Gonzalez wrote:
> > Well, assuming that my assumptions are right, I've patched AutoConfig
> > to use the first WebModule's root context name as a guess to the
> > DataSource name.
> > I've attached the patch, as well as complete files for AutoConfig and
> > AutoConfigPersistenceUnitsTest in
> > https://issues.apache.org/jira/browse/OPENEJB-1027
> > As this is my first code contribution to OpenEJB. So, please, correct
> > me if I did anything wrong...
> > Feedbacks are appreciated.
> 
> This is a great start, thanks!  I've gone ahead and committed it.
> 
> Would be great to get the other searches in there described in
> OPENEJB-1027 such as linking based on the persistence unit name, etc.
> I'm not sure the code is setup to make this easy now because the
> getResourceId() method is perhaps too aggressive -- it always finds an
> id no matter what -- but but at a high level it seems like something
> like this would be really cool.
> 
>      List<String> strings = new ArrayList<String>();
>      strings.add(jtaDataSourceName);
>      strings.add(persistenceUnitName);
>      strings.add(moduleName);
>      strings.add(applicationName);
> 
>      String resourceId;
> 
>      for (String string : strings) {
>          resourceId = getResourceId(string);
> 
>          if (resourceId != null) break;
>      }
> 
>      // use the resourceId ....
> 
> That's the high level thought at least.  Lot's of ways that could be
> rolled out with the existing code.  Maybe we just change
> getResourceId() so that the 'String resourceId' is actually a var-arg
> and move it to the end of the signature.  Or something.
> 
> Open to ideas.
> 
> And just as a side note, you're under no obligation to keep working on
> this, but you're doing great and we can always use the help! :)
> 
> -David
>
Re: Resolve datasource from the application name David Blevins <david.blevins@visi.com> urn:uuid:%3c7EA0E49C-665D-4276-87A8-7F06F9E52E10@visi-com%3e 2009-11-19T03:20:19Z 

On Nov 16, 2009, at 5:21 AM, Luis Fernando Planella Gonzalez wrote:

> Well, assuming that my assumptions are right, I've patched AutoConfig
> to use the first WebModule's root context name as a guess to the
> DataSource name.
> I've attached the patch, as well as complete files for AutoConfig and
> AutoConfigPersistenceUnitsTest in
> https://issues.apache.org/jira/browse/OPENEJB-1027
> As this is my first code contribution to OpenEJB. So, please, correct
> me if I did anything wrong...
> Feedbacks are appreciated.

This is a great start, thanks!  I've gone ahead and committed it.

Would be great to get the other searches in there described in  
OPENEJB-1027 such as linking based on the persistence unit name, etc.   
I'm not sure the code is setup to make this easy now because the  
getResourceId() method is perhaps too aggressive -- it always finds an  
id no matter what -- but but at a high level it seems like something  
like this would be really cool.

     List<String> strings = new ArrayList<String>();
     strings.add(jtaDataSourceName);
     strings.add(persistenceUnitName);
     strings.add(moduleName);
     strings.add(applicationName);

     String resourceId;

     for (String string : strings) {
         resourceId = getResourceId(string);

         if (resourceId != null) break;
     }

     // use the resourceId ....

That's the high level thought at least.  Lot's of ways that could be  
rolled out with the existing code.  Maybe we just change  
getResourceId() so that the 'String resourceId' is actually a var-arg  
and move it to the end of the signature.  Or something.

Open to ideas.

And just as a side note, you're under no obligation to keep working on  
this, but you're doing great and we can always use the help! :)

-David
Re: svn commit: r881730 - in /openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/util: Logger.java PaxLogStreamFactory.java Jacek Laskowski <jacek@laskowski.net.pl> urn:uuid:%3c1b5bfeb50911181551w54b5c49ag7266f4add632a2a8@mail-gmail-com%3e 2009-11-18T23:51:47Z 
On Wed, Nov 18, 2009 at 12:35 PM,  <rickmcguire@apache.org> wrote:

> -            if (factoryClass != null) {
> +            if (factoryClass == null) {

Hi Rick,

That change was easy to grasp, but...

> Added: openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/util/PaxLogStreamFactory.java

...that one wasn't. How is it used? By whom? When? Please elaborate...

Jacek

-- 
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Re: Further actions for OSGi'fication Jacek Laskowski <jacek@laskowski.net.pl> urn:uuid:%3c1b5bfeb50911170554w43750b06udfdb5351d9ab71a9@mail-gmail-com%3e 2009-11-17T13:54:23Z 
On Thu, Nov 12, 2009 at 8:20 PM, Jay D. McHugh <jay@jnwd.net> wrote:

> Is there an up to date 'jumpstart' for getting OpenEJB running in Karaf?

Sorry for a late response.

There's no docs about OpenEJB on Karaf. I've been playing with bare
Felix and have only been pointed into this direction recently. I hope
to have sth in upcoming days. Ping me if it takes longer :)

Jacek

-- 
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
@ManagedBean support David Blevins <david.blevins@visi.com> urn:uuid:%3c0D52D627-1EEE-4544-B8DF-1071672CA5EC@visi-com%3e 2009-11-17T12:41:22Z 
Been looking at support for the java ee 6 @ManagedBean.  Essentially,  
this is a stateful bean without the ability to have @Remove,  
@TransactionManagement, @RolesAllowed, @ConcurrencyManagement,  
@Schedule, @Asynchronous etc.  But it can use @Resource and related EE  
injection annotations, @PostConstruct/@PreDestroy, and interceptors.   
It's created on lookup or injection just like a Stateful bean and its  
lifecycle is the same.

Creating a container for it would basically entail copying the  
stateful container and making a few additions to the deployment  
system.  Pretty much identical to when we made the singleton container  
which is a copy of the stateless container.

All that is really fairly easy.  The innovative part comes in finding  
clean ways to add back in the @TransactionManagement, @RolesAllowed,  
@ConcurrencyManagement, @Schedule, @Asynchronous etc should a user  
want any of them.  By default they would *not* be there, but we have  
all the code to do those functionalities (except some of the new ejb  
3.1 stuff) and it really is just a matter of finding a clean way to  
design it internally.

-David
Re: openejb as a osgi service? Jean-Louis MONTEIRO <jean-louis.monteiro@atosorigin.com> urn:uuid:%3c26386948-post@talk-nabble-com%3e 2009-11-17T09:43:22Z 

Fully agree. 
We definitely have to make some changes in OpenEJB to make it a fully
OSGi-based solution.

Some days ago, Guillaume pointed me some interesting code.

I have been very busy, but will try to help you as much as possible.

Jean-Louis



Jacek Laskowski wrote:
> 
> On Sat, Nov 14, 2009 at 1:30 AM, Jay D. McHugh <jay@jnwd.net> wrote:
> 
>> So, I was thinking of the JEE container as being a black box that would
>> allow a user to deploy JEE artifacts (EJB jars, WAR files, and EARs)
>> without knowing or caring that the server was internally implemented as
>> a collection of OSGi bundles.
>>
>> In this scenario, the server would need to have an EJB container that
>> would receive a non-OSGi artifact and would then need to make all of the
>> EJBs contained in it injectable (or findable through JNDI).
>>
>> To accomplish this, OpenEJB would then (need to?) be deployed as a
>> bundle that provided the EJB supporting services and a second bundle
>> that created a container utilizing those services.  Is that what you
>> (and others) were thinking?
> 
> Hi Jay et al,
> 
> I was busy with Clojure lately which turned out have made me busy for
> longer than I expected. On to OSGi...
> 
> The approach above is just one way to claim a EJB container is based
> upon OSGi and most application servers (WAS, GlassFish, perhaps JOnAS)
> does exactly this. OSGi serves as a componentization layer and is used
> internally. There's no change from a user's perspective.
> 
> What I thought of to implement in OpenEJB was a different approach. Do
> the above, but let OpenEJB's services be exposed as OSGi services and
> therefore become a truly OSGi-based solution. If a developer wants to
> play according to Java EE rules - appropriate packaging and placing
> libraries in *the* directories - let him/her be with it. What makes me
> more appealing to OSGi is the way OpenEJB should handle hot
> redeployment of dependent libraries without stopping the server
> itself. If OpenEJB let enterprise applications be built with their
> libraries deployed as bundles, it would greatly minimize memory
> requirements and allow end users redeploy them without touching the
> apps themselves. If these enterprise applications were able to
> leverage OpenEJB services *and* OSGi componentization that'd be way
> better. That's my goal for OSGi integration.
> 
> Running an app atop OSGi is simple, just create a single bundle with
> all that's needed and that's it. I'd prefer OpenEJB be built
> dynamically at runtime. You want a SLSB container just install
> appropriate bundle and have fun. If the container is no longer needed
> just uninstall it. No more expensive (=time consuming) restarts or
> redeployments. The same I'd like to see for EJBs deployed onto
> OpenEJB. Their interfaces wouldn't have to be redeployed (provided
> they haven't changed) so they could become a separate bundle (with
> imports) and their implementation become another bundle (set). If it
> needed a change refresh would do the job. Of course, under the covers
> the redeployment would take place, but encouraging our users to
> leverage the OSGi standard and build EJBs in a modular fashion would
> made a huge difference.
> 
> Jacek
> 
> -- 
> Jacek Laskowski
> Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
> 
> 

-- 
View this message in context: http://old.nabble.com/openejb-as-a-osgi-service--tp25992634p26386948.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: openejb as a osgi service? Jacek Laskowski <jacek@laskowski.net.pl> urn:uuid:%3c1b5bfeb50911170117s7f6b09a3pf574ff59fac2b27a@mail-gmail-com%3e 2009-11-17T09:17:29Z 
On Sat, Nov 14, 2009 at 1:30 AM, Jay D. McHugh <jay@jnwd.net> wrote:

> So, I was thinking of the JEE container as being a black box that would
> allow a user to deploy JEE artifacts (EJB jars, WAR files, and EARs)
> without knowing or caring that the server was internally implemented as
> a collection of OSGi bundles.
>
> In this scenario, the server would need to have an EJB container that
> would receive a non-OSGi artifact and would then need to make all of the
> EJBs contained in it injectable (or findable through JNDI).
>
> To accomplish this, OpenEJB would then (need to?) be deployed as a
> bundle that provided the EJB supporting services and a second bundle
> that created a container utilizing those services.  Is that what you
> (and others) were thinking?

Hi Jay et al,

I was busy with Clojure lately which turned out have made me busy for
longer than I expected. On to OSGi...

The approach above is just one way to claim a EJB container is based
upon OSGi and most application servers (WAS, GlassFish, perhaps JOnAS)
does exactly this. OSGi serves as a componentization layer and is used
internally. There's no change from a user's perspective.

What I thought of to implement in OpenEJB was a different approach. Do
the above, but let OpenEJB's services be exposed as OSGi services and
therefore become a truly OSGi-based solution. If a developer wants to
play according to Java EE rules - appropriate packaging and placing
libraries in *the* directories - let him/her be with it. What makes me
more appealing to OSGi is the way OpenEJB should handle hot
redeployment of dependent libraries without stopping the server
itself. If OpenEJB let enterprise applications be built with their
libraries deployed as bundles, it would greatly minimize memory
requirements and allow end users redeploy them without touching the
apps themselves. If these enterprise applications were able to
leverage OpenEJB services *and* OSGi componentization that'd be way
better. That's my goal for OSGi integration.

Running an app atop OSGi is simple, just create a single bundle with
all that's needed and that's it. I'd prefer OpenEJB be built
dynamically at runtime. You want a SLSB container just install
appropriate bundle and have fun. If the container is no longer needed
just uninstall it. No more expensive (=time consuming) restarts or
redeployments. The same I'd like to see for EJBs deployed onto
OpenEJB. Their interfaces wouldn't have to be redeployed (provided
they haven't changed) so they could become a separate bundle (with
imports) and their implementation become another bundle (set). If it
needed a change refresh would do the job. Of course, under the covers
the redeployment would take place, but encouraging our users to
leverage the OSGi standard and build EJBs in a modular fashion would
made a huge difference.

Jacek

-- 
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Re: Resolve datasource from the application name Luis Fernando Planella Gonzalez <lfpg.dev@gmail.com> urn:uuid:%3cd12c1890911160521g2370ba32j4b4aa946aabc871f@mail-gmail-com%3e 2009-11-16T13:21:47Z 
Well, assuming that my assumptions are right, I've patched AutoConfig
to use the first WebModule's root context name as a guess to the
DataSource name.
I've attached the patch, as well as complete files for AutoConfig and
AutoConfigPersistenceUnitsTest in
https://issues.apache.org/jira/browse/OPENEJB-1027
As this is my first code contribution to OpenEJB. So, please, correct
me if I did anything wrong...
Feedbacks are appreciated.
--
Luis Fernando Planella Gonzalez
Re: openejb as a osgi service? "Jay D. McHugh" <jay@jnwd.net> urn:uuid:%3c4AFDFA23-50603@jnwd-net%3e 2009-11-14T00:30:27Z 
I have been trying to think of this in terms of how a JEE application
server that is implemented completely as OSGi bundles would need its EJB
support to be implemented.

So, I was thinking of the JEE container as being a black box that would
allow a user to deploy JEE artifacts (EJB jars, WAR files, and EARs)
without knowing or caring that the server was internally implemented as
a collection of OSGi bundles.

In this scenario, the server would need to have an EJB container that
would receive a non-OSGi artifact and would then need to make all of the
EJBs contained in it injectable (or findable through JNDI).

To accomplish this, OpenEJB would then (need to?) be deployed as a
bundle that provided the EJB supporting services and a second bundle
that created a container utilizing those services.  Is that what you
(and others) were thinking?

Jay

Guillaume Nodet wrote:
> I guess the first question is the goal of this OSGi integration.  Is
> the aim to be JEE compatible while the JEE container is deployed in
> OSGi or is the goal to be OSGi friendly in the standalone mode (no JEE
> container, so no full compatibility) ?
> In the first case, we know what need to be done and just need to find
> the best way to do it, while in the second case, we need to find the
> best integration.  Those might lead to different paths.
> 
> 2009/11/12 Jay D. McHugh <jay@jnwd.net>:
>> Hello all,
>>
>> I have been thinking about what an EJB provider and container should
>> look like in OSGi too.  And here is what I have come up with (please
>> respond with corrections, alternate opinions, and agreement where
>> applicable).
>>
>> Provider issues:
>> First, OpenEJB would need to provide a set of services that would allow
>> for the scanning of a bundle to determine if there are EJBs in it.  I
>> believe Jacek has this or something like it done already.
>>
>> Upon finding EJBs in a bundle, OpenEJB would either need to publish JNDI
>> references to each of the interfaces provided by those EJBs -or- the
>> provider would build and maintain a list of EJBs that are available for
>> inclusion in a container.
>>
>> Container issues:
>> From the container side we would need to figure out how an EJB container
>> is deployed.  Is a container a bundle in itself or could a container be
>> created within a larger bundle (or both)?
>>
>> And then, how are those EJBs injected/looked up once they are available
>> in a container.  If the JNDI is build up when EJB bundles are started in
>> the OSGi container - then how are the beans that are actually in the
>> container differentiated from the 'prototype' JNDI entries?  Or, are the
>> JNDI entries only created when EJBs are included in a container?
>>
>> Lastly, what happens when an EJB is injected or looked up?  Does a proxy
>> get returned so that stopped bundles can be handled somewhat gracefully?
>>   It seems to me that this is what we would need to do.  This would
>> probably overlap with what they have done over in the Tuscany project
>> though.
>>
>> I just remembered that there is an OSGi RFC (142 - which I have not
>> finished reading yet) that deals with the JNDI and probably gives some
>> direction on all of this.
>>
>> So, I've got to get reading - but if anyone has already read the spec,
>> do you have any comments?
>>
>> I have not heard of any spec on how EJB containers should behave in an
>> OSGi environment.  Does anyone else have any thoughts (or access to a
>> spec) on how they should?
>>
>>
>> Jay
>>
>> Jacek Laskowski wrote:
>>> Hi,
>>>
>>> I've lately been wondering about the other pieces for openejb
>>> osgi'fication and am stuck. I'll need your help or I won't do any
>>> further step as thinking has grabbed my free cycles completely.
>>>
>>> OSGi may seem as quite a different technology, but what it does with
>>> our development perspective is to think about classloaders and
>>> services. Everything in OSGi is just about classloaders/services and
>>> its implication to the app.
>>>
>>> There're the openejb bundles, but they're nothing more than just a
>>> collection of classes. If you run a osgi provider and staff it with
>>> these bundles, they're started, but it doesn't mean openejb is started
>>> itself. When a bundle is started, it just means that the
>>> imports/exports are resolved and available. OpenEJB could not be
>>> started yet. It's an activator (an instance of
>>> org.osgi.framework.BundleActivator) that's responsible for doing
>>> what's required to fully start the bundlized application (in our case
>>> - openejb). A bundle gives its classes/interfaces via exports or
>>> services. The exports are to let others compose their classloaders
>>> with necessary classes provided by other bundles. So, once the bundles
>>> are started, the activator kicks in and do the job of starting the
>>> app. That's where I'm stack. I need to create necessary openejb
>>> services (in OSGi terms). Can you point me to the simplest way to boot
>>> openejb? The about-to-be-created OSGi service for OpenEJB is just like
>>> LocalInitialContextFactory that boots openejb when a lookup is fired
>>> and holds a reference to it - exactly what the future osgi service
>>> will do.
>>>
>>> ...after a while...
>>>
>>> After a couple of minutes reading the email of mine over and over
>>> again, I think I'll figure out what I was after. I just need to copy
>>> what's in LocalInitialContextFactory! :) So, here goes another
>>> question - how do I deploy an ejb? A test case would be of much help.
>>> I need a way to get a reference to the just-deployed ejb, so I'll be
>>> able to expose it as a osgi service. It should work, doesn't it?
>>>
>>> Jacek
>>>
> 
> 
>
Re: Resolve datasource from the application name Luis Fernando Planella Gonzalez <lfpg.dev@gmail.com> urn:uuid:%3cd12c1890911130906r4300ed03w2352c1bbc23c8e95@mail-gmail-com%3e 2009-11-13T17:06:40Z 
Well, I'm starting to look at this issue today.

Just a small recap: I'm starting to write a patch to automatically
configure data sources in a persistence unit which match the deployed
web application context name. SO, if I have N instances of the same
app in the same server, all I need to do is setup N data sources, each
with the exact name of the web application context for each instance.

>From my previous post, you've answered the "Where is this heuristic
implemented?" question: in AutoConfig.
But I still need the answer for the second one "How to get the current
application name?".
My first idea would be to pick up the first WebModule in
AppModule.getWebModules() (if any) and invoke it's getContextRoot().
Is this ok? If that is the way to go, I would also have to change the
deploy(PersistenceModule) into deploy(AppModule, PersistenceModule),
so that the web applications may be read.

Am I in the right path?

For now, I'm also creating a new test in AutoConfigPersistenceUnitsTest:
    public void testFromWebApp() throws Exception {

        ResourceInfo jta = addDataSource("OrangeWeb",
OrangeDriver.class, "jdbc:orange-web:some:stuff", null);
        ResourceInfo nonJta = addDataSource("OrangeWebUnmanaged",
OrangeDriver.class, "jdbc:orange-web:some:stuff", null);

        PersistenceUnit persistenceUnit = new PersistenceUnit("orange");

        ClassLoader cl = this.getClass().getClassLoader();
        AppModule app = new AppModule(cl, "orange-app");
        app.getPersistenceModules().add(new PersistenceModule("root",
new Persistence(persistenceUnit)));
        WebApp webApp = new WebApp();
        webApp.setMetadataComplete(true);
        app.getWebModules().add(new WebModule(webApp, "orange-web",
cl, "war", "orange-web"));

        // Create app
        AppInfo appInfo = config.configureApplication(app);
        assembler.createApplication(appInfo);

        // Check results
        PersistenceUnitInfo orangeUnit = appInfo.persistenceUnits.get(0);

        assertEquals(jta.id, orangeUnit.jtaDataSource);
        assertEquals(nonJta.id, orangeUnit.nonJtaDataSource);
    }

--
Luis Fernando Planella Gonzalez
lfpg.dev@gmail.com
Re: openejb as a osgi service? Guillaume Nodet <gnodet@gmail.com> urn:uuid:%3cb23ecedc0911122309j58cbf096rc59b66dc9fc55445@mail-gmail-com%3e 2009-11-13T07:09:00Z 
I guess the first question is the goal of this OSGi integration.  Is
the aim to be JEE compatible while the JEE container is deployed in
OSGi or is the goal to be OSGi friendly in the standalone mode (no JEE
container, so no full compatibility) ?
In the first case, we know what need to be done and just need to find
the best way to do it, while in the second case, we need to find the
best integration.  Those might lead to different paths.

2009/11/12 Jay D. McHugh <jay@jnwd.net>:
> Hello all,
>
> I have been thinking about what an EJB provider and container should
> look like in OSGi too.  And here is what I have come up with (please
> respond with corrections, alternate opinions, and agreement where
> applicable).
>
> Provider issues:
> First, OpenEJB would need to provide a set of services that would allow
> for the scanning of a bundle to determine if there are EJBs in it.  I
> believe Jacek has this or something like it done already.
>
> Upon finding EJBs in a bundle, OpenEJB would either need to publish JNDI
> references to each of the interfaces provided by those EJBs -or- the
> provider would build and maintain a list of EJBs that are available for
> inclusion in a container.
>
> Container issues:
> From the container side we would need to figure out how an EJB container
> is deployed.  Is a container a bundle in itself or could a container be
> created within a larger bundle (or both)?
>
> And then, how are those EJBs injected/looked up once they are available
> in a container.  If the JNDI is build up when EJB bundles are started in
> the OSGi container - then how are the beans that are actually in the
> container differentiated from the 'prototype' JNDI entries?  Or, are the
> JNDI entries only created when EJBs are included in a container?
>
> Lastly, what happens when an EJB is injected or looked up?  Does a proxy
> get returned so that stopped bundles can be handled somewhat gracefully?
>   It seems to me that this is what we would need to do.  This would
> probably overlap with what they have done over in the Tuscany project
> though.
>
> I just remembered that there is an OSGi RFC (142 - which I have not
> finished reading yet) that deals with the JNDI and probably gives some
> direction on all of this.
>
> So, I've got to get reading - but if anyone has already read the spec,
> do you have any comments?
>
> I have not heard of any spec on how EJB containers should behave in an
> OSGi environment.  Does anyone else have any thoughts (or access to a
> spec) on how they should?
>
>
> Jay
>
> Jacek Laskowski wrote:
>> Hi,
>>
>> I've lately been wondering about the other pieces for openejb
>> osgi'fication and am stuck. I'll need your help or I won't do any
>> further step as thinking has grabbed my free cycles completely.
>>
>> OSGi may seem as quite a different technology, but what it does with
>> our development perspective is to think about classloaders and
>> services. Everything in OSGi is just about classloaders/services and
>> its implication to the app.
>>
>> There're the openejb bundles, but they're nothing more than just a
>> collection of classes. If you run a osgi provider and staff it with
>> these bundles, they're started, but it doesn't mean openejb is started
>> itself. When a bundle is started, it just means that the
>> imports/exports are resolved and available. OpenEJB could not be
>> started yet. It's an activator (an instance of
>> org.osgi.framework.BundleActivator) that's responsible for doing
>> what's required to fully start the bundlized application (in our case
>> - openejb). A bundle gives its classes/interfaces via exports or
>> services. The exports are to let others compose their classloaders
>> with necessary classes provided by other bundles. So, once the bundles
>> are started, the activator kicks in and do the job of starting the
>> app. That's where I'm stack. I need to create necessary openejb
>> services (in OSGi terms). Can you point me to the simplest way to boot
>> openejb? The about-to-be-created OSGi service for OpenEJB is just like
>> LocalInitialContextFactory that boots openejb when a lookup is fired
>> and holds a reference to it - exactly what the future osgi service
>> will do.
>>
>> ...after a while...
>>
>> After a couple of minutes reading the email of mine over and over
>> again, I think I'll figure out what I was after. I just need to copy
>> what's in LocalInitialContextFactory! :) So, here goes another
>> question - how do I deploy an ejb? A test case would be of much help.
>> I need a way to get a reference to the just-deployed ejb, so I'll be
>> able to expose it as a osgi service. It should work, doesn't it?
>>
>> Jacek
>>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: openejb as a osgi service? "Jay D. McHugh" <jay@jnwd.net> urn:uuid:%3c4AFC6E30-7010408@jnwd-net%3e 2009-11-12T20:21:04Z 
Hello all,

I have been thinking about what an EJB provider and container should
look like in OSGi too.  And here is what I have come up with (please
respond with corrections, alternate opinions, and agreement where
applicable).

Provider issues:
First, OpenEJB would need to provide a set of services that would allow
for the scanning of a bundle to determine if there are EJBs in it.  I
believe Jacek has this or something like it done already.

Upon finding EJBs in a bundle, OpenEJB would either need to publish JNDI
references to each of the interfaces provided by those EJBs -or- the
provider would build and maintain a list of EJBs that are available for
inclusion in a container.

Container issues:
>From the container side we would need to figure out how an EJB container
is deployed.  Is a container a bundle in itself or could a container be
created within a larger bundle (or both)?

And then, how are those EJBs injected/looked up once they are available
in a container.  If the JNDI is build up when EJB bundles are started in
the OSGi container - then how are the beans that are actually in the
container differentiated from the 'prototype' JNDI entries?  Or, are the
JNDI entries only created when EJBs are included in a container?

Lastly, what happens when an EJB is injected or looked up?  Does a proxy
get returned so that stopped bundles can be handled somewhat gracefully?
   It seems to me that this is what we would need to do.  This would
probably overlap with what they have done over in the Tuscany project
though.

I just remembered that there is an OSGi RFC (142 - which I have not
finished reading yet) that deals with the JNDI and probably gives some
direction on all of this.

So, I've got to get reading - but if anyone has already read the spec,
do you have any comments?

I have not heard of any spec on how EJB containers should behave in an
OSGi environment.  Does anyone else have any thoughts (or access to a
spec) on how they should?


Jay

Jacek Laskowski wrote:
> Hi,
> 
> I've lately been wondering about the other pieces for openejb
> osgi'fication and am stuck. I'll need your help or I won't do any
> further step as thinking has grabbed my free cycles completely.
> 
> OSGi may seem as quite a different technology, but what it does with
> our development perspective is to think about classloaders and
> services. Everything in OSGi is just about classloaders/services and
> its implication to the app.
> 
> There're the openejb bundles, but they're nothing more than just a
> collection of classes. If you run a osgi provider and staff it with
> these bundles, they're started, but it doesn't mean openejb is started
> itself. When a bundle is started, it just means that the
> imports/exports are resolved and available. OpenEJB could not be
> started yet. It's an activator (an instance of
> org.osgi.framework.BundleActivator) that's responsible for doing
> what's required to fully start the bundlized application (in our case
> - openejb). A bundle gives its classes/interfaces via exports or
> services. The exports are to let others compose their classloaders
> with necessary classes provided by other bundles. So, once the bundles
> are started, the activator kicks in and do the job of starting the
> app. That's where I'm stack. I need to create necessary openejb
> services (in OSGi terms). Can you point me to the simplest way to boot
> openejb? The about-to-be-created OSGi service for OpenEJB is just like
> LocalInitialContextFactory that boots openejb when a lookup is fired
> and holds a reference to it - exactly what the future osgi service
> will do.
> 
> ...after a while...
> 
> After a couple of minutes reading the email of mine over and over
> again, I think I'll figure out what I was after. I just need to copy
> what's in LocalInitialContextFactory! :) So, here goes another
> question - how do I deploy an ejb? A test case would be of much help.
> I need a way to get a reference to the just-deployed ejb, so I'll be
> able to expose it as a osgi service. It should work, doesn't it?
> 
> Jacek
>
Re: openejb as a osgi service? "Jay D. McHugh" <jay@jnwd.net> urn:uuid:%3c4AFC62D2-8000806@jnwd-net%3e 2009-11-12T19:32:34Z 
Jacek,

Have you seen the JNDI bundles provided by Aries?

I have avoided the implementation OpenEJB up until now and for the most
part, I have used injection to get bean instances (rather than looking
them up).  But, it seems like we should be able to use what they
developed there rather than having to develop it here.

But like I said - this is the (hopeful) opinion who does not have any of
the facts.

Jay

Jacek Laskowski wrote:
> On Wed, Oct 21, 2009 at 4:26 PM, Quintin Beukes <quintin@skywalk.co.za> wrote:
> 
>> Hope it helps.
> 
> Yes, it did, but I had a vague idea of what I should have been doing
> and didn't pay much attention to these classes.
> 
> I've just committed a working activator to boot up openejb to
> https://svn.apache.org/repos/asf/openejb/trunk/sandbox/openejb-osgi.
> 
> The necessary bundles are as follows:
> 
> -> ps
> START LEVEL 1
>    ID   State         Level  Name
> [   0] [Active     ] [    0] System Bundle (2.0.0)
> [   1] [Active     ] [    1] Apache Felix Bundle Repository (1.4.1)
> [   2] [Active     ] [    1] Apache Felix Shell Service (1.4.0)
> [   3] [Active     ] [    1] Apache Felix Shell TUI (1.4.0)
> [   7] [Active     ] [    1] Apache OpenEJB :: Container :: Java EE
> (3.1.2.SNAPSHOT)
> [   8] [Active     ] [    1] file:/C:/.m2/wsdl4j/wsdl4j/1.6.1/wsdl4j-1.6.1.jar
> [   9] [Active     ] [    1] Apache XBean :: Naming (3.6.0.SNAPSHOT)
> [  14] [Active     ] [    1] Apache XBean :: ASM shaded (repackaged)
> (3.7.0.SNAPSHOT)
> [  15] [Active     ] [    1] Apache XBean :: Reflect (3.6.0.SNAPSHOT)
> [  23] [Active     ] [    1] Apache OpenEJB :: Container :: Loader
> (3.1.2.SNAPSHOT)
> [  25] [Active     ] [    1] OPS4J Pax Url - wrap: (0.3.2)
> [  26] [Active     ] [    1] Apache Felix Configuration Admin Service (1.2.4)
> [  27] [Active     ] [    1]
> wrap_http___repo1.maven.org_maven2_wsdl4j_wsdl4j_1.6.2_wsdl4j-1.6.2.jar
> (0)
> [  30] [Active     ] [    1]
> wrap_file__C__.m2_commons-cli_commons-cli_1.1_commons-cli-1.1.jar (0)
> [  33] [Active     ] [    1]
> wrap_file__C__.m2_log4j_log4j_1.2.12_log4j-1.2.12.jar (0)
> [  34] [Active     ] [    1] openejb-api (3.1.2.SNAPSHOT)
> [  35] [Active     ] [    1] Apache OpenEJB :: Container :: Java Agent
> (3.1.2.SNAPSHOT)
> [  36] [Active     ] [    1] Apache XBean :: Finder shaded
> (repackaged) (3.7.0.SNAPSHOT)
> [  37] [Active     ] [    1] Apache OpenEJB :: Container :: Core
> (3.1.2.SNAPSHOT)
> [  57] [Active     ] [    1] Ejb_stateless (1.0.0)
> [  58] [Active     ] [    1] Ejb_deployer (1.0.0)
> [  62] [Active     ] [    1] Apache OpenEJB :: Container :: Core ::
> OSGi (3.1.2.SNAPSHOT)
> [  64] [Active     ] [    1] Apache ServiceMix Features :: Transaction
> (4.0.0.m1)
> [  65] [Active     ] [    1] Jencks (2.2)
> [  66] [Active     ] [    1] geronimo-jms_1.1_spec (1.1.1)
> [  67] [Active     ] [    1] geronimo-j2ee-connector_1.5_spec (2.0.0)
> [  68] [Active     ] [    1] geronimo-servlet_2.5_spec (1.2)
> [  69] [Active     ] [    1]
> wrap_http___repo2.maven.org_maven2_commons-logging_commons-logging_1.1.1_commons-logging-1.1.1.jar
> (0)
> [  71] [Active     ] [    1] OPS4J Pax Logging - API (1.4)
> [  73] [Active     ] [    1] Geronimo TxManager :: Connector (2.1.3)
> [  74] [Active     ] [    1] Geronimo TxManager :: Transaction (2.1.3)
> [  75] [Active     ] [    1] Spring AOP (2.5.6.SEC01)
> [  76] [Active     ] [    1] Spring Beans (2.5.6.SEC01)
> [  77] [Active     ] [    1] Spring Context (2.5.6.SEC01)
> [  78] [Active     ] [    1] Spring Transaction (2.5.6.SEC01)
> [  79] [Active     ] [    1] geronimo-annotation_1.0_spec (1.1.1)
> [  80] [Active     ] [    1] geronimo-ejb_3.0_spec (1.0.1)
> [  81] [Active     ] [    1] geronimo-interceptor_3.0_spec (1.0.1)
> [  82] [Active     ] [    1] geronimo-javamail_1.4_spec (1.6)
> [  83] [Active     ] [    1] geronimo-j2ee-management_1.1_spec (1.0.1)
> [  84] [Active     ] [    1] geronimo-jpa_3.0_spec (1.1.1)
> [  85] [Active     ] [    1] J2EE JACC 1.1 (1.0.2)
> [  86] [Active     ] [    1] geronimo-jta_1.1_spec (1.1.1)
> [  87] [Active     ] [    1] OPS4J Pax Logging - Service (1.4)
> [  90] [Active     ] [    1] Apache Commons Pool (1.4.0)
> [  95] [Active     ] [    1] Commons DBCP (1.3.0.r699049)
> [  99] [Active     ] [    1]
> wrap_http___repo2.maven.org_maven2_org_apache_activemq_activemq-ra_4.1.1_activemq-ra-4.1.1.jar
> (0)
> [ 100] [Active     ] [    1]
> wrap_http___repo2.maven.org_maven2_org_apache_activemq_activemq-core_4.1.1_activemq-core-4.1.1.jar
> (0)
> [ 101] [Active     ] [    1]
> wrap_http___repo1.maven.org_maven2_backport-util-concurrent_backport-util-concurrent_3.1_backport-util-concurrent-3.1.jar
> (0)
> 
> I'll need to give it a try again and filter out what's unnecessary
> (perhaps 1-2 bundles only).
> 
> The output upon openejb startup is as follows:
> 
> Activator started
> DEBUG: org/apache/openejb/util/resources/Messages_pl.properties
> DEBUG: org/apache/openejb/util/resources/Messages_pl_PL.properties
> Apache OpenEJB ${pom.version}    build:
> @DATE-REPLACED-BY-MAVEN@-@TIME-REPLACED-BY-MAVEN@
> http://openejb.apache.org/
> DEBUG: org/apache/openejb/util/Messages.properties
> DEBUG: org/apache/openejb/util/Messages_pl.properties
> DEBUG: org/apache/openejb/util/Messages_pl_PL.properties
> DEBUG: org/apache/openejb/Messages.properties
> DEBUG: org/apache/openejb/Messages_pl.properties
> DEBUG: org/apache/openejb/Messages_pl_PL.properties
> DEBUG: org/apache/openejb/assembler/classic/Messages_pl.properties
> DEBUG: org/apache/openejb/assembler/classic/Messages_pl_PL.properties
> DEBUG: org/apache/openejb/config/Messages_pl.properties
> DEBUG: org/apache/openejb/config/Messages_pl_PL.properties
> DEBUG: META-INF/services/javax.xml.parsers.SAXParserFactory
> DEBUG: org/apache/openejb/config/sys/jaxb.properties
> DEBUG: META-INF/services/javax.xml.bind.JAXBContext
> DEBUG: META-INF/services/javax.xml.datatype.DatatypeFactory
> DEBUG: META-INF/services/javax.xml.datatype.DatatypeFactory
> DEBUG: META-INF/services/javax.xml.datatype.DatatypeFactory
> DEBUG: META-INF/services/javax.xml.parsers.SAXParserFactory
> DEBUG: META-INF/services/org/apache/activemq/broker/broker
> [org.apache.activemq.broker.BrokerService] : ActiveMQ 4.1.1 JMS
> Message Broker (localhost) is starting
> [org.apache.activemq.broker.BrokerService] : For help or more
> information please see: http://incubator.apache.org/activemq/
> DEBUG: META-INF/services/org/apache/activemq/transport/tcp
> DEBUG: META-INF/services/org/apache/activemq/wireformat/default
> [org.apache.activemq.transport.TransportServerThreadSupport] :
> Listening for connections at: tcp://work:61616
> [org.apache.activemq.broker.TransportConnector] : Connector
> tcp://work:61616 Started
> [org.apache.activemq.broker.BrokerService] : ActiveMQ JMS Message
> Broker (localhost, ID:work-3337-1256173063703-0:0) started
> ...A bundle has been started: org.apache.openejb.core-osgi
> 
> I'm going to work on a osgi'fied client JNDI lookup now that will
> require a openejb service. Then deployment and it should be ready for
> polishing.
> 
> Jacek
>
Re: Further actions for OSGi'fication "Jay D. McHugh" <jay@jnwd.net> urn:uuid:%3c4AFC5FF9-9@jnwd-net%3e 2009-11-12T19:20:25Z 
Hello all,

I would like to help out with this if I am able.

Is there an up to date 'jumpstart' for getting OpenEJB running in Karaf?

Thanks,

Jay

Jacek Laskowski wrote:
> Hi,
> 
> I have given much thought of what's necessary to be able to deploy an
> ejb to openejb as osgi-based ejb container and access it from another
> osgi bundle (a ejb client) and here is what I came up with.
> 
> We need a bundle - let's call it openejb-osgi-deployer - that will
> listen to starting events so when an ejb (regular ejb jar file with
> some manifest changes + META-INF/ejb-jar.xml) is started (aka
> deployed) it will get noticed. The o-o-deployer will do what's
> necessary from openejb's PoV and register OSGi services for each ejb
> bean - both, the remote and local interface. That's the server's part.
> 
>>>From the client's PoV we'll need another JNDI initial context factory
> - possibly in a openejb-osgi-client bundle - so instead of booting up
> openejb (local initialcontext) or connecting to a port (remote
> initialcontext) it will look up necessary interfaces in OSGi Service
> Registry. All beans will get registered in the registry during
> deployment via o-o-deployer as described earlier.
> 
> I'm doing a first prototype and am wondering where I should place the
> interim work. I'm not going to touch any part of the codebase so it
> ought to be as little disruptive to what we've got so far as possible
> (if at all visible). I've been wondering if I should create a osgi
> directory where the bundles will have their maven projects or pick
> another directory?
> 
> I'm going to create a series of JIRA tasks so we can track the
> progress of the openejb osgification.
> 
> Comments?
> 
> Jacek
>
Re: Propagating extra context information in remote EJB calls David Blevins <david.blevins@visi.com> urn:uuid:%3c3A59F45D-9DD0-4D8E-BD12-283EF0FC59CD@visi-com%3e 2009-11-10T18:27:32Z 

On Nov 10, 2009, at 7:36 AM, Jack Cai wrote:

> Are you suggesting that I shall write a servlet to
> receive the client call and then forward to the openejb server?

Right, exactly.  On the client side you'd point to the servlet address.

The servlet could be added to an existing webapp for now.  For the  
long term it would be really great to have a servlet like the one I  
posted as a standard part of the Geronimo integration.

This is the one we use in the Tomcat integration:

  http://svn.apache.org/repos/asf/openejb/trunk/openejb3/server/openejb-http/src/main/java/org/apache/openejb/server/httpd/ServerServlet.java

It doesn't do anything with the HTTP headers yet, but it could.

-David
Re: Propagating extra context information in remote EJB calls Jack Cai <greensight@gmail.com> urn:uuid:%3c5e7fd1eb0911100736rbd647c3j6cf418b5c268168b@mail-gmail-com%3e 2009-11-10T15:36:56Z 
Since I'm using the OpenEJB that comes with Geronimo, which port shall I
connect to if http protocol is used? Still 4201 where the EJB daemon is
listening? I did try setting the url to something like "http://hostname:4201"
but didn't work out. Are you suggesting that I shall write a servlet to
receive the client call and then forward to the openejb server?

-Jack


On Sat, Nov 7, 2009 at 4:17 AM, David Blevins <david.blevins@visi.com>wrote:

> On Oct 29, 2009, at 1:16 AM, Jack Cai wrote:
>
>  I want to propagate some context information in remote EJB calls, and
>> hopefully this can be done transparently, i.e., does not require code
>> change
>> to existing applications. Is this possible?
>>
>> I understand transaction and security context are already being propagated
>> as part of an EJB container impl. Can I just inject the extra data into
>> the
>> security context for example to do the trick?
>>
>> Appreciate some insight in this area!
>>
>
> The idea that comes to mind is modifying the HttpConnectionFactory to in
> some way set headers into the HttpURLConnection.  In the 3.1.x codebase it's
> actually possible to replace the HttpConnectionFactory on an existing
> client:
>
>
> http://mail-archives.apache.org/mod_mbox/openejb-users/200911.mbox/%3CB003CC7A-74F0-4E88-AB61-F8C7A80F7F3B@visi.com%3E
>
> On the server side if there was a Servlet like this:
>
>  import org.apache.openejb.loader.SystemInstance;
>  import org.apache.openejb.server.ServiceException;
>  import org.apache.openejb.server.ejbd.EjbServer;
>
>  import javax.servlet.ServletConfig;
>  import javax.servlet.ServletException;
>  import javax.servlet.ServletInputStream;
>  import javax.servlet.ServletOutputStream;
>  import javax.servlet.http.HttpServlet;
>  import javax.servlet.http.HttpServletRequest;
>  import javax.servlet.http.HttpServletResponse;
>  import java.io.IOException;
>
>  public class ServerServlet extends HttpServlet {
>      private EjbServer ejbServer;
>
>      public void init(ServletConfig config) {
>          ejbServer = SystemInstance.get().getComponent(EjbServer.class);
>      }
>
>      protected void service(HttpServletRequest request, HttpServletResponse
> response) throws ServletException, IOException {
>          ServletInputStream in = request.getInputStream();
>          ServletOutputStream out = response.getOutputStream();
>          try {
>              ejbServer.service(in, out);
>          } catch (ServiceException e) {
>              throw new ServletException("ServerService error: " +
> ejbServer.getClass().getName() + " -- " + e.getMessage(), e);
>          }
>      }
>  }
>
>
> You could get the headers and put them on a ThreadLocal or something.
>
> If the state is going to be the same on a per connection basis, then we can
> maybe make some standard way to put the headers in the connection URI and
> pull them out of that "params" map we create.
>
> We'd need some more creativity to make it really nice and easy for people.
>  But this is a rough approach to get the ideas started.
>
> -David
>
>
>
>
>
>
>
Re: Propagating extra context information in remote EJB calls Jack Cai <greensight@gmail.com> urn:uuid:%3c5e7fd1eb0911100721u77d3bf9j2fc4b8117337da03@mail-gmail-com%3e 2009-11-10T15:21:04Z 
Thanks David! I did try CORBA interceptors and it works well with RMI/IIOP
calls, exactly what I want. Unfortunately OpenEJB does not use the IIOP
library that comes with JDK, so intercepting IIOP calls cannot intercept
remote OpenEJB calls.

What I want to propagate is actually a simple ID string.

-Jack

On Fri, Nov 6, 2009 at 10:43 AM, David Jencks <david_jencks@yahoo.com>wrote:

> AFAIK openejb does not propagate transaction context.  I thought about it
> for corba a long time ago but I have never found anyone who actually wants
> distributed transactions so never made the time to implement it.
>
> With Corba I believe you can add client and server interceptors and tack
> whatever info you want onto the request, but I found it a difficult
> programming model to understand.
>
> What context information do you want to transmit?
>
> thanks
> david jencks
>
>
> On Oct 29, 2009, at 4:15 AM, Jacek Laskowski wrote:
>
>  On Thu, Oct 29, 2009 at 10:16 AM, Jack Cai <greensight@gmail.com> wrote:
>>
>>  1. At the client side, intercept the client call before it's sent out,
>>> and
>>> attach some extra context information with the call;
>>> 2. At the server side, intercept the business method call before the
>>> method
>>> is actually executed, so that I can retrieve the extra context
>>> information
>>> coming with the call and set it into the server thread's context.
>>>
>>> I need to transparently do this for all EJBs. I was hoping I could do the
>>> trick only once in the code, instead of having to take care of all EJBs
>>> (e.g., use AOP to specify to intecept each invidiual remote interface).
>>>
>>> So in a word, I guess this is pretty much the same as how
>>> transaction/security context gets propagated today. Does this make more
>>> sense now?
>>>
>>
>> Nope :] I still don't know what exactly you'd like to add to a call.
>> Yet, you're right that OpenEJB adds some additional data for security
>> and tx mgmt, but I don't think it was exposed for public consumption.
>>
>> Jacek
>>
>> --
>> Jacek Laskowski
>> Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
>>
>
>
Re: Maven Quickstart Archetypes Jonathan Gallimore <jonathan.gallimore@gmail.com> urn:uuid:%3c8a884a800911080403p2ddefd56k3ca5dc969dca220c@mail-gmail-com%3e 2009-11-08T12:03:49Z 
Hi Quintin,

I think my quickstart archetype will do everything you're after - it's
gives you a sample ejb and test using the embedded container with all
the dependencies.

If you give it a go, I'd love to know how you get on and if there's
anything else you'd like to see in there - I'd quite like to get it
working with your new test runner.


Jon

On Saturday, November 7, 2009, Quintin Beukes <quintin@skywalk.co.za> wrote:
> Hey,
>
> A generic archetypes for only OpenEJB would be really useful. Just one for
> an OpenEJB embedded client - where you get a sample EJB, the dependencies
> and a unit test that loads up the embedded container. Many times i find
> myself just wanting to create a quick project for trying/testing something.
> Such an archetype would save a lot of time.
>
> I've never done this, so the source code in quickstart.zip. Does that
> contain everything I would need to make such an archetype?
>
> Quintin Beukes
>
>
> On Fri, Nov 6, 2009 at 2:09 AM, Jonathan Gallimore <
> jonathan.gallimore@gmail.com> wrote:
>
>> Hi All,
>>
>> I don't know if anyone will find this useful, but I've been playing around
>> a
>> bit with Maven Archetypes, and I created a couple of quickstart archetypes
>> for OpenEJB. One creates a simple EJB project, complete with a simple
>> stateless bean, a unit test, includes all the necessary dependencies and
>> will add the right Eclipse WTP configuration to work with the OpenEJB
>> Eclipse Plugin. The other does the same for a complete EAR project. The
>> latter still needs a bit of work (and I'd quite like to add the functional
>> testing stuff I wrote about here:
>>
>> http://openejb.apache.org/functional-testing-with-openejb-jetty-and-selenium.html
>> )
>> but I thought I'd post them up in case anyone had any comments.
>>
>> Currently I've deployed a mini-repository on my website with the necessary
>> stuff, and you can generate a project by doing the following:
>>
>> $ mvn -DarchetypeCatalog=http://jrg.me.uk/repository/-DarchetypeRepository=
>> http://jrg.me.uk/repository/ archetype:generate (the trailing / on the URL
>> is necessary for some reason)
>>
>> [INFO] Scanning for projects...
>> [INFO] Searching repository for plugin with prefix: 'archetype'.
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Building Maven Default Project
>> [INFO]    task-segment: [archetype:generate] (aggregator-style)
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Preparing archetype:generate
>> [INFO] No goals needed for project - skipping
>> [INFO] Setting property: classpath.resource.loader.class =>
>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
>> [INFO] Setting property: velocimacro.messages.on => 'false'.
>> [INFO] Setting property: resource.loader => 'classpath'.
>> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
>> [INFO] [archetype:generate]
>> [INFO] Generating project in Interactive mode
>> [INFO] No archetype defined. Using maven-archetype-quickstart
>> (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
>> Choose archetype:
>> 1: http://jrg.me.uk/repository/ -> maven-openejb-quickstart
>> (maven-openejb-quickstart)
>> 2: http://jrg.me.uk/repository/ -> maven-openejb-quickstart-ear
>> (maven-openejb-quickstart-ear)
>> Choose a number:  (1/2):
>>
>> Once you've followed the wizard, you should be able to cd to the newly
>> created project, and run:
>>
>> $ mvn install eclipse:eclipse
>>
>> This should compile everything, run the tests and create an Eclipse project
>> ready to be imported to your workspace.
>>
>> I've put some source code up here: http://jrg.me.uk/assets/quickstart.zip-
>> I'm more than happy to check it into SVN if anyone thinks its useful. Any
>> comments will be gratefully received.
>>
>> Cheers,
>>
>> Jon
>>
>
Re: More fine grained undeploy (Fwd: Override Porvider property via system properties) Quintin Beukes <quintin@skywalk.co.za> urn:uuid:%3c1f3854d50911070407n6a3730f1o5e8c056bd1279fa7@mail-gmail-com%3e 2009-11-07T12:07:51Z 
That does explain something I've been experiencing. I've been meaning to
investigate it, as I thought it was a bug :>

Quintin Beukes


On Wed, Nov 4, 2009 at 1:59 AM, David Blevins <david.blevins@visi.com>wrote:

> Just a side note if someone is looking for something to work on.
>
> When an application fails to deploy, we don't really know how much work
> we've done in the assembler.creatApplication phase, so as a result we try
> and undo everything.  That of course results in a lot of exceptions saying
> that we couldn't cleanly undeploy the application.  Notice how many items
> are in the undeploy exception before we finally get to the real exception
> which is this:
>
> ERROR - Application could not be deployed:  classpath.ear
> org.apache.openejb.OpenEJBException: Creating application failed:
> classpath.ear: java.lang.ClassNotFoundException:
> org.hibernate.ejb.HibernatePersistence:
> org.hibernate.ejb.HibernatePersistence
>   at
>
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:666)
>   at
>
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:449)
>   at
>
> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>   at
> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
>
>
> We could do something simple and put an object on the thread in the
> createApplication method that records the steps we've taken; maybe stuff it
> full of enum values -- or even better, just remember the last enum value as
> there is an order to them and we could assume all previous steps were done.
>  Then in destroyApplication we can check for it and use it to only know how
> far to go in our destroy logic.
>
> Added a JIRA for it:  https://issues.apache.org/jira/browse/OPENEJB-1101
>
>
> -David
>
>
> Begin forwarded message:
>
>  Resent-From: <dblevins@visi.com>
>> From: El Arbi Aboussoror <aboussoror@gmail.com>
>> Date: November 3, 2009 1:55:18 PM PST
>> To: users@openejb.apache.org
>> Subject: Re: Override Porvider property via system properties
>> Reply-To: users@openejb.apache.org
>>
>> I've 2 decriptors: persistence.xml and test.persistence.xml
>> In the first one the provider is set as follow:
>>   <persistence-unit name="educaPU">
>>       <provider>org.hibernate.ejb.HibernatePersistence</provider>
>> And in the 2nd one:
>>   <persistence-unit name="educaPU">
>>   <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
>>
>> In the jndi.properties I put:
>> openejb.altdd.prefix=test
>> openejb.deployments.classpath.filter.descriptors=true
>> openejb.deployments.classpath.include=.*/Educa-serveur/build/classes/
>> openejb.deployments.classpath.exclude=.*
>> openejb.jndiname.format = {ejbName}/{interfaceType.annotationName}
>> openejb.descriptors.output = true
>> openejb.validation.output.level = verbose
>>
>>
>> And this is the result (It doesn't work):
>>
>> DEBUG - Using default 'openejb.nobanner=true'
>> Apache OpenEJB 3.1.2    build: 20091010-03:11
>> http://openejb.apache.org/
>> INFO - openejb.home = G:\data\eclipse\workspace_0\Educa-serveur-test
>> INFO - openejb.base = G:\data\eclipse\workspace_0\Educa-serveur-test
>> DEBUG - Using default
>> 'openejb.assembler=org.apache.openejb.assembler.classic.Assembler'
>> DEBUG - Instantiating assembler class
>> org.apache.openejb.assembler.classic.Assembler
>> DEBUG - Using default 'openejb.jndiname.failoncollision=true'
>> DEBUG - Using default
>> 'openejb.configurator=org.apache.openejb.config.ConfigurationFactory'
>> DEBUG - Using default 'openejb.validation.skip=false'
>> DEBUG - Using default 'openejb.deploymentId.format={ejbName}'
>> DEBUG - Using default 'openejb.debuggable-vm-hackery=false'
>> DEBUG - Using default 'openejb.webservices.enabled=true'
>> DEBUG - Using default 'openejb.vendor.config=ALL'  Possible values are:
>> geronimo, glassfish, jboss, weblogic or NONE or ALL
>> DEBUG - Using default
>> 'openejb.provider.default=org.apache.openejb.embedded'
>> INFO - Configuring Service(id=Default Security Service,
>> type=SecurityService, provider-id=Default Security Service)
>> INFO - Configuring Service(id=Default Transaction Manager,
>> type=TransactionManager, provider-id=Default Transaction Manager)
>> INFO - Configuring Service(id=educaDatabase, type=Resource,
>> provider-id=Default JDBC Database)
>> DEBUG - Override [Password=<hidden>]
>> DEBUG - Override [JdbcUrl=jdbc:oracle:thin:@localhost:1521:xe]
>> DEBUG - Override [UserName=system]
>> DEBUG - Override [JdbcDriver=oracle.jdbc.OracleDriver]
>> DEBUG - Using default 'openejb.deployments.classpath=true'
>> INFO - Using
>> 'openejb.deployments.classpath.include=.*/Educa-serveur/build/classes/'
>> INFO - Using 'openejb.deployments.classpath.exclude=.*'
>> DEBUG - Using default
>> 'openejb.deployments.classpath.require.descriptor=false'
>> INFO - Using 'openejb.deployments.classpath.filter.descriptors=true'
>> DEBUG - Using default
>> 'openejb.deployments.classpath.filter.systemapps=true'
>> DEBUG - Inspecting classpath for applications: 1 urls.
>> INFO - Found EjbModule in classpath:
>> G:\data\eclipse\workspace_0\Educa-serveur\build\classes
>> DEBUG - URLs after filtering: 10
>> DEBUG - Annotations path:
>> file:/G:/data/eclipse/workspace_0/Educa-serveur/build/classes/
>> DEBUG - Searched 1 classpath urls in 35 milliseconds.  Average 35
>> milliseconds per url.
>> DEBUG - Using default 'openejb.deployments.classpath.ear=true'
>> INFO - Beginning load:
>> G:\data\eclipse\workspace_0\Educa-serveur\build\classes
>> DEBUG - Using default 'openejb.tempclassloader.skip=none'  Possible values
>> are: none, annotations, enums or NONE or ALL
>> DEBUG - Using default 'openejb.tempclassloader.skip=none'  Possible values
>> are: none, annotations, enums or NONE or ALL
>> INFO - Configuring enterprise application: classpath.ear
>> DEBUG - No ejb-jar.xml found assuming annotated beans present:
>> classpath.ear, module: classes
>> DEBUG - Searching for inherited application exceptions (see OPENEJB-980) -
>> it doesn't care whether inherited is true/false
>> DEBUG - ...handling class ma.orca.educa.exception.ValidationException
>> DEBUG - ...adding class ma.orca.educa.exception.ValidationException with
>> rollback=true
>> INFO - Configuring Service(id=Default Stateless Container, type=Container,
>> provider-id=Default Stateless Container)
>> INFO - Auto-creating a container for bean AnnuaireSA:
>> Container(type=STATELESS, id=Default Stateless Container)
>> INFO - Configuring PersistenceUnit(name=educaPU,
>> provider=org.hibernate.ejb.HibernatePersistence)
>> DEBUG - raw <jta-data-source>java:/OracleDS</jta-datasource>
>> DEBUG - raw <non-jta-data-source>null</non-jta-datasource>
>> DEBUG - normalized <jta-data-source>java:/OracleDS</jta-datasource>
>> DEBUG - normalized <non-jta-data-source>null</non-jta-datasource>
>> DEBUG - Available DataSources
>> DEBUG - DataSource(name=educaDatabase, JtaManaged=true)
>> INFO - Auto-creating a Resource with id 'educaDatabaseNonJta' of type
>> 'DataSource for 'educaPU'.
>> INFO - Configuring Service(id=educaDatabaseNonJta, type=Resource,
>> provider-id=educaDatabase)
>> INFO - Adjusting PersistenceUnit educaPU <jta-data-source> to Resource ID
>> 'educaDatabase' from 'java:/OracleDS'
>> INFO - Adjusting PersistenceUnit educaPU <non-jta-data-source> to Resource
>> ID 'educaDatabaseNonJta' from 'null'
>> INFO - Using 'openejb.descriptors.output=true'
>> INFO - Using 'openejb.descriptors.output=true'
>> INFO - Dumping Generated ejb-jar.xml to:
>>
>> C:\Users\ELARBI~1\AppData\Local\Temp\ejb-jar-5983584300064536573classes.xml
>> INFO - Dumping Generated openejb-jar.xml to:
>>
>> C:\Users\ELARBI~1\AppData\Local\Temp\openejb-jar-3542212472572389109classes.xml
>> DEBUG - Adding persistence-unit educaPU property
>>
>> eclipselink.target-database=org.eclipse.persistence.platform.database.oracle.OraclePlatform
>> DEBUG - Adding persistence-unit educaPU property
>> non-jta-data-source=educaDatabase
>> DEBUG - Adding persistence-unit educaPU property
>> jta-data-source=educaDatabase
>> DEBUG - Adding persistence-unit educaPU property
>> eclipselink.ddl-generation=drop-and-create-tables
>> DEBUG - Adding persistence-unit educaPU property
>>
>> eclipselink.application-location=G:/data/eclipse/workspace_0/Educa-serveur-test/scriptDB
>> DEBUG - Adding persistence-unit educaPU property
>> eclipselink.ddl-generation.output-mode=both
>> DEBUG - Adjusting PersistenceUnit(name=educaPU) property to
>>
>> hibernate.transaction.manager_lookup_class=org.apache.openejb.hibernate.TransactionManagerLookup
>> INFO - Using 'openejb.validation.output.level=VERBOSE'
>> INFO - Enterprise application "classpath.ear" loaded.
>> INFO - Assembling app: classpath.ear
>> DEBUG - Using default 'openejb.tempclassloader.skip=none'  Possible values
>> are: none, annotations, enums or NONE or ALL
>> INFO - Undeploying app: classpath.ear
>> DEBUG - App failing deployment may not have undeployed cleanly:
>> classpath.ear
>> org.apache.openejb.UndeployException: Failed undeploying application:
>> id=classpath.ear
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.destroyApplication(Assembler.java:802)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:662)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:449)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>   at
>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
>>   at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>   at java.lang.reflect.Method.invoke(Unknown Source)
>>   at
>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
>>   at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>>   at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>   at javax.naming.InitialContext.init(Unknown Source)
>>   at javax.naming.InitialContext.<init>(Unknown Source)
>>   at
>>
>> ma.orca.educa.service.crud.configuration.ConfigurationCRUDTest.setUp(ConfigurationCRUDTest.java:21)
>>   at junit.framework.TestCase.runBare(TestCase.java:128)
>>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>>   at junit.framework.TestResult.run(TestResult.java:109)
>>   at junit.framework.TestCase.run(TestCase.java:120)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>> Nested caused by:
>> java.lang.Exception: deployment not found: AnnuaireSA
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:662)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:449)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>   at
>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
>>   at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>   at java.lang.reflect.Method.invoke(Unknown Source)
>>   at
>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
>>   at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>>   at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>   at javax.naming.InitialContext.init(Unknown Source)
>>   at javax.naming.InitialContext.<init>(Unknown Source)
>>   at
>>
>> ma.orca.educa.service.crud.configuration.ConfigurationCRUDTest.setUp(ConfigurationCRUDTest.java:21)
>>   at junit.framework.TestCase.runBare(TestCase.java:128)
>>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>>   at junit.framework.TestResult.run(TestResult.java:109)
>>   at junit.framework.TestCase.run(TestCase.java:120)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>> Nested caused by:
>> java.lang.Exception: deployment not found: InsriptionSA
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:662)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:449)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>   at
>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
>>   at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>   at java.lang.reflect.Method.invoke(Unknown Source)
>>   at
>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
>>   at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>>   at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>   at javax.naming.InitialContext.init(Unknown Source)
>>   at javax.naming.InitialContext.<init>(Unknown Source)
>>   at
>>
>> ma.orca.educa.service.crud.configuration.ConfigurationCRUDTest.setUp(ConfigurationCRUDTest.java:21)
>>   at junit.framework.TestCase.runBare(TestCase.java:128)
>>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>>   at junit.framework.TestResult.run(TestResult.java:109)
>>   at junit.framework.TestCase.run(TestCase.java:120)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>> Nested caused by:
>> java.lang.Exception: deployment not found: ConfigurationCRUD
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:662)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:449)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>   at
>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
>>   at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>   at java.lang.reflect.Method.invoke(Unknown Source)
>>   at
>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
>>   at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>>   at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>   at javax.naming.InitialContext.init(Unknown Source)
>>   at javax.naming.InitialContext.<init>(Unknown Source)
>>   at
>>
>> ma.orca.educa.service.crud.configuration.ConfigurationCRUDTest.setUp(ConfigurationCRUDTest.java:21)
>>   at junit.framework.TestCase.runBare(TestCase.java:128)
>>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>>   at junit.framework.TestResult.run(TestResult.java:109)
>>   at junit.framework.TestCase.run(TestCase.java:120)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>> Nested caused by:
>> java.lang.Exception: deployment not found: AnnuaireCRUD
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:662)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:449)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>   at
>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
>>   at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>   at java.lang.reflect.Method.invoke(Unknown Source)
>>   at
>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
>>   at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>>   at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>   at javax.naming.InitialContext.init(Unknown Source)
>>   at javax.naming.InitialContext.<init>(Unknown Source)
>>   at
>>
>> ma.orca.educa.service.crud.configuration.ConfigurationCRUDTest.setUp(ConfigurationCRUDTest.java:21)
>>   at junit.framework.TestCase.runBare(TestCase.java:128)
>>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>>   at junit.framework.TestResult.run(TestResult.java:109)
>>   at junit.framework.TestCase.run(TestCase.java:120)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>> Nested caused by:
>> java.lang.Exception: deployment not found: RessourceCRUD
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:662)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:449)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>   at
>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
>>   at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>   at java.lang.reflect.Method.invoke(Unknown Source)
>>   at
>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
>>   at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>>   at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>   at javax.naming.InitialContext.init(Unknown Source)
>>   at javax.naming.InitialContext.<init>(Unknown Source)
>>   at
>>
>> ma.orca.educa.service.crud.configuration.ConfigurationCRUDTest.setUp(ConfigurationCRUDTest.java:21)
>>   at junit.framework.TestCase.runBare(TestCase.java:128)
>>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>>   at junit.framework.TestResult.run(TestResult.java:109)
>>   at junit.framework.TestCase.run(TestCase.java:120)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>> Nested caused by:
>> java.lang.Exception: deployment not found: FiliereCRUD
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:662)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:449)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>   at
>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
>>   at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>   at java.lang.reflect.Method.invoke(Unknown Source)
>>   at
>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
>>   at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>>   at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>   at javax.naming.InitialContext.init(Unknown Source)
>>   at javax.naming.InitialContext.<init>(Unknown Source)
>>   at
>>
>> ma.orca.educa.service.crud.configuration.ConfigurationCRUDTest.setUp(ConfigurationCRUDTest.java:21)
>>   at junit.framework.TestCase.runBare(TestCase.java:128)
>>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>>   at junit.framework.TestResult.run(TestResult.java:109)
>>   at junit.framework.TestCase.run(TestCase.java:120)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>> Nested caused by:
>> java.lang.Exception: deployment not found: GroupeCRUD
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:662)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:449)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>   at
>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
>>   at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>   at java.lang.reflect.Method.invoke(Unknown Source)
>>   at
>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
>>   at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>>   at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>   at javax.naming.InitialContext.init(Unknown Source)
>>   at javax.naming.InitialContext.<init>(Unknown Source)
>>   at
>>
>> ma.orca.educa.service.crud.configuration.ConfigurationCRUDTest.setUp(ConfigurationCRUDTest.java:21)
>>   at junit.framework.TestCase.runBare(TestCase.java:128)
>>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>>   at junit.framework.TestResult.run(TestResult.java:109)
>>   at junit.framework.TestCase.run(TestCase.java:120)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>> Nested caused by:
>> java.lang.Exception: deployment not found: NiveauCRUD
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:662)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:449)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>   at
>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
>>   at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>   at java.lang.reflect.Method.invoke(Unknown Source)
>>   at
>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
>>   at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>>   at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>   at javax.naming.InitialContext.init(Unknown Source)
>>   at javax.naming.InitialContext.<init>(Unknown Source)
>>   at
>>
>> ma.orca.educa.service.crud.configuration.ConfigurationCRUDTest.setUp(ConfigurationCRUDTest.java:21)
>>   at junit.framework.TestCase.runBare(TestCase.java:128)
>>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>>   at junit.framework.TestResult.run(TestResult.java:109)
>>   at junit.framework.TestCase.run(TestCase.java:120)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>> Nested caused by:
>> java.lang.Exception: deployment not found: PieceCRUD
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:662)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:449)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>   at
>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
>>   at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>   at java.lang.reflect.Method.invoke(Unknown Source)
>>   at
>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
>>   at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>>   at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>   at javax.naming.InitialContext.init(Unknown Source)
>>   at javax.naming.InitialContext.<init>(Unknown Source)
>>   at
>>
>> ma.orca.educa.service.crud.configuration.ConfigurationCRUDTest.setUp(ConfigurationCRUDTest.java:21)
>>   at junit.framework.TestCase.runBare(TestCase.java:128)
>>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>>   at junit.framework.TestResult.run(TestResult.java:109)
>>   at junit.framework.TestCase.run(TestCase.java:120)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>> Nested caused by:
>> java.lang.Exception: deployment not found: PieceJustificativeCRUD
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:662)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:449)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>   at
>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
>>   at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>   at java.lang.reflect.Method.invoke(Unknown Source)
>>   at
>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
>>   at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>>   at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>   at javax.naming.InitialContext.init(Unknown Source)
>>   at javax.naming.InitialContext.<init>(Unknown Source)
>>   at
>>
>> ma.orca.educa.service.crud.configuration.ConfigurationCRUDTest.setUp(ConfigurationCRUDTest.java:21)
>>   at junit.framework.TestCase.runBare(TestCase.java:128)
>>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>>   at junit.framework.TestResult.run(TestResult.java:109)
>>   at junit.framework.TestCase.run(TestCase.java:120)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>> Nested caused by:
>> java.lang.Exception: deployment not found: SpecialiteCRUD
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:662)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:449)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>   at
>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
>>   at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>   at java.lang.reflect.Method.invoke(Unknown Source)
>>   at
>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
>>   at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>>   at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>   at javax.naming.InitialContext.init(Unknown Source)
>>   at javax.naming.InitialContext.<init>(Unknown Source)
>>   at
>>
>> ma.orca.educa.service.crud.configuration.ConfigurationCRUDTest.setUp(ConfigurationCRUDTest.java:21)
>>   at junit.framework.TestCase.runBare(TestCase.java:128)
>>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>>   at junit.framework.TestResult.run(TestResult.java:109)
>>   at junit.framework.TestCase.run(TestCase.java:120)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>> Nested caused by:
>> java.lang.Exception: deployment not found: DocumentAdministratifSF
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:662)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:449)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>   at
>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
>>   at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>   at java.lang.reflect.Method.invoke(Unknown Source)
>>   at
>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
>>   at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>>   at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>   at javax.naming.InitialContext.init(Unknown Source)
>>   at javax.naming.InitialContext.<init>(Unknown Source)
>>   at
>>
>> ma.orca.educa.service.crud.configuration.ConfigurationCRUDTest.setUp(ConfigurationCRUDTest.java:21)
>>   at junit.framework.TestCase.runBare(TestCase.java:128)
>>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>>   at junit.framework.TestResult.run(TestResult.java:109)
>>   at junit.framework.TestCase.run(TestCase.java:120)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>> Nested caused by:
>> java.lang.Exception: deployment not found: InscriptionSF
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:662)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:449)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>   at
>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
>>   at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>   at java.lang.reflect.Method.invoke(Unknown Source)
>>   at
>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
>>   at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>>   at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>   at javax.naming.InitialContext.init(Unknown Source)
>>   at javax.naming.InitialContext.<init>(Unknown Source)
>>   at
>>
>> ma.orca.educa.service.crud.configuration.ConfigurationCRUDTest.setUp(ConfigurationCRUDTest.java:21)
>>   at junit.framework.TestCase.runBare(TestCase.java:128)
>>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>>   at junit.framework.TestResult.run(TestResult.java:109)
>>   at junit.framework.TestCase.run(TestCase.java:120)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>> Nested caused by:
>> java.lang.Exception: persistence-unit: educaPU 495723823: Name
>> "openejb/PersistenceUnit/educaPU 495723823" not found.
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.destroyApplication(Assembler.java:893)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:662)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:449)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>   at
>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
>>   at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>   at java.lang.reflect.Method.invoke(Unknown Source)
>>   at
>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
>>   at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>>   at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>   at javax.naming.InitialContext.init(Unknown Source)
>>   at javax.naming.InitialContext.<init>(Unknown Source)
>>   at
>>
>> ma.orca.educa.service.crud.configuration.ConfigurationCRUDTest.setUp(ConfigurationCRUDTest.java:21)
>>   at junit.framework.TestCase.runBare(TestCase.java:128)
>>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>>   at junit.framework.TestResult.run(TestResult.java:109)
>>   at junit.framework.TestCase.run(TestCase.java:120)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>> Caused by: javax.naming.NameNotFoundException: Name
>> "openejb/PersistenceUnit/educaPU 495723823" not found.
>>   at
>>
>> org.apache.openejb.core.ivm.naming.IvmContext.federate(IvmContext.java:193)
>>   at
>> org.apache.openejb.core.ivm.naming.IvmContext.lookup(IvmContext.java:150)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.destroyApplication(Assembler.java:886)
>>   ... 37 more
>> ERROR - Application could not be deployed:  classpath.ear
>> org.apache.openejb.OpenEJBException: Creating application failed:
>> classpath.ear: java.lang.ClassNotFoundException:
>> org.hibernate.ejb.HibernatePersistence:
>> org.hibernate.ejb.HibernatePersistence
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:666)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:449)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>   at
>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
>>   at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>   at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>   at java.lang.reflect.Method.invoke(Unknown Source)
>>   at
>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>   at
>>
>> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
>>   at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>>   at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>   at javax.naming.InitialContext.init(Unknown Source)
>>   at javax.naming.InitialContext.<init>(Unknown Source)
>>   at
>>
>> ma.orca.educa.service.crud.configuration.ConfigurationCRUDTest.setUp(ConfigurationCRUDTest.java:21)
>>   at junit.framework.TestCase.runBare(TestCase.java:128)
>>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>>   at junit.framework.TestResult.run(TestResult.java:109)
>>   at junit.framework.TestCase.run(TestCase.java:120)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>   at junit.framework.TestSuite.run(TestSuite.java:225)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>   at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>> Caused by: org.apache.openejb.OpenEJBException:
>> java.lang.ClassNotFoundException: org.hibernate.ejb.HibernatePersistence:
>> org.hibernate.ejb.HibernatePersistence
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:494)
>>   ... 36 more
>> Caused by: java.lang.ClassNotFoundException:
>> org.hibernate.ejb.HibernatePersistence
>>   at java.net.URLClassLoader$1.run(Unknown Source)
>>   at java.security.AccessController.doPrivileged(Native Method)
>>   at java.net.URLClassLoader.findClass(Unknown Source)
>>   at java.lang.ClassLoader.loadClass(Unknown Source)
>>   at java.lang.ClassLoader.loadClass(Unknown Source)
>>   at
>>
>> org.apache.openejb.assembler.classic.PersistenceBuilder.createEntityManagerFactory(PersistenceBuilder.java:178)
>>   at
>>
>> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:489)
>>   ... 36 more
>> DEBUG - Containers        : 1
>> DEBUG - Type        Container ID
>> DEBUG -    STATELESS   Default Stateless Container
>> DEBUG - Deployments       : 0
>> DEBUG - SecurityService   :
>> org.apache.openejb.core.security.SecurityServiceImpl
>> DEBUG - TransactionManager:
>> org.apache.geronimo.transaction.manager.GeronimoTransactionManager
>> DEBUG - OpenEJB Container System ready.
>>
>>
>> 2009/11/3 David Blevins <david.blevins@visi.com>
>>
>>
>>> On Nov 3, 2009, at 10:08 AM, hypnosat7 wrote:
>>>
>>>
>>>  Is it working with the persistence.xml file ?
>>>> I mean if I have a 'test.persistence.xml' file in my test project, will
>>>> this
>>>> file 'override' the persistence.xml in my production project ?
>>>>
>>>>
>>> It *should* for the version you are using (3.1.2).  There was a bug in
>>> 3.1.1 that prevented it from working for persistence.xml files
>>> specifically.
>>>
>>> If it isn't working, post the debug log output and we'll take a look.
>>>
>>> -David
>>>
>>>
>>> David Blevins wrote:
>>>
>>>>
>>>>
>>>>> Don't know if you've gotten passed this yet, but this feature should
>>>>> help with this:
>>>>>
>>>>> http://openejb.apache.org/3.0/alternate-descriptors.html
>>>>>
>>>>> Seems your situation falls into the "catch all" we mention at the top
>>>>> of that page.  The override support is really aimed at just tweaking
>>>>> properties of your provider.  But in your case you want a completely
>>>>> different provider and a completely different set of properties, so
>>>>> the AltDD support is probably best.
>>>>>
>>>>> -David
>>>>>
>>>>> On Oct 23, 2009, at 10:02 AM, hypnosat7 wrote:
>>>>>
>>>>>
>>>>>  Yes I want to use a different provider for tests than I do for
>>>>>> production. In
>>>>>> fact I have this persistence.xml for producation:
>>>>>>
>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>> <persistence version="1.0"
>>>>>>      xmlns="http://java.sun.com/xml/ns/persistence"
>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>>      xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
>>>>>> http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
>>>>>>      <persistence-unit name="educaPU">
>>>>>>              <!--
>>>>>>
>>>>>> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
>>>>>>               -->
>>>>>>
>>>>>> <provider>org.hibernate.ejb.HibernatePersistence</provider>
>>>>>>              <jta-data-source>java:/OracleDS</jta-data-source>
>>>>>>              <properties>
>>>>>>                      <property name="hibernate.hbm2ddl.auto"
>>>>>> value="update" />
>>>>>>                      <property name="hibernate.dialect"
>>>>>> value="org.hibernate.dialect.Oracle10gDialect" />
>>>>>>
>>>>>>              </properties>
>>>>>>      </persistence-unit>
>>>>>> </persistence>
>>>>>>
>>>>>> And to override the Hibernate provider I launch my test from eclipse
>>>>>> with
>>>>>> "Run Configurations ..." and then I specify in the "Program
>>>>>> arguments" text
>>>>>> area :
>>>>>> "-
>>>>>> Djavax
>>>>>> .persistence.provider=org.eclipse.persistence.jpa.PersistenceProvider"
>>>>>>
>>>>>> And this is the error:
>>>>>> DEBUG - Using default 'openejb.nobanner=true'
>>>>>> Apache OpenEJB 3.1.2    build: 20091010-03:11
>>>>>> http://openejb.apache.org/
>>>>>> INFO - openejb.home = G:\data\eclipse\workspace_0\Educa-serveur-test
>>>>>> INFO - openejb.base = G:\data\eclipse\workspace_0\Educa-serveur-test
>>>>>> DEBUG - Using default
>>>>>> 'openejb.assembler=org.apache.openejb.assembler.classic.Assembler'
>>>>>> DEBUG - Instantiating assembler class
>>>>>> org.apache.openejb.assembler.classic.Assembler
>>>>>> DEBUG - Using default 'openejb.jndiname.failoncollision=true'
>>>>>> DEBUG - Using default
>>>>>> 'openejb.configurator=org.apache.openejb.config.ConfigurationFactory'
>>>>>> DEBUG - Using default 'openejb.validation.skip=false'
>>>>>> DEBUG - Using default 'openejb.deploymentId.format={ejbName}'
>>>>>> DEBUG - Using default 'openejb.debuggable-vm-hackery=false'
>>>>>> DEBUG - Using default 'openejb.webservices.enabled=true'
>>>>>> DEBUG - Using default 'openejb.vendor.config=ALL'  Possible values
>>>>>> are:
>>>>>> geronimo, glassfish, jboss, weblogic or NONE or ALL
>>>>>> DEBUG - Using default
>>>>>> 'openejb.provider.default=org.apache.openejb.embedded'
>>>>>> INFO - Configuring Service(id=Default Security Service,
>>>>>> type=SecurityService, provider-id=Default Security Service)
>>>>>> INFO - Configuring Service(id=Default Transaction Manager,
>>>>>> type=TransactionManager, provider-id=Default Transaction Manager)
>>>>>> INFO - Configuring Service(id=educaDatabase, type=Resource,
>>>>>> provider-id=Default JDBC Database)
>>>>>> DEBUG - Override
>>>>>> [JdbcUrl=jdbc:hsqldb:file:G:/database/hsql/hsqldb_1_8_0_10/hsqldb/
>>>>>> data/educadb]
>>>>>> DEBUG - Override [UserName=sa]
>>>>>> DEBUG - Override [JdbcDriver=org.hsqldb.jdbcDriver]
>>>>>> DEBUG - Using default 'openejb.deployments.classpath=true'
>>>>>> DEBUG - Using default 'openejb.deployments.classpath.include='
>>>>>> INFO - Using
>>>>>>
>>>>>>
>>>>>> 'openejb.deployments.classpath.exclude="file:///G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/
>>>>>> jboss-5.1.0.GA/.*
>>>>>> "'
>>>>>> DEBUG - Using default
>>>>>> 'openejb.deployments.classpath.require.descriptor=false'
>>>>>> DEBUG - Using default
>>>>>> 'openejb.deployments.classpath.filter.descriptors=false'
>>>>>> DEBUG - Using default
>>>>>> 'openejb.deployments.classpath.filter.systemapps=true'
>>>>>> WARN - Inspecting classpath for applications: 78 urls.
>>>>>> WARN - ADJUST THE EXCLUDE/INCLUDE!!!.  Current settings:
>>>>>>
>>>>>>
>>>>>> openejb.deployments.classpath.exclude='"file:///G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/
>>>>>> jboss-5.1.0.GA/.*
>>>>>> "',
>>>>>> openejb.deployments.classpath.include=''
>>>>>> INFO - Found EjbModule in classpath:
>>>>>> G:\data\eclipse\workspace_0\Educa-serveur-test\bin
>>>>>> INFO - Found EjbModule in classpath:
>>>>>> G:\data\eclipse\workspace_0\Educa-serveur\build\classes
>>>>>> INFO - Found ClientModule in classpath:
>>>>>> G:\repository\jboss\as\jboss-5.1.0.GA-jdk6\jboss-5.1.0.GA\client
>>>>>> \javassist.jar
>>>>>> INFO - Found ClientModule in classpath:
>>>>>> G:\repository\apache\openejb\openejb-3.1.2\openejb-3.1.2\lib\xml-
>>>>>> resolver-1.2.jar
>>>>>> INFO - Found ClientModule in classpath:
>>>>>> G:\repository\jboss\as\jboss-5.1.0.GA-jdk6\jboss-5.1.0.GA\client
>>>>>> \jboss-serialization.jar
>>>>>> INFO - Found ClientModule in classpath:
>>>>>> G:\repository\jboss\as\jboss-5.1.0.GA-jdk6\jboss-5.1.0.GA\client
>>>>>> \jboss-remoting.jar
>>>>>> INFO - Found ClientModule in classpath:
>>>>>> G:\repository\apache\openejb\openejb-3.1.2\openejb-3.1.2\lib
>>>>>> \serializer-2.7.1.jar
>>>>>> DEBUG - URLs after filtering: 780
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-common-core.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jbosssx-as-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-srp-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-integration.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-mdr.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> file:/G:/data/eclipse/workspace_0/Educa-serveur-test/bin/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/apache/openejb/openejb-3.1.2/openejb-3.1.2/
>>>>>> lib/quartz-1.5.2.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/data/eclipse/eclipse-jee-galileo-win32/eclipse/plugins/
>>>>>> javax.persistence_1.99.0.v200906021518.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-deployers-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> file:/G:/data/eclipse/workspace_0/Educa-serveur/build/classes/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/data/eclipse/eclipse-jee-galileo-win32/eclipse/plugins/
>>>>>> org.eclipse.persistence.asm_1.1.2.v20090612-r4475.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-security-spi.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/slf4j-api.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-aspect-jdk50-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-ejb3-proxy-impl-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/apache/openejb/openejb-3.1.2/openejb-3.1.2/
>>>>>> lib/xbean-finder-shaded-3.6.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-deployers-core-spi.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-system-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-ha-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-ejb3-security-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/apache/openejb/openejb-3.1.2/openejb-3.1.2/
>>>>>> lib/neethi-2.0.4.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/commons-logging.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-logging-spi.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/javassist.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jbosssx-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/hibernate-annotations.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jmx-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jbossall-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-logging-jdk.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> file:/G:/data/eclipse/eclipse-jee-galileo-win32/eclipse/
>>>>>> configuration/org.eclipse.osgi/bundles/329/1/.cp/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-j2se.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-logging-log4j.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-ejb3-proxy-clustered-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-deployment.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/log4j.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-iiop-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/apache/openejb/openejb-3.1.2/openejb-3.1.2/
>>>>>> lib/slf4j-api-1.3.1.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-ejb3-ext-api.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/data/eclipse/eclipse-jee-galileo-win32/eclipse/plugins/
>>>>>> org.eclipse.persistence.jpa_1.1.2.v20090612-r4475.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/data/eclipse/eclipse-jee-galileo-win32/eclipse/plugins/
>>>>>> org.eclipse.persistence.antlr_1.1.2.v20090612-r4475.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/ejb3-persistence.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-ejb3-core-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-appclient.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/apache/openejb/openejb-3.1.2/openejb-3.1.2/
>>>>>> lib/xml-resolver-1.2.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-messaging-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-serialization.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/slf4j-jboss-logging.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jbossjts-integration.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-javaee.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jnp-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jbossjts.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/apache/openejb/openejb-3.1.2/openejb-3.1.2/
>>>>>> lib/commons-dbcp-all-1.3-r699049.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/trove.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-ejb3-proxy-spi-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/apache/openejb/openejb-3.1.2/openejb-3.1.2/
>>>>>> lib/XmlSchema-1.4.2.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-deployers-client-spi.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/apache/openejb/openejb-3.1.2/openejb-3.1.2/
>>>>>> lib/wss4j-1.5.4.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jmx-invoker-adaptor-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-ejb3-common-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/apache/openejb/openejb-3.1.2/openejb-3.1.2/
>>>>>> lib/slf4j-jdk14-1.3.1.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-ha-legacy-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/data/eclipse/eclipse-jee-galileo-win32/eclipse/plugins/
>>>>>> org.junit_3.8.2.v20090203-1005/junit.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/data/eclipse/eclipse-jee-galileo-win32/eclipse/plugins/
>>>>>> org.eclipse.persistence.core_1.1.2.v20090612-r4475.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/apache/openejb/openejb-3.1.2/openejb-3.1.2/
>>>>>> lib/saaj-impl-1.3.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/apache/openejb/openejb-3.1.2/openejb-3.1.2/
>>>>>> lib/opensaml-1.1.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> file:/G:/data/eclipse/eclipse-jee-galileo-win32/eclipse/
>>>>>> configuration/org.eclipse.osgi/bundles/328/1/.cp/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/apache/openejb/openejb-3.1.2/openejb-3.1.2/
>>>>>> lib/bcprov-jdk15-140.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/apache/openejb/openejb-3.1.2/openejb-3.1.2/
>>>>>> lib/xmlsec-1.4.0.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-system-jmx-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-remoting.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-jsr77-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/apache/openejb/openejb-3.1.2/openejb-3.1.2/
>>>>>> lib/xbean-asm-shaded-3.6.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-aop-client.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/apache/openejb/openejb-3.1.2/openejb-3.1.2/
>>>>>> lib/serializer-2.7.1.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jboss-deployers-core.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/xmlsec.jar!/
>>>>>> DEBUG - Annotations path:
>>>>>> jar:file:/G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/jboss-5.1.0.GA/
>>>>>> client/jbosscx-client.jar!/
>>>>>> WARN - Searched 78 classpath urls in 7013 milliseconds.  Average 89
>>>>>> milliseconds per url.
>>>>>> WARN - Consider adjusting your openejb.deployments.classpath.exclude
>>>>>> and
>>>>>> openejb.deployments.classpath.include settings.  Current settings:
>>>>>> exclude='"file:///G:/repository/jboss/as/jboss-5.1.0.GA-jdk6/
>>>>>> jboss-5.1.0.GA/.*
>>>>>> "',
>>>>>> include=''
>>>>>> DEBUG - Using default 'openejb.deployments.classpath.ear=true'
>>>>>> INFO - Beginning load: G:\data\eclipse\workspace_0\Educa-serveur-test
>>>>>> \bin
>>>>>> DEBUG - Using default 'openejb.tempclassloader.skip=none'  Possible
>>>>>> values
>>>>>> are: none, annotations, enums or NONE or ALL
>>>>>> DEBUG - Using default 'openejb.tempclassloader.skip=none'  Possible
>>>>>> values
>>>>>> are: none, annotations, enums or NONE or ALL
>>>>>> INFO - Beginning load:
>>>>>> G:\data\eclipse\workspace_0\Educa-serveur\build\classes
>>>>>> DEBUG - Using default 'openejb.tempclassloader.skip=none'  Possible
>>>>>> values
>>>>>> are: none, annotations, enums or NONE or ALL
>>>>>> DEBUG - Using default 'openejb.tempclassloader.skip=none'  Possible
>>>>>> values
>>>>>> are: none, annotations, enums or NONE or ALL
>>>>>> INFO - Beginning load:
>>>>>> G:\repository\jboss\as\jboss-5.1.0.GA-jdk6\jboss-5.1.0.GA\client
>>>>>> \javassist.jar
>>>>>> DEBUG - Using default 'openejb.tempclassloader.skip=none'  Possible
>>>>>> values
>>>>>> are: none, annotations, enums or NONE or ALL
>>>>>> INFO - Beginning load:
>>>>>> G:\repository\apache\openejb\openejb-3.1.2\openejb-3.1.2\lib\xml-
>>>>>> resolver-1.2.jar
>>>>>> DEBUG - Using default 'openejb.tempclassloader.skip=none'  Possible
>>>>>> values
>>>>>> are: none, annotations, enums or NONE or ALL
>>>>>> INFO - Beginning load:
>>>>>> G:\repository\jboss\as\jboss-5.1.0.GA-jdk6\jboss-5.1.0.GA\client
>>>>>> \jboss-serialization.jar
>>>>>> DEBUG - Using default 'openejb.tempclassloader.skip=none'  Possible
>>>>>> values
>>>>>> are: none, annotations, enums or NONE or ALL
>>>>>> INFO - Beginning load:
>>>>>> G:\repository\jboss\as\jboss-5.1.0.GA-jdk6\jboss-5.1.0.GA\client
>>>>>> \jboss-remoting.jar
>>>>>> DEBUG - Using default 'openejb.tempclassloader.skip=none'  Possible
>>>>>> values
>>>>>> are: none, annotations, enums or NONE or ALL
>>>>>> INFO - Beginning load:
>>>>>> G:\repository\apache\openejb\openejb-3.1.2\openejb-3.1.2\lib
>>>>>> \serializer-2.7.1.jar
>>>>>> DEBUG - Using default 'openejb.tempclassloader.skip=none'  Possible
>>>>>> values
>>>>>> are: none, annotations, enums or NONE or ALL
>>>>>> INFO - Configuring enterprise application: classpath.ear
>>>>>> DEBUG - No ejb-jar.xml found assuming annotated beans present:
>>>>>> classpath.ear, module: classes
>>>>>> DEBUG - No application-client.xml found assuming annotations present:
>>>>>> classpath.ear, module: javassist.jar
>>>>>> DEBUG - No application-client.xml found assuming annotations present:
>>>>>> classpath.ear, module: xml-resolver-1.2.jar
>>>>>> DEBUG - No application-client.xml found assuming annotations present:
>>>>>> classpath.ear, module: jboss-serialization.jar
>>>>>> DEBUG - No application-client.xml found assuming annotations present:
>>>>>> classpath.ear, module: jboss-remoting.jar
>>>>>> DEBUG - No application-client.xml found assuming annotations present:
>>>>>> classpath.ear, module: serializer-2.7.1.jar
>>>>>> DEBUG - Searching for inherited application exceptions (see
>>>>>> OPENEJB-980) -
>>>>>> it doesn't care whether inherited is true/false
>>>>>> DEBUG - Searching for inherited application exceptions (see
>>>>>> OPENEJB-980) -
>>>>>> it doesn't care whether inherited is true/false
>>>>>> DEBUG - ...handling class ma.orca.educa.exception.ValidationException
>>>>>> DEBUG - ...adding class ma.orca.educa.exception.ValidationException
>>>>>> with
>>>>>> rollback=true
>>>>>> INFO - Configuring Service(id=Default Stateless Container,
>>>>>> type=Container,
>>>>>> provider-id=Default Stateless Container)
>>>>>> INFO - Auto-creating a container for bean ConfigurationBean:
>>>>>> Container(type=STATELESS, id=Default Stateless Container)
>>>>>> INFO - Configuring PersistenceUnit(name=Educa-serveur-test)
>>>>>> DEBUG - raw <jta-data-source>null</jta-datasource>
>>>>>> DEBUG - raw <non-jta-data-source>null</non-jta-datasource>
>>>>>> DEBUG - normalized <jta-data-source>null</jta-datasource>
>>>>>> DEBUG - normalized <non-jta-data-source>null</non-jta-datasource>
>>>>>> DEBUG - Available DataSources
>>>>>> DEBUG - DataSource(name=educaDatabase, JtaManaged=true)
>>>>>> INFO - Auto-creating a Resource with id 'educaDatabaseNonJta' of type
>>>>>> 'DataSource for 'Educa-serveur-test'.
>>>>>> INFO - Configuring Service(id=educaDatabaseNonJta, type=Resource,
>>>>>> provider-id=educaDatabase)
>>>>>> INFO - Adjusting PersistenceUnit Educa-serveur-test <jta-data-
>>>>>> source> to
>>>>>> Resource ID 'educaDatabase' from 'null'
>>>>>> INFO - Adjusting PersistenceUnit Educa-serveur-test <non-jta-data-
>>>>>> source> to
>>>>>> Resource ID 'educaDatabaseNonJta' from 'null'
>>>>>> INFO - Configuring PersistenceUnit(name=educaPU,
>>>>>> provider=org.hibernate.ejb.HibernatePersistence)
>>>>>> DEBUG - raw <jta-data-source>java:/OracleDS</jta-datasource>
>>>>>> DEBUG - raw <non-jta-data-source>null</non-jta-datasource>
>>>>>> DEBUG - normalized <jta-data-source>java:/OracleDS</jta-datasource>
>>>>>> DEBUG - normalized <non-jta-data-source>null</non-jta-datasource>
>>>>>> DEBUG - Available DataSources
>>>>>> DEBUG - DataSource(name=educaDatabase, JtaManaged=true)
>>>>>> DEBUG - DataSource(name=educaDatabaseNonJta, JtaManaged=false)
>>>>>> INFO - Adjusting PersistenceUnit educaPU <jta-data-source> to
>>>>>> Resource ID
>>>>>> 'educaDatabase' from 'java:/OracleDS'
>>>>>> INFO - Adjusting PersistenceUnit educaPU <non-jta-data-source> to
>>>>>> Resource
>>>>>> ID 'educaDatabaseNonJta' from 'null'
>>>>>> INFO - Using 'openejb.descriptors.output=true'
>>>>>> INFO - Using 'openejb.descriptors.output=true'
>>>>>> INFO - Dumping Generated ejb-jar.xml to:
>>>>>> C:\Users\ELARBI~1\AppData\Local\Temp\ejb-
>>>>>> jar-4519594178483779556bin.xml
>>>>>> INFO - Dumping Generated openejb-jar.xml to:
>>>>>> C:\Users\ELARBI~1\AppData\Local\Temp\openejb-
>>>>>> jar-2046724989127448680bin.xml
>>>>>> INFO - Using 'openejb.descriptors.output=true'
>>>>>> INFO - Dumping Generated ejb-jar.xml to:
>>>>>> C:\Users\ELARBI~1\AppData\Local\Temp\ejb-
>>>>>> jar-7664296864725927732classes.xml
>>>>>> INFO - Dumping Generated openejb-jar.xml to:
>>>>>> C:\Users\ELARBI~1\AppData\Local\Temp\openejb-
>>>>>> jar-1100372600686023701classes.xml
>>>>>> DEBUG - Adding persistence-unit educaPU property
>>>>>> eclipselink.target-
>>>>>> database=org.eclipse.persistence.platform.database.HSQLPlatform
>>>>>> DEBUG - Adding persistence-unit educaPU property
>>>>>> non-jta-data-source=educaDatabase
>>>>>> DEBUG - Adding persistence-unit educaPU property
>>>>>> jta-data-source=educaDatabase
>>>>>> DEBUG - Adding persistence-unit educaPU property
>>>>>> eclipselink.ddl-generation=drop-and-create-tables
>>>>>> DEBUG - Adding persistence-unit educaPU property
>>>>>> eclipselink.application-location=G:/data/eclipse/workspace_0/Educa-
>>>>>> serveur-test/scriptDB
>>>>>> DEBUG - Adding persistence-unit educaPU property
>>>>>> eclipselink.ddl-generation.output-mode=both
>>>>>> DEBUG - Adjusting PersistenceUnit(name=educaPU) property to
>>>>>> hibernate
>>>>>> .transaction
>>>>>> .manager_lookup_class
>>>>>> =org.apache.openejb.hibernate.TransactionManagerLookup
>>>>>> INFO - Using 'openejb.validation.output.level=VERBOSE'
>>>>>> INFO - Enterprise application "classpath.ear" loaded.
>>>>>> INFO - Assembling app: classpath.ear
>>>>>> DEBUG - Using default 'openejb.tempclassloader.skip=none'  Possible
>>>>>> values
>>>>>> are: none, annotations, enums or NONE or ALL
>>>>>> INFO - PersistenceUnit(name=Educa-serveur-test,
>>>>>> provider=org.apache.openjpa.persistence.PersistenceProviderImpl)
>>>>>> DEBUG - Using default 'openejb.tempclassloader.skip=none'  Possible
>>>>>> values
>>>>>> are: none, annotations, enums or NONE or ALL
>>>>>> ERROR - JAVA AGENT NOT INSTALLED. The JPA Persistence Provider
>>>>>> requested
>>>>>> installation of a ClassFileTransformer which requires a JavaAgent.
>>>>>> See
>>>>>> http://openejb.apache.org/3.0/javaagent.html
>>>>>> INFO - Undeploying app: classpath.ear
>>>>>> DEBUG - App failing deployment may not have undeployed cleanly:
>>>>>> classpath.ear
>>>>>> org.apache.openejb.UndeployException: Failed undeploying application:
>>>>>> id=classpath.ear
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.destroyApplication(Assembler.java:802)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:662)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:449)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>>>>>      at
>>>>>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:
>>>>>> 279)
>>>>>>      at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>>>>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>>>>> Source)
>>>>>>      at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>>      at
>>>>>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:
>>>>>> 36)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory
>>>>>> .getInitialContext(LocalInitialContextFactory.java:42)
>>>>>>      at javax.naming.spi.NamingManager.getInitialContext(Unknown
>>>>>> Source)
>>>>>>      at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>>>>>      at javax.naming.InitialContext.init(Unknown Source)
>>>>>>      at javax.naming.InitialContext.<init>(Unknown Source)
>>>>>>      at
>>>>>> ma.orca.educa.service.RessourceBeanTest.setUp(RessourceBeanTest.java:
>>>>>> 22)
>>>>>>      at junit.framework.TestCase.runBare(TestCase.java:128)
>>>>>>      at junit.framework.TestResult$1.protect(TestResult.java:106)
>>>>>>      at junit.framework.TestResult.runProtected(TestResult.java:124)
>>>>>>      at junit.framework.TestResult.run(TestResult.java:109)
>>>>>>      at junit.framework.TestCase.run(TestCase.java:120)
>>>>>>      at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>>>>      at junit.framework.TestSuite.run(TestSuite.java:225)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit
>>>>>> .runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:
>>>>>> 197)
>>>>>> Nested caused by:
>>>>>> java.lang.Exception: deployment not found: ConfigurationBean
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:662)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:449)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>>>>>      at
>>>>>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:
>>>>>> 279)
>>>>>>      at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>>>>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>>>>> Source)
>>>>>>      at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>>      at
>>>>>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:
>>>>>> 36)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory
>>>>>> .getInitialContext(LocalInitialContextFactory.java:42)
>>>>>>      at javax.naming.spi.NamingManager.getInitialContext(Unknown
>>>>>> Source)
>>>>>>      at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>>>>>      at javax.naming.InitialContext.init(Unknown Source)
>>>>>>      at javax.naming.InitialContext.<init>(Unknown Source)
>>>>>>      at
>>>>>> ma.orca.educa.service.RessourceBeanTest.setUp(RessourceBeanTest.java:
>>>>>> 22)
>>>>>>      at junit.framework.TestCase.runBare(TestCase.java:128)
>>>>>>      at junit.framework.TestResult$1.protect(TestResult.java:106)
>>>>>>      at junit.framework.TestResult.runProtected(TestResult.java:124)
>>>>>>      at junit.framework.TestResult.run(TestResult.java:109)
>>>>>>      at junit.framework.TestCase.run(TestCase.java:120)
>>>>>>      at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>>>>      at junit.framework.TestSuite.run(TestSuite.java:225)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit
>>>>>> .runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:
>>>>>> 197)
>>>>>> Nested caused by:
>>>>>> java.lang.Exception: deployment not found: AnnuaireBean
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:662)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:449)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>>>>>      at
>>>>>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:
>>>>>> 279)
>>>>>>      at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>>>>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>>>>> Source)
>>>>>>      at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>>      at
>>>>>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:
>>>>>> 36)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory
>>>>>> .getInitialContext(LocalInitialContextFactory.java:42)
>>>>>>      at javax.naming.spi.NamingManager.getInitialContext(Unknown
>>>>>> Source)
>>>>>>      at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>>>>>      at javax.naming.InitialContext.init(Unknown Source)
>>>>>>      at javax.naming.InitialContext.<init>(Unknown Source)
>>>>>>      at
>>>>>> ma.orca.educa.service.RessourceBeanTest.setUp(RessourceBeanTest.java:
>>>>>> 22)
>>>>>>      at junit.framework.TestCase.runBare(TestCase.java:128)
>>>>>>      at junit.framework.TestResult$1.protect(TestResult.java:106)
>>>>>>      at junit.framework.TestResult.runProtected(TestResult.java:124)
>>>>>>      at junit.framework.TestResult.run(TestResult.java:109)
>>>>>>      at junit.framework.TestCase.run(TestCase.java:120)
>>>>>>      at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>>>>      at junit.framework.TestSuite.run(TestSuite.java:225)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit
>>>>>> .runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:
>>>>>> 197)
>>>>>> Nested caused by:
>>>>>> java.lang.Exception: deployment not found: RessourceBean
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:662)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:449)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>>>>>      at
>>>>>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:
>>>>>> 279)
>>>>>>      at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>>>>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>>>>> Source)
>>>>>>      at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>>      at
>>>>>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:
>>>>>> 36)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory
>>>>>> .getInitialContext(LocalInitialContextFactory.java:42)
>>>>>>      at javax.naming.spi.NamingManager.getInitialContext(Unknown
>>>>>> Source)
>>>>>>      at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>>>>>      at javax.naming.InitialContext.init(Unknown Source)
>>>>>>      at javax.naming.InitialContext.<init>(Unknown Source)
>>>>>>      at
>>>>>> ma.orca.educa.service.RessourceBeanTest.setUp(RessourceBeanTest.java:
>>>>>> 22)
>>>>>>      at junit.framework.TestCase.runBare(TestCase.java:128)
>>>>>>      at junit.framework.TestResult$1.protect(TestResult.java:106)
>>>>>>      at junit.framework.TestResult.runProtected(TestResult.java:124)
>>>>>>      at junit.framework.TestResult.run(TestResult.java:109)
>>>>>>      at junit.framework.TestCase.run(TestCase.java:120)
>>>>>>      at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>>>>      at junit.framework.TestSuite.run(TestSuite.java:225)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit
>>>>>> .runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:
>>>>>> 197)
>>>>>> Nested caused by:
>>>>>> java.lang.Exception: deployment not found: InscriptionBean
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:662)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:449)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>>>>>      at
>>>>>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:
>>>>>> 279)
>>>>>>      at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>>>>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>>>>> Source)
>>>>>>      at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>>      at
>>>>>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:
>>>>>> 36)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory
>>>>>> .getInitialContext(LocalInitialContextFactory.java:42)
>>>>>>      at javax.naming.spi.NamingManager.getInitialContext(Unknown
>>>>>> Source)
>>>>>>      at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>>>>>      at javax.naming.InitialContext.init(Unknown Source)
>>>>>>      at javax.naming.InitialContext.<init>(Unknown Source)
>>>>>>      at
>>>>>> ma.orca.educa.service.RessourceBeanTest.setUp(RessourceBeanTest.java:
>>>>>> 22)
>>>>>>      at junit.framework.TestCase.runBare(TestCase.java:128)
>>>>>>      at junit.framework.TestResult$1.protect(TestResult.java:106)
>>>>>>      at junit.framework.TestResult.runProtected(TestResult.java:124)
>>>>>>      at junit.framework.TestResult.run(TestResult.java:109)
>>>>>>      at junit.framework.TestCase.run(TestCase.java:120)
>>>>>>      at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>>>>      at junit.framework.TestSuite.run(TestSuite.java:225)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit
>>>>>> .runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:
>>>>>> 197)
>>>>>> Nested caused by:
>>>>>> java.lang.Exception: deployment not found: ScolariteBean
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:662)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:449)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>>>>>      at
>>>>>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:
>>>>>> 279)
>>>>>>      at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>>>>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>>>>> Source)
>>>>>>      at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>>      at
>>>>>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:
>>>>>> 36)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory
>>>>>> .getInitialContext(LocalInitialContextFactory.java:42)
>>>>>>      at javax.naming.spi.NamingManager.getInitialContext(Unknown
>>>>>> Source)
>>>>>>      at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>>>>>      at javax.naming.InitialContext.init(Unknown Source)
>>>>>>      at javax.naming.InitialContext.<init>(Unknown Source)
>>>>>>      at
>>>>>> ma.orca.educa.service.RessourceBeanTest.setUp(RessourceBeanTest.java:
>>>>>> 22)
>>>>>>      at junit.framework.TestCase.runBare(TestCase.java:128)
>>>>>>      at junit.framework.TestResult$1.protect(TestResult.java:106)
>>>>>>      at junit.framework.TestResult.runProtected(TestResult.java:124)
>>>>>>      at junit.framework.TestResult.run(TestResult.java:109)
>>>>>>      at junit.framework.TestCase.run(TestCase.java:120)
>>>>>>      at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>>>>      at junit.framework.TestSuite.run(TestSuite.java:225)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit
>>>>>> .runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:
>>>>>> 197)
>>>>>> Nested caused by:
>>>>>> java.lang.Exception: deployment not found: RessourceWS
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:662)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:449)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>>>>>      at
>>>>>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:
>>>>>> 279)
>>>>>>      at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>>>>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>>>>> Source)
>>>>>>      at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>>      at
>>>>>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:
>>>>>> 36)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory
>>>>>> .getInitialContext(LocalInitialContextFactory.java:42)
>>>>>>      at javax.naming.spi.NamingManager.getInitialContext(Unknown
>>>>>> Source)
>>>>>>      at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>>>>>      at javax.naming.InitialContext.init(Unknown Source)
>>>>>>      at javax.naming.InitialContext.<init>(Unknown Source)
>>>>>>      at
>>>>>> ma.orca.educa.service.RessourceBeanTest.setUp(RessourceBeanTest.java:
>>>>>> 22)
>>>>>>      at junit.framework.TestCase.runBare(TestCase.java:128)
>>>>>>      at junit.framework.TestResult$1.protect(TestResult.java:106)
>>>>>>      at junit.framework.TestResult.runProtected(TestResult.java:124)
>>>>>>      at junit.framework.TestResult.run(TestResult.java:109)
>>>>>>      at junit.framework.TestCase.run(TestCase.java:120)
>>>>>>      at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>>>>      at junit.framework.TestSuite.run(TestSuite.java:225)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit
>>>>>> .runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:
>>>>>> 197)
>>>>>> Nested caused by:
>>>>>> java.lang.Exception: deployment not found: ScolariteWS
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.destroyApplication(Assembler.java:820)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:662)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:449)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>>>>>      at
>>>>>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:
>>>>>> 279)
>>>>>>      at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>>>>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>>>>> Source)
>>>>>>      at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>>      at
>>>>>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:
>>>>>> 36)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory
>>>>>> .getInitialContext(LocalInitialContextFactory.java:42)
>>>>>>      at javax.naming.spi.NamingManager.getInitialContext(Unknown
>>>>>> Source)
>>>>>>      at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>>>>>      at javax.naming.InitialContext.init(Unknown Source)
>>>>>>      at javax.naming.InitialContext.<init>(Unknown Source)
>>>>>>      at
>>>>>> ma.orca.educa.service.RessourceBeanTest.setUp(RessourceBeanTest.java:
>>>>>> 22)
>>>>>>      at junit.framework.TestCase.runBare(TestCase.java:128)
>>>>>>      at junit.framework.TestResult$1.protect(TestResult.java:106)
>>>>>>      at junit.framework.TestResult.runProtected(TestResult.java:124)
>>>>>>      at junit.framework.TestResult.run(TestResult.java:109)
>>>>>>      at junit.framework.TestCase.run(TestCase.java:120)
>>>>>>      at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>>>>      at junit.framework.TestSuite.run(TestSuite.java:225)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit
>>>>>> .runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:
>>>>>> 197)
>>>>>> Nested caused by:
>>>>>> java.lang.Exception: persistence-unit: educaPU 495723823: Name
>>>>>> "openejb/PersistenceUnit/educaPU 495723823" not found.
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.destroyApplication(Assembler.java:893)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:662)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:449)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>>>>>      at
>>>>>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:
>>>>>> 279)
>>>>>>      at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>>>>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>>>>> Source)
>>>>>>      at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>>      at
>>>>>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:
>>>>>> 36)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory
>>>>>> .getInitialContext(LocalInitialContextFactory.java:42)
>>>>>>      at javax.naming.spi.NamingManager.getInitialContext(Unknown
>>>>>> Source)
>>>>>>      at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>>>>>      at javax.naming.InitialContext.init(Unknown Source)
>>>>>>      at javax.naming.InitialContext.<init>(Unknown Source)
>>>>>>      at
>>>>>> ma.orca.educa.service.RessourceBeanTest.setUp(RessourceBeanTest.java:
>>>>>> 22)
>>>>>>      at junit.framework.TestCase.runBare(TestCase.java:128)
>>>>>>      at junit.framework.TestResult$1.protect(TestResult.java:106)
>>>>>>      at junit.framework.TestResult.runProtected(TestResult.java:124)
>>>>>>      at junit.framework.TestResult.run(TestResult.java:109)
>>>>>>      at junit.framework.TestCase.run(TestCase.java:120)
>>>>>>      at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>>>>      at junit.framework.TestSuite.run(TestSuite.java:225)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit
>>>>>> .runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:
>>>>>> 197)
>>>>>> Caused by: javax.naming.NameNotFoundException: Name
>>>>>> "openejb/PersistenceUnit/educaPU 495723823" not found.
>>>>>>      at
>>>>>> org
>>>>>> .apache.openejb.core.ivm.naming.IvmContext.federate(IvmContext.java:
>>>>>> 193)
>>>>>>      at
>>>>>> org.apache.openejb.core.ivm.naming.IvmContext.lookup(IvmContext.java:
>>>>>> 150)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.destroyApplication(Assembler.java:886)
>>>>>>      ... 33 more
>>>>>> ERROR - Application could not be deployed:  classpath.ear
>>>>>> org.apache.openejb.OpenEJBException: Creating application failed:
>>>>>> classpath.ear: java.lang.ClassNotFoundException:
>>>>>> org.hibernate.ejb.HibernatePersistence:
>>>>>> org.hibernate.ejb.HibernatePersistence
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:666)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:449)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.buildContainerSystem(Assembler.java:367)
>>>>>>      at
>>>>>> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:
>>>>>> 279)
>>>>>>      at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
>>>>>>      at org.apache.openejb.OpenEJB.init(OpenEJB.java:265)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>>>>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>>>>> Source)
>>>>>>      at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>>      at
>>>>>> org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:
>>>>>> 36)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .client
>>>>>> .LocalInitialContextFactory
>>>>>> .getInitialContext(LocalInitialContextFactory.java:42)
>>>>>>      at javax.naming.spi.NamingManager.getInitialContext(Unknown
>>>>>> Source)
>>>>>>      at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>>>>>      at javax.naming.InitialContext.init(Unknown Source)
>>>>>>      at javax.naming.InitialContext.<init>(Unknown Source)
>>>>>>      at
>>>>>> ma.orca.educa.service.RessourceBeanTest.setUp(RessourceBeanTest.java:
>>>>>> 22)
>>>>>>      at junit.framework.TestCase.runBare(TestCase.java:128)
>>>>>>      at junit.framework.TestResult$1.protect(TestResult.java:106)
>>>>>>      at junit.framework.TestResult.runProtected(TestResult.java:124)
>>>>>>      at junit.framework.TestResult.run(TestResult.java:109)
>>>>>>      at junit.framework.TestCase.run(TestCase.java:120)
>>>>>>      at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>>>>      at junit.framework.TestSuite.run(TestSuite.java:225)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit
>>>>>> .runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal
>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>>>>>      at
>>>>>> org
>>>>>> .eclipse
>>>>>> .jdt
>>>>>> .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:
>>>>>> 197)
>>>>>> Caused by: org.apache.openejb.OpenEJBException:
>>>>>> java.lang.ClassNotFoundException:
>>>>>> org.hibernate.ejb.HibernatePersistence:
>>>>>> org.hibernate.ejb.HibernatePersistence
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:494)
>>>>>>      ... 32 more
>>>>>> Caused by: java.lang.ClassNotFoundException:
>>>>>> org.hibernate.ejb.HibernatePersistence
>>>>>>      at java.net.URLClassLoader$1.run(Unknown Source)
>>>>>>      at java.security.AccessController.doPrivileged(Native Method)
>>>>>>      at java.net.URLClassLoader.findClass(Unknown Source)
>>>>>>      at java.lang.ClassLoader.loadClass(Unknown Source)
>>>>>>      at java.lang.ClassLoader.loadClass(Unknown Source)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler
>>>>>> .classic
>>>>>> .PersistenceBuilder
>>>>>> .createEntityManagerFactory(PersistenceBuilder.java:178)
>>>>>>      at
>>>>>> org
>>>>>> .apache
>>>>>> .openejb
>>>>>> .assembler.classic.Assembler.createApplication(Assembler.java:489)
>>>>>>      ... 32 more
>>>>>> DEBUG - Containers        : 1
>>>>>> DEBUG - Type        Container ID
>>>>>> DEBUG -    STATELESS   Default Stateless Container
>>>>>> DEBUG - Deployments       : 0
>>>>>> DEBUG - SecurityService   :
>>>>>> org.apache.openejb.core.security.SecurityServiceImpl
>>>>>> DEBUG - TransactionManager:
>>>>>> org.apache.geronimo.transaction.manager.GeronimoTransactionManager
>>>>>> DEBUG - OpenEJB Container System ready.
>>>>>>
>>>>>>
>>>>>> Quintin Beukes-2 wrote:
>>>>>>
>>>>>>
>>>>>>> Can you please paste the error you receive?
>>>>>>>
>>>>>>> I'm not sure how to override it, will have a look now. Though, what
>>>>>>> are you trying to achieve with this? Maybe there is another way to
>>>>>>> get
>>>>>>> the same thing. I assume you're just trying to use a different
>>>>>>> provider for tests than you do for production?
>>>>>>>
>>>>>>> Quintin Beukes
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 23, 2009 at 7:50 AM, hypnosat7 <ablarbi@yahoo.fr> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> If I set the provider property in the persistence.xml of my EJB
>>>>>>>> project
>>>>>>>> in
>>>>>>>> works. But if I set the provider via system properties (to
>>>>>>>> override the
>>>>>>>> persistence.xml) my tests fail and the reason is that the data are
>>>>>>>> not
>>>>>>>> stored to the database.
>>>>>>>>
>>>>>>>> So this is my persistence.xml:
>>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>>> <persistence version="1.0"
>>>>>>>> xmlns="http://java.sun.com/xml/ns/persistence"
>>>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>>>> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
>>>>>>>> http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
>>>>>>>> <persistence-unit name="educaPU">
>>>>>>>>    <!--
>>>>>>>>    <provider>org.hibernate.ejb.HibernatePersistence</provider>
>>>>>>>>     -->
>>>>>>>>
>>>>>>>> <provider>org.eclipse.persistence.jpa.PersistenceProvider</
>>>>>>>> provider>
>>>>>>>>    <jta-data-source>java:/OracleDS</jta-data-source>
>>>>>>>>    <properties>
>>>>>>>>        <property name="hibernate.hbm2ddl.auto" value="update" />
>>>>>>>>        <property name="hibernate.dialect"
>>>>>>>> value="org.hibernate.dialect.Oracle10gDialect" />
>>>>>>>>        <!--
>>>>>>>>            MySQL <property name="hibernate.hbm2ddl.auto"
>>>>>>>> value="create-drop" />
>>>>>>>>            <property name="hibernate.dialect"
>>>>>>>>            value="org.hibernate.dialect.MySQLInnoDBDialect" />
>>>>>>>>        -->
>>>>>>>>    </properties>
>>>>>>>> </persistence-unit>
>>>>>>>> </persistence>
>>>>>>>>
>>>>>>>> I've add the line:
>>>>>>>> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
>>>>>>>> because using the
>>>>>>>> "-
>>>>>>>> Djavax
>>>>>>>> .persistence
>>>>>>>> .provider=org.eclipse.persistence.jpa.PersistenceProvider"
>>>>>>>> as VM arguments make my tests failing.
>>>>>>>>
>>>>>>>> Thanks for any help.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> View this message in context:
>>>>>>>>
>>>>>>>>
>>>>>>>> http://www.nabble.com/Override-Porvider-property-via-system-properties-tp26021215p26021215.html
>>>>>>>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>  --
>>>>>> View this message in context:
>>>>>>
>>>>>>
>>>>>> http://www.nabble.com/Override-Porvider-property-via-system-properties-tp26021215p26029996.html
>>>>>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>  --
>>>> View this message in context:
>>>>
>>>> http://old.nabble.com/Override-Porvider-property-via-system-properties-tp26021215p26160653.html
>>>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>>
>>>
>
Re: Maven Quickstart Archetypes Quintin Beukes <quintin@skywalk.co.za> urn:uuid:%3c1f3854d50911070330u31348f8h895ad0af018fdaaa@mail-gmail-com%3e 2009-11-07T11:30:16Z 
Hey,

A generic archetypes for only OpenEJB would be really useful. Just one for
an OpenEJB embedded client - where you get a sample EJB, the dependencies
and a unit test that loads up the embedded container. Many times i find
myself just wanting to create a quick project for trying/testing something.
Such an archetype would save a lot of time.

I've never done this, so the source code in quickstart.zip. Does that
contain everything I would need to make such an archetype?

Quintin Beukes


On Fri, Nov 6, 2009 at 2:09 AM, Jonathan Gallimore <
jonathan.gallimore@gmail.com> wrote:

> Hi All,
>
> I don't know if anyone will find this useful, but I've been playing around
> a
> bit with Maven Archetypes, and I created a couple of quickstart archetypes
> for OpenEJB. One creates a simple EJB project, complete with a simple
> stateless bean, a unit test, includes all the necessary dependencies and
> will add the right Eclipse WTP configuration to work with the OpenEJB
> Eclipse Plugin. The other does the same for a complete EAR project. The
> latter still needs a bit of work (and I'd quite like to add the functional
> testing stuff I wrote about here:
>
> http://openejb.apache.org/functional-testing-with-openejb-jetty-and-selenium.html
> )
> but I thought I'd post them up in case anyone had any comments.
>
> Currently I've deployed a mini-repository on my website with the necessary
> stuff, and you can generate a project by doing the following:
>
> $ mvn -DarchetypeCatalog=http://jrg.me.uk/repository/-DarchetypeRepository=
> http://jrg.me.uk/repository/ archetype:generate (the trailing / on the URL
> is necessary for some reason)
>
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'archetype'.
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Maven Default Project
> [INFO]    task-segment: [archetype:generate] (aggregator-style)
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Preparing archetype:generate
> [INFO] No goals needed for project - skipping
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] [archetype:generate]
> [INFO] Generating project in Interactive mode
> [INFO] No archetype defined. Using maven-archetype-quickstart
> (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
> Choose archetype:
> 1: http://jrg.me.uk/repository/ -> maven-openejb-quickstart
> (maven-openejb-quickstart)
> 2: http://jrg.me.uk/repository/ -> maven-openejb-quickstart-ear
> (maven-openejb-quickstart-ear)
> Choose a number:  (1/2):
>
> Once you've followed the wizard, you should be able to cd to the newly
> created project, and run:
>
> $ mvn install eclipse:eclipse
>
> This should compile everything, run the tests and create an Eclipse project
> ready to be imported to your workspace.
>
> I've put some source code up here: http://jrg.me.uk/assets/quickstart.zip-
> I'm more than happy to check it into SVN if anyone thinks its useful. Any
> comments will be gratefully received.
>
> Cheers,
>
> Jon
>
Re: Propagating extra context information in remote EJB calls David Blevins <david.blevins@visi.com> urn:uuid:%3c120D6DB7-2831-4A7B-8C0D-FDECCD7DAFDD@visi-com%3e 2009-11-06T20:17:37Z 
On Oct 29, 2009, at 1:16 AM, Jack Cai wrote:

> I want to propagate some context information in remote EJB calls, and
> hopefully this can be done transparently, i.e., does not require  
> code change
> to existing applications. Is this possible?
>
> I understand transaction and security context are already being  
> propagated
> as part of an EJB container impl. Can I just inject the extra data  
> into the
> security context for example to do the trick?
>
> Appreciate some insight in this area!

The idea that comes to mind is modifying the HttpConnectionFactory to  
in some way set headers into the HttpURLConnection.  In the 3.1.x  
codebase it's actually possible to replace the HttpConnectionFactory  
on an existing client:

   http://mail-archives.apache.org/mod_mbox/openejb-users/200911.mbox/%3CB003CC7A-74F0-4E88-AB61-F8C7A80F7F3B@visi.com%3E

On the server side if there was a Servlet like this:

   import org.apache.openejb.loader.SystemInstance;
   import org.apache.openejb.server.ServiceException;
   import org.apache.openejb.server.ejbd.EjbServer;

   import javax.servlet.ServletConfig;
   import javax.servlet.ServletException;
   import javax.servlet.ServletInputStream;
   import javax.servlet.ServletOutputStream;
   import javax.servlet.http.HttpServlet;
   import javax.servlet.http.HttpServletRequest;
   import javax.servlet.http.HttpServletResponse;
   import java.io.IOException;

   public class ServerServlet extends HttpServlet {
       private EjbServer ejbServer;

       public void init(ServletConfig config) {
           ejbServer =  
SystemInstance.get().getComponent(EjbServer.class);
       }

       protected void service(HttpServletRequest request,  
HttpServletResponse response) throws ServletException, IOException {
           ServletInputStream in = request.getInputStream();
           ServletOutputStream out = response.getOutputStream();
           try {
               ejbServer.service(in, out);
           } catch (ServiceException e) {
               throw new ServletException("ServerService error: " +  
ejbServer.getClass().getName() + " -- " + e.getMessage(), e);
           }
       }
   }


You could get the headers and put them on a ThreadLocal or something.

If the state is going to be the same on a per connection basis, then  
we can maybe make some standard way to put the headers in the  
connection URI and pull them out of that "params" map we create.

We'd need some more creativity to make it really nice and easy for  
people.  But this is a rough approach to get the ideas started.

-David
Re: Propagating extra context information in remote EJB calls David Jencks <david_jencks@yahoo.com> urn:uuid:%3cDA224F1C-3477-4D46-B5CC-AC9DC0D60875@yahoo-com%3e 2009-11-06T02:43:01Z 
AFAIK openejb does not propagate transaction context.  I thought about  
it for corba a long time ago but I have never found anyone who  
actually wants distributed transactions so never made the time to  
implement it.

With Corba I believe you can add client and server interceptors and  
tack whatever info you want onto the request, but I found it a  
difficult programming model to understand.

What context information do you want to transmit?

thanks
david jencks

On Oct 29, 2009, at 4:15 AM, Jacek Laskowski wrote:

> On Thu, Oct 29, 2009 at 10:16 AM, Jack Cai <greensight@gmail.com>  
> wrote:
>
>> 1. At the client side, intercept the client call before it's sent  
>> out, and
>> attach some extra context information with the call;
>> 2. At the server side, intercept the business method call before  
>> the method
>> is actually executed, so that I can retrieve the extra context  
>> information
>> coming with the call and set it into the server thread's context.
>>
>> I need to transparently do this for all EJBs. I was hoping I could  
>> do the
>> trick only once in the code, instead of having to take care of all  
>> EJBs
>> (e.g., use AOP to specify to intecept each invidiual remote  
>> interface).
>>
>> So in a word, I guess this is pretty much the same as how
>> transaction/security context gets propagated today. Does this make  
>> more
>> sense now?
>
> Nope :] I still don't know what exactly you'd like to add to a call.
> Yet, you're right that OpenEJB adds some additional data for security
> and tx mgmt, but I don't think it was exposed for public consumption.
>
> Jacek
>
> -- 
> Jacek Laskowski
> Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Maven Quickstart Archetypes Jonathan Gallimore <jonathan.gallimore@gmail.com> urn:uuid:%3c8a884a800911051609m255a78c8m4a8e87c15332cc88@mail-gmail-com%3e 2009-11-06T00:09:00Z 
Hi All,

I don't know if anyone will find this useful, but I've been playing around a
bit with Maven Archetypes, and I created a couple of quickstart archetypes
for OpenEJB. One creates a simple EJB project, complete with a simple
stateless bean, a unit test, includes all the necessary dependencies and
will add the right Eclipse WTP configuration to work with the OpenEJB
Eclipse Plugin. The other does the same for a complete EAR project. The
latter still needs a bit of work (and I'd quite like to add the functional
testing stuff I wrote about here:
http://openejb.apache.org/functional-testing-with-openejb-jetty-and-selenium.html)
but I thought I'd post them up in case anyone had any comments.

Currently I've deployed a mini-repository on my website with the necessary
stuff, and you can generate a project by doing the following:

$ mvn -DarchetypeCatalog=http://jrg.me.uk/repository/ -DarchetypeRepository=
http://jrg.me.uk/repository/ archetype:generate (the trailing / on the URL
is necessary for some reason)

[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO]
------------------------------------------------------------------------
[INFO] Building Maven Default Project
[INFO]    task-segment: [archetype:generate] (aggregator-style)
[INFO]
------------------------------------------------------------------------
[INFO] Preparing archetype:generate
[INFO] No goals needed for project - skipping
[INFO] Setting property: classpath.resource.loader.class =>
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] [archetype:generate]
[INFO] Generating project in Interactive mode
[INFO] No archetype defined. Using maven-archetype-quickstart
(org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
Choose archetype:
1: http://jrg.me.uk/repository/ -> maven-openejb-quickstart
(maven-openejb-quickstart)
2: http://jrg.me.uk/repository/ -> maven-openejb-quickstart-ear
(maven-openejb-quickstart-ear)
Choose a number:  (1/2):

Once you've followed the wizard, you should be able to cd to the newly
created project, and run:

$ mvn install eclipse:eclipse

This should compile everything, run the tests and create an Eclipse project
ready to be imported to your workspace.

I've put some source code up here: http://jrg.me.uk/assets/quickstart.zip -
I'm more than happy to check it into SVN if anyone thinks its useful. Any
comments will be gratefully received.

Cheers,

Jon