Ara,
Thanks, I'll update and try again.. Don't think I don't appreciate the hard
work you are all doing, because I do.. I just want to see the quality and
confidence go up, which will ensure that the project will be more often
considered for use in various shops. For instance, I co-founded a Java-based
consulting company and found several open source projects that I would carry
into engagements for faster development such as Castor, Ant, Tomcat, etc.
These projects have achieved their level of acceptance into a number of
development shops because of their proven track record of stability and
features. I would love to see XDoclet achieve the same thing. So, I bring
these things up to enhance the stability and acceptance of XDoclet.
On the topic of testing, I'm sure that since your code is more easily
testable with Junit in the small now, that producing unit tests before doing
bug fixes or adding enhancements will begin to happen. I would be concerned
with system-level acceptance tests to spot the problems that I am seeing (as
it seems your framework is pretty stable thus far). These tests would ensure
that changes made to the codebase do not break any existing code generation.
One method of doing this may be to use expect or do file comparisons. That
way, after running a system-level junit test, you can determine if the
resulting output matches that which is expected to be produced. This would
have caught the error I noticed where a create() method was missing. You
could start with pretty simple tests, such as generic stateless session
beans, then add jboss and weblogic, then go for simple CMP and BMP, adding
relations, etc. as needed. If you add a new feature that would generate new
Java code and deployment descriptor XML, then add it to them expected files
first, in which the unit tests will then fail. The impl is then added and
the unit tests run until the expected output is achieved and the task/bug
fix is completed.
Another method was one that was mentioned earlier, one of testing
deployment. This would involve deploying generated beans into JBoss and
Weblogic, and running unit tests against them to check logic, CMP/BMP, etc.
These would involve more work but ensure that deployment occurs properly (no
exceptions upon deployment) and that the behavior is expected (data in DB by
testng with a straight SQL connection outside the bean or requerying the
bean and comparing fields for CMP and Castor JDO). My main concern on this
topic is that if you or others are only testing with one application server,
issues could arise with another and not be caught. Its fairly inexpensive
(time wise) to download an eval of WebLogic or talk with them about a 2-6
month dev license for testing your project as you do with JBoss. And of
course, JBoss 3.0 alpha adds more complexity but ensures that code is
working properly with both versions and helps to spot areas where
version-specific tags may be needed to handle both versions (if this is even
needed).
I hope this helps out. My environment includes using WebLogic 6.1 with
Stateless and CMP EJBs (2.0 spec) and will eventually involve the testing of
WL, JBoss, and Orion. The beans will be released as open source, and be used
in a closed sourced, non-profit web site. Thus, I need to choose pretty soon
how I will manage these EJBs and test them myself. Having a greater
confidence in XDoclet will both save me time in coding and debugging as I
try to update with your recent CVS changes for your newer JBoss 3.0 and WL
6.1 updates and target potentially 3 or more application servers (and maybe
Castor JDO objects) with my project.
Sorry for the long-windedness, I just wanted to ensure that I convey my
thoughts adequately and provide a good background and vision for what I
would expect to see come from XDoclet. If this doesn't align with your
goals, please let me know so that I may adjust my vision and technology
decisions.
Best Regards,
James
----- Original Message -----
From: "Ara Abrahamian" <[EMAIL PROTECTED]>
To: "'James Higginbotham'" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Sunday, December 09, 2001 9:51 AM
Subject: RE: [Xdoclet-user] Create() in CMP Missing?
I fixed the create-method bug. I apologize, that was because of my
changes.
I agree with you that we need unit testing for Xdoclet. Why we haven't
done it already is because Xdoclet wasn't junit-friendly and btw this
tool started as a little tool for generating ejb interfaces and now is
more or less a framework. Another issue is how to unit test it after
all. Let me explain what the create-method bug was. I changed home
templates yesterday (refactored the templates!), but I mistakenly
changed one part to:
<XDtEjbSession:ifStatelessSession>
public <XDtEjbIntf:componentInterface type="remote"/> create() throws
javax.ejb.CreateException, java.rmi.RemoteException;
</XDtEjbSession:ifStatelessSession>
<XDtEjbSession:ifStatefulSession>
<XDtMethod:forAllMethods>
<XDtEjbHome:ifIsCreateMethod>
<XDtMethod:methodComment indent="3"/>
public <XDtEjbIntf:componentInterface type="remote"/>
create(<XDtParameter:parameterList/>) <XDtMethod:exceptionList
append="java.rmi.RemoteException,javax.ejb.CreateException"/>;
</XDtEjbHome:ifIsCreateMethod>
</XDtMethod:forAllMethods>
</XDtEjbSession:ifStatefulSession>
the problem is the second ifStatefulSession block which should be
ifNotStatelessSession. So tell me how could we write a unit test for
this template file? It's like writing unit tests for jsp files! I don't
have a good solution. Maybe Xdoclet-users could shed a light....
Btw, we can and we will add unit tests for the normal java sources of
Xdoclet. It's now junit-friendly, should be possible to write unit tests
for blablaTagsHandlers easily, they are completely independent from the
rest of the world. We'll try it after v1.1 release.
Cheers,
Ara.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of James
Higginbotham
Sent: Sunday, December 09, 2001 7:20 AM
To: [EMAIL PROTECTED]
Subject: [Xdoclet-user] Create() in CMP Missing?
Importance: High
I just obtained the latest CVS about 10 minutes ago, built it, replaced
the jar with the new one, and discovered that none of my ejbCreate()
methods are being honored. I just built the samples and noticed the same
thing. Anyone else seeing this?
I am also seeing a problem with CMPs that only have a local interface
not getting the <local> and <localhome> entries generated in their
ejb-jar.xml file. Anyone seeing this as well?
I'm getting a bit frustrated with trying to use this tool, though the
goals are honorable. I am concerned that there are no regression tests
being performed to ensure that the most basic concepts, such as create()
methods, are continuing to be generated. It also prevents quick
determination of whether WebLogic and JBoss support is broken or not. Am
I missing something with your project, or is this the case? If so, what
are the plans for implementing unit tests and other forms of regression
testing when introducing new features or bug fixes?
Currently, I am spending more time getting around XDoclet 'features'
than writing code - I hope this will change, as I don't want to abandon
XDoclet unless it is necessary.
Attached is my source file, along with the generated code. You can build
your samples project and look at the AccountBean to see the same
problem.The home contains only finders and no create() methods.
Best Regards,
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
