JNDI Name problem in Facades when using Maven (and workaround)
Generate PrimeFaces Pages from Entity Classes in NetBeans
Status: Beta
Brought to you by:
kwrobel
Menu
▾
▴
Hi,
Great job!
I have bumped into a problem with JNDI Naming when using Maven. The problem is with Global JNDI name and maven deployment, so not specifically in your code. But I have found a workaround and I was wondering if it would be good to use it in your code, or if there are better solutions.
I have two related tables (e.g Employee and Unit with the idUnit in the Employee table).
If you Edit the table Employee and set a Unit you get a successful update message (this is the worst part in my opinion) when in fact it has not been executed. Going to the logs you discover an error that points to the corresponding Converter class (UnitConverter in this case) to the getAsObject method.
SEVERE: javax.naming.NamingException: Lookup failed for 'java:global/prototype2/UnitFacade'
Caused by: javax.naming.NameNotFoundException: prototype2
The workaround is based on http://stackoverflow.com/questions/2804365/jee6-global-jndi-name-and-maven-deployment
I have subsitute the line
lookupString = "java:global" + servletContext.getContextPath() + "/" + UnitFacade.class.getSimpleName();
for
lookupString = "java:module/" + UnitFacade.class.getSimpleName();
This solves my problem, but as I say I don't know if there are better solutions.
Cheers,
David
PS: The same example without Maven works fine.
Hi David.
Thank you for your feedback. I have to admit that while developing this
approach, I did not have Maven in mind at all. In fact, I am new enough
to the whole Java scene to not know too much about Maven. So, sorry for
my ignorance there. I am glad you were able to fix that specific part of
the code, and since it is inside a template, you're already good to go.
I have to check into the ability of the wizard to detect whether the
project is a Maven project, and then maybe pass a new boolean over to
the template engine to control that. Does that sound like something you
could work with?
Also what version of the project did you try? I am surprised that it
gave you a success message and in-fact had a Exception.
Kay
On 02/26/2013 10:34 AM, David Rodriguez wrote:
Hi Kay,
Not to worry, and thanks for your prompt answer. In any case I think your plugin is a great improvement over the default Netbeans CRUD JSF generator.
I am using Primefaces CRUD Generator 0.12.1 with Netbeans 7.2.1, Primefaces 3.5 running on Glassfish 3.1.2 (Mojarra 2.1.18).
I am quite new to Maven and JSF myself. I started using Maven for another project (with quite complicated dependencies) and I decided to give it a try with this, but it is not actually a requirement for me in this case. As I said I have tried to do the same without Maven and works fine.
The most problematic thing is the success message when the update is not working, and my solution is only masking it (well it is making it work for me, but I feel there is something else there that needs fixing).
Most surprisingly is that if you Edit other field of the entity (lest say a String like a name) at the same time as the foreign key one (Unit in my example) that part of the update will work (i.e. the name will be updated in the DB, but not the Unit). That is why there is a success message, but it is still wrong, everything should be updated or nothing.
So I have tried to debug the problem (reverting back my change). The NamingException is catched in UnitConverter.getObject and then the method returns null. Then in AbstractController the method save is called, and then persist,... etc. But the thing is that the Unit value in the entity passed is null, so it has not been set (the error occurs before the saving). That is the reason that the update is successful.
So finally, the problem is that in the entity setIdUnit method the value passed is null, and the actual user input is lost silently.
I am trying to find out how to solve this. I will send an update if I manage to do so.
Thanks,
David
Yes, I have actually noticed something similar that I thing is part of
that issue as well. When you have a one-to-many relationship and the you
have a drop-down list and if the field is mandatory. Say you select
"Select one..." instead and then hit save, it actually pretends to save
where in fact it doesn't. And that used to work beautifully at one point
in time, but I must have broken it, probably when I shuffled the while
converter thing around. So maybe if I find that problem and why it
thinks it succeeds, that might take care of your problem as well.
Hey, thank for helping out. And good luck with your project. Keep an eye
out for new versions as they come.
Kay
On 02/27/2013 04:53 AM, David Rodriguez wrote:
Hi,
I think I have found the problem: when a converter detects an error it should throw a ConverterException. So I think the getObject methods in the converters should be changed to
public Object getAsObject(FacesContext facesContext, UIComponent component, String value)
throws ConverterException
And then throw the exception wherever you detect an error in the method (in the two catches?).
It works for me. Now when I press Save the error message appear and the corresponding
control and label in the Edit form turn red :-)
BTW, this is independent of the Maven thing. I hope this helps.
Cheers,
David
Oh man, I should have read your second message first before replying to
the first. You know, this sounds exactly like what I was going to do. So
let me try that out and if that solves our problem, then great.
Thanks, David.
On 02/27/2013 05:02 AM, David Rodriguez wrote:
Thanks Kay.
That sounds good to me.
I will keep an eye out for the next release.
Cheers,
David
David,
Please try the new version 0.12.2 which I just uploaded. I changed the converters significantly as they are now
@ManagedBeans and thus accept the@EJBannotation for injecting the entity facade object. Hope this works in your Maven project. Please leave me some feedback. Ok?Thanks.
Hi Kay,
Yes, I will do. I just downloaded the new version.
BTW the default download in this version is the src package, is this intentional?
I will send you feedback after doing some testing.
Cheers,
David
No, this is not intentional, but SF sometimes doesn't get it right and I
don't know how to straighten it out. I'm really not too happy with SF.
It is very slow at times, too.
On 03/06/2013 03:39 AM, David Rodriguez wrote:
Kay,
I have just tested it.
Good job! It now works out of the box with or without Maven..
I think this can be closed.
Cheers,
David
PS: I have found an unrelated small problem, but I will put it in another post.
Nice! I like to hear that. This is truly the intention of Resource
Injection, that the container that manages the resource handles all of
that lookup load. I'm so glad this works now.
On 03/06/2013 05:08 AM, David Rodriguez wrote:
Yes, it is great news.
About the default download, have you tried with the "i" icon by the file. It should allow to set a given file as the default download for a given OS or all. Like this
I've tried that once in the past and it didn't seem to affect the file that's being used by default. I will try it again.