Harkness, David wrote:
bob combs wrote:
WORKING!
WOOT!
Had to add a null constructor into UUID to get the create()
to work due
to CMP wanting to do a class.newInstance(), then populate data on the
primary key.
Yes, and I believe that's also the reason that the PK's fields (in th
On May 11, 2004, at 7:52 AM, [EMAIL PROTECTED] wrote:
hacking at this ant script for hours. tried every possible permutation
of the fileset.
no doclets are generated and the only output is --
Buildfile: xdoclet-build.xml
xdocletIsCrap:
[hibernatedoclet] (XDocletMain.start
On Tue, 2004-05-11 at 12:52, [EMAIL PROTECTED] wrote:
> hacking at this ant script for hours. tried every possible permutation
> of the fileset.
> no doclets are generated and the only output is --
>
> Buildfile: xdoclet-build.xml
> xdocletIsCrap:
> [hibernatedoclet] (XDocletMain.star
bob combs wrote:
> WORKING!
WOOT!
> Had to add a null constructor into UUID to get the create()
> to work due
> to CMP wanting to do a class.newInstance(), then populate data on the
> primary key.
Yes, and I believe that's also the reason that the PK's fields (in the
class) need to be public --
Sorry,
I mean, I have a plugin.properties with these contents in my home
directory...
> Where should thid project.properties must be?
>
> I have a build.properties, on my home directory:
>
> #ejbdoclet default properties
> maven.xdoclet.ejbdoclet.destDir=${maven.build.dir}/xdoclet/ejbdoclet
>
>
Where should thid project.properties must be?
I have a build.properties, on my home directory:
#ejbdoclet default properties
maven.xdoclet.ejbdoclet.destDir=${maven.build.dir}/xdoclet/ejbdoclet
maven.xdoclet.ejbdoclet.force=true
maven.xdoclet.ejbdoclet.verbose=true
maven.xdoclet.ejbdoclet.files
bob combs wrote:
> putting the @ejb.pk-field entry back on the getId() method generates a
> correct getPrimaryKey()
Cool, then you're almost there, right? Or are you all the way there? I
still think it's odd that it creates a PK each time you call
getPrimaryKey(), but that's not so nefarious I sup
bob combs wrote:
> Problem lies in what's being generated in the getPrimaryKey()
> in the VO:
>
>public com.messagegate.foundation.id.UUID getPrimaryKey() {
> com.messagegate.foundation.id.UUID pk = new
> com.messagegate.foundation.id.UUID();
> return pk;
>}
WTF?! That's truly b
hI,#
how about creating a project.properties file where
u define what is needed for XDoclet?
there is an example at XDoclet website, follow the Maven link..
regards
marco
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Jesus De
Oliveira -
WORKING!
Had to add a null constructor into UUID to get the create() to work due
to CMP wanting to do a class.newInstance(), then populate data on the
primary key. Now I just have to make the VO inherit from somewhere or
merge methods in so I can get a get/set UUID. Some form of inheritance
wo
More fun:
putting the @ejb.pk-field entry back on the getId() method generates a
correct getPrimaryKey()
Harkness, David wrote:
bob combs wrote:
org.jboss.deployment.DeploymentException: Field id in prim-key-class
must be the same type
Ah yes, note to self: reply *after* coffee. By u
Almost!
Problem lies in what's being generated in the getPrimaryKey() in the VO:
public com.messagegate.foundation.id.UUID getPrimaryKey() {
com.messagegate.foundation.id.UUID pk = new
com.messagegate.foundation.id.UUID();
return pk;
}
should be:
public com.messagegate.foundation.id
More follow-up.
Seems that the name of the field is kind of issue. If I change the field
name in the bean to "idd" (as in getIdd/setIdd with a matching
pk-field=idd entry) the bean will deploy. However, any SQL that gets
issued (either a table create or if I create the table by hand, a query)
bob combs wrote:
> org.jboss.deployment.DeploymentException: Field id in prim-key-class
> must be the same type
Ah yes, note to self: reply *after* coffee. By using a custom PK class,
you still need to map the individual fields (one in your case) using the
types in the PK class. So you need
pu
Hi,
I'm trying to use the xdoclet plugin for maven, to build the classes and
interfaces for enterprise javabeans. My problem is that when the
xdoclet:ejbdoclet task is executed, nothing is generated, causing
compilation errors because the classes and interfaces never exists.
Following is the outpu
Follow up:
org.jboss.deployment.DeploymentException: Field id in prim-key-class
must be the same type
Here's specifically what I have now:
--
package com.messagegate.mms.message.ejb;
import javax.ejb.EntityBean;
import com.messagegate.foundation.id.IdentifierFactory;
import com.messagega
Thanks David, but I've been that route too (you're seeing some scatterd
remnants of various experiments).
I get a deployment message that "field id must be of same type". Same
type as what would be nice to know. I'll make everything match up both
ways though and give it another go.
Harkness, Da
bob combs wrote:
> I'm having quite a time attempting to use a CMP bean with a custom PK
> class w/ support in the value object. I'm sure I'm missing something
> fairly simple.
>
> [...]
>
> In the Bean xdoclet
>
> /**
> * @ejb.bean name="Message"
> * pk-field="id"
^^
> **/
Bruno Beloff wrote:
> I'm sure this would work. My only concern is that - by putting my
> code in the template - I've made it harder to modify and develop the
> code. But that's not a significant problem in most situations.
The key would be to put code into the template that would *generate*
your
DDU DUQUENNOY Didier wrote:
> Just a question : is it possible to avoid generating the
> constant "JNDI_NAME" in the Home class?
You could modify the template to remove it. I don't know of an
configuration option.
> Actually, I don't understand why it is there since the JNDI
> Name of an EJB may
Setting the force attribute to false seems to have
done the trick. Thanks Erik.
Shaun
On May 11, 2004, at 7:52 AM, [EMAIL PROTECTED] wrote:
hacking at this ant script for hours. tried every possible permutation
of the fileset.
no doclets are generated and the only output is --
Buildfile: xdoclet-build.xml
xdocletIsCrap:
[hibernatedoclet] (XDocletMain.start
hacking at this ant script for hours. tried every
possible permutation of the fileset.no doclets are generated and the only
output is --
Buildfile:
xdoclet-build.xml xdocletIsCrap:
[hibernatedoclet]
(XDocletMain.start
47 ) Running BUILD
SUCCESSFUL Tot
It does compare timestamps itself - it takes a little time to do this,
but much less than doing actual generation followed by subsequent
recompilation and repackaging of things that did not change. Be sure
you are not setting the force attribute.
Erik
On May 11, 2004, at 5:32 AM, Shaun wrote
Is there any plan to enable XDoclet to only
generate code if a source file has changed since the last generation?
Currently I am using tasks in ant to accomplish this, but it
seems that it would be nicer if XDoclet did this inherently. Or does it
compare timestamps inherently and I am jus
Hi,
I'm using XDoclet 1.2 to generate the Home and Remote interface of my EJBs.
Just a question : is it possible to avoid generating the constant "JNDI_NAME" in the
Home class?
Actually, I don't understand why it is there since the JNDI Name of an EJB may change
at deployment time...
Thanks,
Lorraine
Thank you, this looks great.
I will try to do this by creating an abstract class which is extended
by both the Bean class and the VO. This abstract class can introduce
the persisted fields as abstract getters, this allows the compareTo(..)
do to its stuff.
This feels slightly weird
Title: Re: [Xdoclet-user] Specifying a remove method on the home interface?
Hi all,
Don’t wanna spam the list,
but I can’t figure out what is the problem.
I am using xdoclet
-1.2.1 together with maven.
I want to generate the
in web.xml.
So I went to check the maven xdoclet
David
Thank you very much for this.
I'm sure this would work. My only concern is that - by putting my code
in the template - I've made it harder to modify and develop the code.
But that's not a significant problem in most situations.
Cheers,
Bruno.
On 10 May 2004, at 19:36, Harkness, Davi
29 matches
Mail list logo
