Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 55332 invoked from network); 14 Mar 2007 13:58:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Mar 2007 13:58:06 -0000 Received: (qmail 92547 invoked by uid 500); 14 Mar 2007 13:58:12 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 92487 invoked by uid 500); 14 Mar 2007 13:58:12 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 92476 invoked by uid 99); 14 Mar 2007 13:58:12 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Mar 2007 06:58:12 -0700 X-ASF-Spam-Status: No, hits=0.9 required=10.0 tests=FORGED_YAHOO_RCVD X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [205.152.59.70] (HELO imf22aec.mail.bellsouth.net) (205.152.59.70) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Mar 2007 06:58:00 -0700 Received: from ibm67aec.bellsouth.net ([74.237.109.96]) by imf22aec.mail.bellsouth.net with ESMTP id <20070314135738.ITR14382.imf22aec.mail.bellsouth.net@ibm67aec.bellsouth.net> for ; Wed, 14 Mar 2007 09:57:38 -0400 Received: from [192.168.1.101] (really [74.237.109.96]) by ibm67aec.bellsouth.net with ESMTP id <20070314135738.LGAS26682.ibm67aec.bellsouth.net@[192.168.1.101]> for ; Wed, 14 Mar 2007 09:57:38 -0400 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Jencks Subject: Re: Working on DayTrader Date: Wed, 14 Mar 2007 09:57:26 -0400 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.752.3) X-Virus-Checked: Checked by ClamAV on apache.org 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 :) > >