Re: Issue with using JPA in openejb
On Jan 2, 2009, at 1:51 AM, Debarshi Sanyal wrote:
Hi All,
New Year greetings!
Happy new year to you too!
I was trying to execute the example on EJB entity-manager provided
at *
http://openejb.apache.org/3.0/injection-of-entitymanager-
example.html.*
I have replaced the test case with a standalone client that, however,
performs exactly the same steps. However, I observed that while
insertion to
the database is occurring perfectly, the deletion does not take place.
Movies movies = (Movies) context.lookup("MoviesLocal");
movies.addMovie(new Movie("Quentin Tarantino", "Reservoir
Dogs", 1992));
movies.addMovie(new Movie("Joel Coen", "Fargo", 1996));
movies.addMovie(new Movie("Joel Coen", "The Big Lebowski",
1998));
List list = movies.getMovies();
assertEquals("List.size()", 3, list.size());
*for (Movie movie : list) {
movies.deleteMovie(movie);
}*
Even after the previous steps, *movies.getMovies().size()* returns 3
which
is very strange.
That is very strange. I'm not sure what could be happening. When in
doubt add a entityManager.flush() statement and hope for an error
message :) (useful debug tactic with JPA -- just make sure to remove
it in production as it will affect performance) In this case I'd add
it right after the entityManager.remove(movie); call.
Hopefully that will dig up something.
Also double check that one of your modifications did not involve
deleting "PersistenceContextType.EXTENDED" from the example. That
could cause the issue as well -- entityManager.remove(foo) only works
if the object passed in is still "attached" [1].
-David
[1] Attached/Detached explained here
http://openejb.apache.org/3.0/jpa-concepts.html
Re: Non daemon threads launched by Timer service and not properly stopped
On Dec 31, 2008, at 5:30 AM, uglything wrote:
PS : I wish you all a nice new year eve !!!
Happy new year to you!!
PPS : I'm trying to make my managers switch to OpenEJB 3.1, I'm
particularly
interrested in the Singleton mechanism. Many thanks to the OpenEJB
crew for
it's amazing work at sticking to both the EJB specs and user's
expectations
!!!
Thank you very much. We do our best not to make extra work for
users. I like to think we're having a positive impact on the EJB spec
itself as well. Time will tell if people like some of the things
we've been able to get added (like the embedded ejb container
stuff ... or most recently a simple annotation @StatefulTimeout so
that you can specify the timeout of your stateful session bean in a
portable way. Look for that in the next 3.1 public draft).
My application contains stateless session beans with @Timeout.
Everything runs smoothly, until I try to stop the application.
After some debugging, it appeared that two non-daemon threads are
still up
after OpenEJB has returned from its shutting down routine. (they are
named
pool-1-thread-1 and pool-1-thread-2 for me). I think they prevent
the VM
from exiting.
These two threads seem to be started from the timer service.
A snipplet of the code I found in
org.apache.openejb.core.timer.EjbTimerServiceImpl:
public EjbTimerServiceImpl(DeploymentInfo deployment) {
this(deployment, getDefaultTransactionManager(),
getDefaultExecutor(), new
MemoryTimerStore(getDefaultTransactionManager()),
1);
}
public static Executor getDefaultExecutor() {
Executor executor =
SystemInstance.get().getComponent(Executor.class);
if (executor == null) {
executor = Executors.newFixedThreadPool(10);
SystemInstance.get().setComponent(Executor.class,
executor);
}
return executor;
}
---
I couldn't find any code shutting down the executor.
To work around this problem, I add in a ServletContextListener the
following
specs-breaking code:
public void contextDestroyed(ServletContextEvent arg0) {
try {
((ThreadPoolExecutor)
EjbTimerServiceImpl.getDefaultExecutor()).shutdown();
} catch (Throwable t) {
// We did what we could...
}
}
---
As expected, the server shuts down smoothly now.
I'm not sure if this is a bug or not, i might have misconfigured
smthg.
This is definitely a bug.
If we added that that shutdown call to a "finalize" method in
EjbTimerServiceImpl that might do the trick. Easy change to make but
harder to test. Seems like you're already setup, if you wanted to
give that a try and give a thumbs up or thumbs down, that would be
fantastic -- would be a big help and we love new contributors. If
not, I can add that in a push up some binaries that you can test out.
Added a bug report for it: https://issues.apache.org/jira/browse/OPENEJB-983
Either way, thanks for finding this!
-David
Re: Unauthenticated principal
On Dec 30, 2008, at 3:51 AM, Luis Fernando Planella Gonzalez wrote:
Well, my problem is not really configuring the default (or
unauthenticated)
username, but it's roles.
We should already be adding a role of the same name so that people
could do as you demonstrate below. I've checked the code to be sure
and it looks like that is the case.
I'd like to annotate EJB methods like this:
@RolesAllowed({"public", "broker"})
public void x() {}
@RolesAllowed({"public", "admin"})
public void y() {}
@RolesAllowed("admin")
public void z() {}
I tried this out in embedded mode using "guest" instead of "public"
and it worked fine. Should work the same way in Tomcat.
Give the code above a try in Tomcat but with "guest" in the
RolesAllowed instead of "public". If that works as I suspect, than
making the change to allow the default username to be changed should
do the trick.
-David
