Hi!
Robert Schulz wrote:
> If this is spec compliance, than compliant apps are not going to work.
You're not listening to what I'm saying. Compliant apps are going to
work just fine. However, since we can't assume that much in our
*default* settings, you will see bad performance. With a little explicit
configuration on your behalf things will run fine.
This ensures that you can just deploy your application in JBoss and it
will always *work*, but once you get that going you tune it to *work
well*.
> We develop and deploy a server side Java web app here and the two things
> which are a problem are
> - memory foot print per users (can't say any thing about jBoss here yet,
> but will get around to it whilst evaluating)
This will be related to client session size, i.e. not related to JBoss
but more with Tomcat and your own application. If you only do stateless
sessions and entitybeans there is no per-user memory hit on JBoss.
> > ... The proper way is to either use a bulk data
> > accessor in the bean, or use a session which extracts the data in one
> > call. This is the main problem with your code.
>
> I can see how this cuts back calls, but from an OO point of view it, err,
> is not very nice. Maybe the session bean approach might help (but I not
> that far yet - maybe tomorrow ;-)
You will definitely want to use code generation tools for the bulk
accessors (they are hopeless to write by hand). May I humbly suggest the
EJBDoclet:
http://www.dreambean.com/ejbdoclet.html
It will generate remote, home, ejb-jar.xml, primary keys, bulk data
objects, etc. by having you add custom javadoc tags to your code. Very
simple, and very nice. And I wrote it, so it's of course OpenSource :-)
(i.e. you can modify it so it fits *your* needs)
If you do this the bean code will be VERY nice. The EJBDoclet assumes
EJB 2.0 CMP code, so all you have to do is abstract get/set methods and
the doclet will generate a subclass which takes care of the persistence
including dirty flags and bulk data objects. You will never see this in
your own code, only in the client code.
> OK - in more detail: In my home interface I declared:
>
> code: public Collection findCapacityAndName(int capacity, String name)
> code: throws RemoteException,
> FinderException;
>
> ie, a non "standard" find method ( findByXYZ and findAll work ok). In the
> documentation
> of jBoss on the website is a page called "Customizing JAWS" and there is a
> section called
> "Declaring Finders" which explains how to setup a finder with WHERE and
> ORDER in jaws.xml
> This is my shot at it:
>
> <jaws>
> <enterprise-beans>
> <entity>
> <ejb-name>ShipBean</ejb-name>
> <finder>
> <name>findCapacityAndName</name>
> <query>capacity = {0} AND name = {1}</query>
> <order>name DESC</order>
> </finder>
> </entity>
> </enterprise-beans>
> </jaws>
>
> Now, when calling the method in the client an exception is throw, which
> stems from the
> database not understanding the SQL created:
>
> query: SELECT id,name DESC FROM ShipBean WHERE capacity = 3000 AND name =
> 'Utopia' ORDER BY name DESC
> ~~~~~~~~~~~~
> The WHERE and ORDER clause are built correctly from what I speced in
> jaws.xml, but the SELECT bit is
> stuffed.
Ah, I see. That's a bug in JBoss/JAWS :-) Add to bugzilla (if it's not
there already; I remember other people having mentioned this)
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
