Thanks for the explanation. Actually, I was trying to create a simple
example to demonstrate problem #2 when problem #1 occurred. It had not
occurred to me that the absence of a remote interface might be the
problem...

Is there a configurable option to keep the generated source? I found it
useful to be able to review the generated source.

Does this preview release accurately reflect the O/R mapping capabilities
that will be in place in the final product, or can we expect to see
additional capabilities before the product goes final.

> -----Original Message-----
> From: Gautam Borah [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, June 21, 2001 8:01 AM
> To:    
> Subject:      Re: Can't deploy simple CMP Bean + code gen fails for String
> PK mapped to char(n) column
> 
> Hi Richard,
> 
> I have gone through the problems you have mentioned.
> Please find my analysis in the following,
> 
> 
> > Hello,
> >
> > I have a couple of problems to report....
> >
> >
> > Problem #1
> >
> > For the following very simple test case (foo.ear)
> > Code generation completes successfully but deployment fails with
> > "Failed to load/add the class file. Error: Class loader clould not find
> the
> > class."
> >
> >
> > TestCase: a simple, local Entity Bean with two String properties (mapped
> to
> > CUSTOMER_DVITIYA.CUSTOMERID and CUSTOMER_DVITIYA.LAST_NAME)
> >
> >
> >  <<logs.zip>>  <<foo.ear>>  <<foo-src.zip>>
> >
> 
> In your Foo.ear application there is only one bean with Local interfaces.
> When you tried to deploy it on the server after code generation and
> compilation the container tried to create the FooClient.jar inside folder
> [INST_DIR\server\nodes\StandAlone\default\archives\Foo.ear\classes]. This
> jar contains all the stubs of your RemoteHome and RemoteComponent and also
> the classes that are used in the signature of the stub methods. When you
> tried to deploy your application it tried to create this jar but as there
> are no Remote components in your application it failed.
> 
>  If all the beans in the application are local then these beans can not be
> accessed from outside the SERVER JVM.The only possible way to access these
> beans is throgh a <ejb-local-ref> JNDI lookup in the Server JVM.. One more
> possibility I see is, these local interfaces can be accessed from a JSP or
> servlet, if the WebServer, NamingService and the EJBContainer all are
> running in the same JVM, but current web deployment descriptors(web.xml in
> WAR file) do not support <ejb-local-ref> tag as of now.
> 
> The only way the local beans can be accessed is through another bean in
> the
> same JVM which has Remote Interface or the bean has Remote Interface also.
> 
> If you look at our sample application, OrderApp.ear, the ProductBean has
> only local interfaces, the SalesOrderBean has both local and remote
> interfaces and when a SalesOrder is placed the SalesOrderBean does a
> <ejb-local-ref> lookup to get the local ProductComponent reference.
> 
> Following code is from the SalesOrderBean.java in the ejbPostCreate()
> method.
> 
> <code>
>             CustomerEJBLocalHome customerLocalHome =
> (CustomerEJBLocalHome)ic.lookup("java:comp/env/ejb/CustomerEJB_Local");
>             ProductEJBLocalHome productLocalHome =
> (ProductEJBLocalHome)ic.lookup("java:comp/env/ejb/ProductEJB_Local");
>             LineItemEJBLocalHome lineItemLocalHome =
> (LineItemEJBLocalHome)ic.lookup("java:comp/env/ejb/LineItemEJB_Local");
>             CustomerEJBLocalObject localCustomer =
> (CustomerEJBLocalObject)customerLocalHome.findByPrimaryKey(custPrimKey);
> 
> </code>
> 
> You may go through the sample applications source code in
> [INST_DIR\server\samples\cmp20\java\com\pramati\sample\orderApp\ejb]
> 
> I have added two interfaces in your Foo.ear (1. FooRemote and 2.
> FooHomeRemote) and remaned the ear as Roo.ear. It contains the remote
> interfaces for the FooBean. I am attaching a client source code
> (FooClient.java).
> 
> Kindly try to deploy the application and please get back to me in case you
> come accross any problem.
> 
> 
> 
> > -----------------------------------------------------------
> >
> > Problem #2
> >
> > When I map the example Entity Bean's key field (defined as
> > java.lang.String) to a CHAR(12) database column type instead of
> VARCHAR(12),
> > for example, once again, code generation completes OK, but  compilation
> > fails with several errors like this:
> >
> > ": Incompatible type for constructor. Can't convert java.lang.String
> > to char.
> >     pStmt.setString(++i,(String)new
> > Character(sourcePKObj).toString());"
> >
> > I examined the generated code briefly and  I saw where sourcePKObj
> > is declared as a String (representing the primary key value passed to
> > findByPrimaryKey); but apparently the code generation engine is treating
> it
> > as a single char .
> >
> >
> > <<logs.zip>>
> > -----------------------------
> >
> 
> We have identified this problem, and we will fix this in the coming
> preview
> release. Thanks a million for reporting this bug. I will personally update
> you when we do the next release.
> 
> Thanks & Regards,
> 
> Gautam
> Server Team
> www.pramati.com
> 
>  << File: Roo.ear >>  << File: FooClient.java >> 

Reply via email to