Sun JEE5 API, javax.ejb package Stateless annotation:
| mappedName
|
| public abstract String mappedName
| A product specific name(e.g. global JNDI name) that this session bean
should be mapped to. Application servers are not required to support any
particular form or type of mapped na
@LocalBinding works perfectly but it's really REALLY lame that Jboss put
in this annotation, while the sun EJB3.0 specification says that the mappedName
property of @Stateless should do this job.
Vendor specific solutions are evil and wrong!
View the original post :
http://www.jboss.com/i
In different tutorials I am seeing different specifications for the same models.
e.g.: To bind a SessionBean to a give name, some use:
| @LocalBinding(jndiBinding="some_binding")
|
others use:
| @Stateless(mappedName="some_binding")
|
What am I missing or not getting? (ps. the Loca
I'm building a tree structured Object model. I.o.w. there a single POJO
(ResourceEJB) with a parent reference (Many to One) and a collection of child
references (One to Many) which are of the same type.
I have a method which determines all ResourceEJB object that share a certain
ResourceEJB par
Sweet thx. (backdoors are always nice to know)
For now I'll stick with:
| em.createQuery("find "+getPersistentClass().getName()+"
object").getResultList();
|
... to maintain a cross platform freedom. It's a lame solution, but probably
the only one that's 'clean'.
View the original post
I'm trying to convert my old Hibernate GenericDAO to an EJB3.0 GenericDAO. My
problem is that EJB3.0 requires a specific Query to retrieve all objects rather
then a Criterion (like Hibernate) that is purely defined by a class type.
Hibernate could do it like this:
| protected List
|
Thta won't work. This problem has been around since the birthdays of Hibernate.
Basically it comes down to this:
The exception that is throw isn't thrown back through the call-chain, but
rather through the container. This exception doesn't 'land' back in your
application until it reaches the st
I have a 'modulename'.jar containing all classes relevant to the data
integration tier. This is a plug and play module which must not have
dependencies outside of the module. The problem is that I can't create an
EntityManagerFactory in a managed transaction or I get the following exception:
Thx for all your help :)
The initialization part will be tricky since the module containing all the EJB
classes isn't even really initialized when first called upon.
I.o.w. the orm mappings/JNDI bindings are deployed just in time when the first
call to the module is made.
View the original pos
Also,
Do you have any tips on how to preload/precreate the EMF?
I'm developing a integratable jar which supplies all classes from the Facade to
the Entity Objects there is no point in my entire module, where no
transaction is active. Can I preload the class somehow when it is deployed in
t
If I try to add those options to my persitence.xml properties, I get the
following exception:
| java.lang.RuntimeException: java.lang.NoClassDefFoundError:
org/jboss/cache/TreeCacheMBean
| at
org.jboss.ejb3.ServiceDelegateWrapper.startService(ServiceDelegateWrapper.java:105)
|
I am trying to create an EntityManagerFactory in a Generic DAO object, but as
soon an the Child Object is created this following error is thrown.
note: I manually added ehcache-1.2.1RC.jar, since the EJB3.0 setup is lacking
an ehcache jar file)
(I'm using JBoss 4.0.4GA EJB3.0 setup with MySQL 4
"anders.hedstrom" wrote : anonymous wrote : Why in heavens name, would I want
to add a service locator between my As and DAO?
|
| Why in heavens name, would you want to use a service locator between your
As and DAO?
Because JNDI code doesn't below in an Application Service?
View the origin
Just implemented the DAO's as Sessions that are aquired by the POJO AS through
a DAO Factory that does the JNDI lookup by menas of a ServiceLocator.
result:
8.1% increase in response time with 100 users
13.4% increase in response time with 1.000 users
16.9% increase in response time with 10.000
Forgot code layout..
The 2nd DAO should be attached to the first AS, not the Facade ofcourse.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3948292#3948292
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3948292
--
Even hashmap lookups get heavy when the map is loaded with a piles and piles of
objects.
On the DP's, don't kind yourself techniques come and go, the core DP's
(these are not limited to Java, but are universal) are pretty much forever.
But the problem is that I have an basic application:
But I wasn't asking what I should 'change' on the design... I was asking if it
can be done in the current design.
We are testing the EJB3.0 technique and, although easy to program, it is
lacking in some departments (we possibly overlooked something?). I would like
to be informed if my question
Not to start a discussion on development and design rules...
...But if you start treating Session beans like DAO's, you end up with:
A) Facade's with 10k line of code
B) Session Facades calling Session DAO's (which is a total waste of resources
since JNDI lookups, even internal ones, aren't exactl
How can I get a plain old DAO to function with the @PersistenceContext WITHOUT
turning the DAO into a bean of any kind?(since a DAO should obviously not be an
EJB)
This code fails when it is put to work as it is, but it works if I turn it into
a stateless Session.
| public class MyDAO
|
19 matches
Mail list logo
