Working on DayTrader

[Matt Hogstrom <ma...@hogstrom.org>]

I'll be working on DT today.  My goals are to first get the monster  
deployed on trunk (and working or JIRA's opened identifying issues).   
I'm also going to next look at primitives for EJB 3.0 and see where  
we lack and what needs to be added.

I suspect we would like to keep the AppClients that use WS and for  
data integrity verification.  Most people don't find them that useful  
(only a few postings about what they are).  If anyone has an opinion  
one way or the other chime in.

I know chris has done some cleanup so maybe all this is already done :)

Re: Working on DayTrader

[Matt Hogstrom <ma...@hogstrom.org>]

On Mar 14, 2007, at 10:14 AM, Christopher Blythe wrote:

> Matt...
>
> As I mentioned last week, I started working on a full EJB3 mode for  
> Daytrader 2.0 on Glassfish. I was able to get this up and running  
> under load late yesterday afternoon. So far, I have not seen any  
> exceptions; however, I have not had a chance to verify how much  
> data I may be stomping due to the optimistic nature of EJB3/JPA. In  
> addition to the full workload, I also have a full set of EJB3  
> session and entity primitives. I will try to have a patch (and/or  
> these changes integrated) within the next day or so.
>

Excellent, I'd be curious as I spect everyone else would about  
differences you might see between Glassfish and Geronimo in terms of  
application behaviour.

I'll focus on the EJB 2.1 stuff which I believe is currently broken.   
Also, if you could commit your primitive stuff that would be awesome.

thanks

Re: Working on DayTrader

[Christopher Blythe <cj...@gmail.com>]

Matt...

As I mentioned last week, I started working on a full EJB3 mode for
Daytrader 2.0 on Glassfish. I was able to get this up and running under load
late yesterday afternoon. So far, I have not seen any exceptions; however, I
have not had a chance to verify how much data I may be stomping due to the
optimistic nature of EJB3/JPA. In addition to the full workload, I also have
a full set of EJB3 session and entity primitives. I will try to have a patch
(and/or these changes integrated) within the next day or so.

Chris

On 3/14/07, David Jencks <da...@yahoo.com> wrote:
>
> someone just reported a problem with some required classes being in
> one of the app client jars and no longer being accessible to the
> server.  I caused this recently :-) by making the app client deployer
> copy the files into the app client's configuration rather than the
> ear configuration.  This makes the app client config independent of
> the ear config so it should be possible to deploy it without the ear
> config present.
>
> I'm not quite sure what the best solution is....nor am I sure that
> having an app client as a manifest dependency of a server side
> component is spec compliant.
>
> I think we could either:
>
> (1) if the app client is specified as a manifest cp entry, copy it
> into the ear config but just as a jar, so there would be 2 copies,
> one in the ear and one in the app client
>
> (2) in this case make the app client config a parent of the ear config
>
> At the moment (1) sounds more reliable to me.
>
> thanks
> david jencks
>
>
> On Mar 14, 2007, at 9:42 AM, Matt Hogstrom wrote:
>
> > I'll be working on DT today.  My goals are to first get the monster
> > deployed on trunk (and working or JIRA's opened identifying
> > issues).  I'm also going to next look at primitives for EJB 3.0 and
> > see where we lack and what needs to be added.
> >
> > I suspect we would like to keep the AppClients that use WS and for
> > data integrity verification.  Most people don't find them that
> > useful (only a few postings about what they are).  If anyone has an
> > opinion one way or the other chime in.
> >
> > I know chris has done some cleanup so maybe all this is already
> > done :)
> >
> >
>
>


-- 
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden

Re: Working on DayTrader

[David Jencks <da...@yahoo.com>]

someone just reported a problem with some required classes being in  
one of the app client jars and no longer being accessible to the  
server.  I caused this recently :-) by making the app client deployer  
copy the files into the app client's configuration rather than the  
ear configuration.  This makes the app client config independent of  
the ear config so it should be possible to deploy it without the ear  
config present.

I'm not quite sure what the best solution is....nor am I sure that  
having an app client as a manifest dependency of a server side  
component is spec compliant.

I think we could either:

(1) if the app client is specified as a manifest cp entry, copy it  
into the ear config but just as a jar, so there would be 2 copies,  
one in the ear and one in the app client

(2) in this case make the app client config a parent of the ear config

At the moment (1) sounds more reliable to me.

thanks
david jencks


On Mar 14, 2007, at 9:42 AM, Matt Hogstrom wrote:

> I'll be working on DT today.  My goals are to first get the monster  
> deployed on trunk (and working or JIRA's opened identifying  
> issues).  I'm also going to next look at primitives for EJB 3.0 and  
> see where we lack and what needs to be added.
>
> I suspect we would like to keep the AppClients that use WS and for  
> data integrity verification.  Most people don't find them that  
> useful (only a few postings about what they are).  If anyone has an  
> opinion one way or the other chime in.
>
> I know chris has done some cleanup so maybe all this is already  
> done :)
>
>