You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Mohammad Shamsi <m....@gmail.com> on 2008/04/12 16:03:04 UTC
my Java EE tragic story.
Hi Friends,
please take a look at my blog about Java EE and my problems with it.
http://mhshams.blogspot.com/
--
sincerely yours
M. H. Shamsi
Re: my Java EE tragic story.
Posted by "Jay D. McHugh" <ja...@jnwd.net>.
Hi Mohammad,
I'm sorry that you haven't had a better experience with Geronimo.
I looked back at you other posts and it looked like all of your issues
got straightened out.
From your blog, the issue with One to Many relationships is something
that I ran into myself when I first started using JPA.
Apparently, whoever it was that worked out the JPA spec thought that it
would be a good idea to make the 'standard' method of defining a 1-M
relationship be to have the entity on the 'many' side own the
relationship. Until right this second (literally as I am typing this) I
could not see why they would do this - but, that is what they did.
So when I was trying to set up my relationships, they all 'felt'
backwards. Is this what you meant in #3 on your blog?
If it is, then there is a possible ray of light for you with OpenJPA.
Because, they added a (non-standard) way of mapping 1-M relationships
from the 'one' side. That made defining my table relationship feel much
more natural (to me).
So, if that is what you meant on your blog, here is the OpenJPA specific
annotation:
@ElementJoinColumn(name="column in this table",
referencedColumnName="column in the other table")
Hope that helps,
Jay
Mohammad Shamsi wrote:
> Hi Friends,
>
> please take a look at my blog about Java EE and my problems with it.
>
> http://mhshams.blogspot.com/
>
Re: my Java EE tragic story.
Posted by Mohammad Shamsi <m....@gmail.com>.
thanks Yura,
this is not jost about jndi prefix. take a look at this list :
JBOSS :: {jar file name}/{bean name}/{local or remote}
GLASSFISH :: ejb/{bean name}
WEBLOGIC :: {jar file name}_{bean name}_{remote or local interface name}
..
I solved this problem with one xml file for each app server. i most define
all EJB in these xml files.
any way, i don't looking for solution here. I just want to say that Java EE
portability is just in theory.
On Sat, Apr 12, 2008 at 11:20 PM, Yura Tkachenko <
try.tapestry.again@gmail.com> wrote:
> Hi Mohammad,
>
> I have one suggestion to fix JNDI naming conventions on different servers.
> In general if in your code you have:
>
> InitialContext iniCtx = new InitialContext(props);
> Context envCtx = (Context) iniCtx.lookup("java:comp/env");
>
> I suggest you to expose constant "java:/comp/env" to some configuration
> file
> (let's call it jndi_jboss.properties). So tomorrow if for some reason you
> need to run your application on new app server and this jndi name will
> look
> like: "comp/env" you just need to create another config file with specific
> settings for this particular application server
> (jndi_xxx_app_server.properties).
> Hopes this solution can address your problem with jndi.
>
> Thanks,
> Yura.
>
> On Sat, Apr 12, 2008 at 11:36 PM, Mohammad Shamsi <m....@gmail.com>
> wrote:
>
> > No, it doesn't about Tapestry.
> >
> > its about my problems during migration from lightweight containers to
> the
> > Java EE standard world.
> >
> >
> >
> > On Sat, Apr 12, 2008 at 11:27 AM, adasal <ad...@gmail.com> wrote:
> >
> > > Your blog doesn't seem to be about Tapestry.
> > > I believe there are standards, but the standards have boarders which
> may
> > > be
> > > redefined as the standard evolves. What is inside the boarder will be
> > > interoperable, What is outside is left to the implementer.
> > > It is very possible to misunderstand the standard and find that two
> > > seeming
> > > incompatible implementations are both correct and are compatible.
> These
> > > things are complex.
> > > I don't understand your point 4. But I doubt that TopLink is short on
> > > features and capability. Maybe if you explain more fully, but this
> > doesn't
> > > belong to the Tapestry list.
> > > What may belong here is how much Tapestry falls within the boarders of
> > > J2EE
> > > conformance, or does it touch on it at all? I would have thought it
> > > doesn't
> > > and any implementation made with Tapestry will be conforment where
> > > standards
> > > dictate.
> > > Adam
> > >
> > > On 12/04/2008, Mohammad Shamsi <m....@gmail.com> wrote:
> > > >
> > > > Hi Friends,
> > > >
> > > > please take a look at my blog about Java EE and my problems with it.
> > > >
> > > > http://mhshams.blogspot.com/
> > > >
> > > >
> > > > --
> > > > sincerely yours
> > > > M. H. Shamsi
> > > >
> > >
> >
> >
> >
> > --
> > sincerely yours
> > M. H. Shamsi
> >
>
--
sincerely yours
M. H. Shamsi
Re: my Java EE tragic story.
Posted by Yura Tkachenko <tr...@gmail.com>.
Hi Mohammad,
I have one suggestion to fix JNDI naming conventions on different servers.
In general if in your code you have:
InitialContext iniCtx = new InitialContext(props);
Context envCtx = (Context) iniCtx.lookup("java:comp/env");
I suggest you to expose constant "java:/comp/env" to some configuration file
(let's call it jndi_jboss.properties). So tomorrow if for some reason you
need to run your application on new app server and this jndi name will look
like: "comp/env" you just need to create another config file with specific
settings for this particular application server
(jndi_xxx_app_server.properties).
Hopes this solution can address your problem with jndi.
Thanks,
Yura.
On Sat, Apr 12, 2008 at 11:36 PM, Mohammad Shamsi <m....@gmail.com>
wrote:
> No, it doesn't about Tapestry.
>
> its about my problems during migration from lightweight containers to the
> Java EE standard world.
>
>
>
> On Sat, Apr 12, 2008 at 11:27 AM, adasal <ad...@gmail.com> wrote:
>
> > Your blog doesn't seem to be about Tapestry.
> > I believe there are standards, but the standards have boarders which may
> > be
> > redefined as the standard evolves. What is inside the boarder will be
> > interoperable, What is outside is left to the implementer.
> > It is very possible to misunderstand the standard and find that two
> > seeming
> > incompatible implementations are both correct and are compatible. These
> > things are complex.
> > I don't understand your point 4. But I doubt that TopLink is short on
> > features and capability. Maybe if you explain more fully, but this
> doesn't
> > belong to the Tapestry list.
> > What may belong here is how much Tapestry falls within the boarders of
> > J2EE
> > conformance, or does it touch on it at all? I would have thought it
> > doesn't
> > and any implementation made with Tapestry will be conforment where
> > standards
> > dictate.
> > Adam
> >
> > On 12/04/2008, Mohammad Shamsi <m....@gmail.com> wrote:
> > >
> > > Hi Friends,
> > >
> > > please take a look at my blog about Java EE and my problems with it.
> > >
> > > http://mhshams.blogspot.com/
> > >
> > >
> > > --
> > > sincerely yours
> > > M. H. Shamsi
> > >
> >
>
>
>
> --
> sincerely yours
> M. H. Shamsi
>
Re: my Java EE tragic story.
Posted by Mohammad Shamsi <m....@gmail.com>.
No, it doesn't about Tapestry.
its about my problems during migration from lightweight containers to the
Java EE standard world.
On Sat, Apr 12, 2008 at 11:27 AM, adasal <ad...@gmail.com> wrote:
> Your blog doesn't seem to be about Tapestry.
> I believe there are standards, but the standards have boarders which may
> be
> redefined as the standard evolves. What is inside the boarder will be
> interoperable, What is outside is left to the implementer.
> It is very possible to misunderstand the standard and find that two
> seeming
> incompatible implementations are both correct and are compatible. These
> things are complex.
> I don't understand your point 4. But I doubt that TopLink is short on
> features and capability. Maybe if you explain more fully, but this doesn't
> belong to the Tapestry list.
> What may belong here is how much Tapestry falls within the boarders of
> J2EE
> conformance, or does it touch on it at all? I would have thought it
> doesn't
> and any implementation made with Tapestry will be conforment where
> standards
> dictate.
> Adam
>
> On 12/04/2008, Mohammad Shamsi <m....@gmail.com> wrote:
> >
> > Hi Friends,
> >
> > please take a look at my blog about Java EE and my problems with it.
> >
> > http://mhshams.blogspot.com/
> >
> >
> > --
> > sincerely yours
> > M. H. Shamsi
> >
>
--
sincerely yours
M. H. Shamsi
Re: my Java EE tragic story.
Posted by adasal <ad...@gmail.com>.
Your blog doesn't seem to be about Tapestry.
I believe there are standards, but the standards have boarders which may be
redefined as the standard evolves. What is inside the boarder will be
interoperable, What is outside is left to the implementer.
It is very possible to misunderstand the standard and find that two seeming
incompatible implementations are both correct and are compatible. These
things are complex.
I don't understand your point 4. But I doubt that TopLink is short on
features and capability. Maybe if you explain more fully, but this doesn't
belong to the Tapestry list.
What may belong here is how much Tapestry falls within the boarders of J2EE
conformance, or does it touch on it at all? I would have thought it doesn't
and any implementation made with Tapestry will be conforment where standards
dictate.
Adam
On 12/04/2008, Mohammad Shamsi <m....@gmail.com> wrote:
>
> Hi Friends,
>
> please take a look at my blog about Java EE and my problems with it.
>
> http://mhshams.blogspot.com/
>
>
> --
> sincerely yours
> M. H. Shamsi
>