A wise old hermit known only as Andrew Stevens
<[EMAIL PROTECTED]> once said:
> A wise old hermit known only as KC <[EMAIL PROTECTED]> once said:
>
> > 1. I am trying Xdoclet1.1.1 to create my "jboss.xml" file.
> > 2. I use the merge file method, the content of the merge file, both
> > the
> >
A wise old hermit known only as Nortje, Andrew <[EMAIL PROTECTED]> once
said:
> I am having trouble getting the PK classes to gen properly. I don't
> think I am making the PK fields properly.
>
> I have a class called Contact with two Long's that serve as the PK
> fields.
> The PK class does
A wise old hermit known only as KC <[EMAIL PROTECTED]> once said:
> 1. I am trying Xdoclet1.1.1 to create my "jboss.xml" file.
> 2. I use the merge file method, the content of the merge file, both the
> "jboss-resource-managers.xml" and the "jboss.xml" appear as follows:
>
>
> res-class="
Hi everyone,
1. I am trying Xdoclet1.1.1 to create my "jboss.xml" file.
2. I use the merge file method, the content of the merge file, both the
"jboss-resource-managers.xml" and the "jboss.xml" appear as follows:
AppDB
java:/AppDS
3. I receive the following error:
Att
I am having problems with the BMP files that xdoclet is generating (built
from CVS today).
1) It is generating two variables for dirty. See at the beginning of the
class and right before the serialVersionId;
2) It isn't generating the makeClean function.
When I look at the entitybmp.j which
very nice little slide (o:
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 01, 2002 9:46 AM
Subject: RE: [Xdoclet-user] Generated Util classes' getHome()
> forgot the slide I promised. Hope it clears things up.
>
> Aslak
forgot the slide I promised. Hope it clears things up.
Aslak
comp_jndi.png
Description: PNG image
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jozsa
> Kristof
> Sent: 31. januar 2002 23:14
> To: Dmitri Colebatch; [EMAIL PROTECTED]
> Subject: Re: [Xdoclet-user] Generated Util classes' getHome()
>
>
> hi,
>
> thanks much for the explanation, I
I think it really depends how you intend using it. My guess is that its for use
inside another bean, with the assuming that the
other bean will have the appropriate ejb-ref tags. Konstantin was the initial
committer of it, so perhaps he can answer it?
cheers
dim
- Original Message -
I agree with dim, and Util's getHome()/getLocalHome() should use
java:comp/env since that's the spec recommendation.
I suggest that we add getHomeJNDI()/getLocalHomeJNDI() methods that use the
JNDI name for lookup. This will make everybody happy. The javadocs in the
Util classes should explain th
hi,
thanks much for the explanation, I see much clearly now :) I don't think I
have a vote here, but anyway, an other Util class per Bean don't make much
sense for me. What about using the COMP_NAME for local lookups, and using
JNDI for remote ones (and making all these overwritable by optional x
The Util class could always do:
lookup in java:comp/env
if not found:
lookup in absolute
But then it makes you think... why not just look up the absolute.
D
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Dmitri
> Colebatch
> Sent: Thursday, Ja
java:comp/env is a magic namespace for each bean. Thus, if you are outside of the
bean you will not see
that special context.
This allows for the same ejb-ref name to point to different real names without having
a conflict:
Bean1:
java:comp/env/Account -> com.foo.Account
Bean2:
java:comp/en
Christopher,
there has been some discussion of this recently on dev (I think thats where it was).
quick abc on jndi and ejb: inside an ejb container, the spec "recommends" that a bean
looks up resources in the java:comp/env
namespace, and the container has to provide facilities for mapping ref
Hello,
using the generated *Util classes, it seems that their getHome() methods
fail when they're invoked 'outside' of the EJB environment. As I see if I
get the home manually (getting InitialContext, doing lookup and narrow the
home class), and use the classes' JNDI_NAME, it works fine, but fail
> > The question is how? What's the easy way? The key here is the
ejb:bean
> > jndi-name parameter. I think a good solution could be letting user
> > define multiple ejb:bean tags, loop over all those ejb:bean, create
a
> > separate entry for each on, and so on. There should be a dittoing
> > faci
>
> The question is how? What's the easy way? The key here is the ejb:bean
> jndi-name parameter. I think a good solution could be letting user
> define multiple ejb:bean tags, loop over all those ejb:bean, create a
> separate entry for each on, and so on. There should be a dittoing
> facility to
> I know this is not exactly what this thread was about, but in addition
to
> having multiple separate deployment descriptors be able to be
generated
> with different values, I'd really like the ability to deploy the same
bean
> multiple times in the SAME deployment descriptor, with different
> co
Hi All,
I know this is not exactly what this thread was about, but in addition to having
multiple separate deployment descriptors be able to be generated with different
values, I'd really like the ability to deploy the same bean multiple times in the SAME
deployment descriptor, with different
Multiple deployment settings.
It's tricky and honestly I haven't given it full thought what the
problems could be. I don't know, maybe we should provide a mechanism to
let user specify which deployment he's targeting now (say
${deployment1.project.name} and n nested elements of
ejbdoclet wher
Property replacement works the same way for all tags. The problem is
that property replacement only works if you use
someparam="${some.property}", but not with
someparam="foo${some.property} or someparam="${some.property}bar". Dim
implemented this, so maybe he could fix it. The workaround in t
Hi,
The situation is the following: I have two CMR beans in 1-n bidirectional
relationship, Product and Manufacturer (the usual example :), both beans are
view-type="local". I'd like to have a container managed query on the Product
bean, which would return a collection of Products where it's manu
Hi,
I have a similiar problem: I want to deploy different applications (say
shop1 and shop2) based on the same beans within the same ejb server
(JBoss). To be able to distinguish the bean "instances" I prefix the
JNDI name with the application name, e. g. shop1/ShoppingCart.
With xDoclet (v1.
At 17:05 2002-01-30 +0100, Daniel Bratell wrote:
>>No, it's not wrong. Check the DTD (it's bundled with xdoclet). Only m:n
>>relationships are supposed to have two :s.
>
>Not in my WebLogic. I have Weblogic 6.1 SP1. I do try to define a
>unidirectional 1->n relationship but with only one
>webl
24 matches
Mail list logo