Akaine Harga

No need to be rude.

1. When I submitted my post there were no answers on stackoverflow.
2. While others gave me the right ideas, I've answered it myself.

You're welcome to delete this thread

Hello everyone,

I'm trying to create a mouseOver visual effect for several JLabel elements filled with text. The idea is to make each label darker when mouse enters and then return it to normal when the mouse leaves its area. Also all the labels are placed over a panel that has a background image.

Though simple enough, I've encountered a nasty behavior I can't overcome.

Bug 1: The first time I move mouse over a label it shows me the upper-left corner of my main window as its background.

Bug 2: Then, every time I move mouse over one label once, and then move it over the second label, the second one changes its background to the "summ background" (panel image + semitransparent background) of first label. Above that it seems that even the first label's text contents are being "copied" to the second label's background. This only happened once per label change: if I move mouse over the same label twice, the second mouse over event is painted correctly.

I've already tried to use MouseMotionListener, a different element (JButton), played with component modification methods and eve tried to override paint methods. No result.

I've attached an animated GIF showing the described behavior:


I'm relatively new to Swing so I'm not familiar with its caveats. Any idea what might cause this?


Custom Panel class:
public class ImagePanel extends JPanel{ private static final long serialVersionUID = -3995745756635082049L; private Image image = null; public ImagePanel(Image image){ this.image = image; } public void paintComponent(Graphics g){ super.paintComponent(g); if(image != null){ g.drawImage(image, 0, 0, this); } } }
MouseListener class:
public class MouseHoverPiece implements MouseListener{ private static final Cursor CURSOR_HAND = new Cursor(Cursor.HAND_CURSOR); private static final Cursor CURSOR_DEFAULT = new Cursor(Cursor.DEFAULT_CURSOR); private static final Color HOVER_SHADOW = new Color(40, 80, 60, 50); @Override public void mouseEntered(MouseEvent e) { JLabel component = (JLabel)e.getComponent(); component.setBackground(HOVER_SHADOW); component.setCursor(CURSOR_HAND); component.setOpaque(true); component.repaint(); } @Override public void mouseExited(MouseEvent e) { JLabel component = (JLabel)e.getComponent(); component.setBackground(null); component.setCursor(CURSOR_DEFAULT); component.setOpaque(false); component.repaint(); }
MainWindow class:
Image background = ResourceLoader.loadImage("board.png"); ImagePanel panel = new ImagePanel(background); panel.setBounds(10, 55, 480, 480); panel.setLayout(null); panel_main.add(panel); final JLabel lblNewLabel1 = new JLabel("N"); lblNewLabel1.setHorizontalAlignment(SwingConstants.CENTER); lblNewLabel1.setOpaque(false); lblNewLabel1.setBounds(25, 24, 52, 52); lblNewLabel1.setFont(lblNewLabel1.getFont().deriveFont(42f)); lblNewLabel1.addMouseListener(new MouseHoverPiece()); panel.add(lblNewLabel1); final JLabel lblNewLabel2 = new JLabel("O"); lblNewLabel2.setHorizontalAlignment(SwingConstants.CENTER); lblNewLabel2.setOpaque(false); lblNewLabel2.setBounds(25+52+2, 24, 52, 52); lblNewLabel2.setFont(lblNewLabel2.getFont().deriveFont(42f)); lblNewLabel2.addMouseListener(new MouseHoverPiece()); panel.add(lblNewLabel2);

The answer is simple. When you bind a property to view its getter is invoked every time you load the view. In this case JSF sees greeting as a property of the user object, so it invokes the method as soon as you load the view. And since name is null at this point you get the nullpointer exception. Recommended approach: in the getGreeting() method check name for null before checking its length. Alternative approach: initialize name with an empty string.

My question is general, for any "known" common data structure (as I mentioned in my first post): entity beans with fields consisting of primitives, wrappers from java.lang and other entities linked by the foreign keys. Normally knowing the bean structure is enough to make a relatively efficient custom serialization.

1. Java serialization: https://github.com/eishay/jvm-serializers/wiki
2. Serialization in JPA: http://java-persistence-performance.blogspot.mx/2013/08/optimizing-java-serialization-java-vs.html

It is a well known fact that java.io.Serializable is one of the slowest serializers out there. So in many cases when long response time is an issue to gain a couple of milliseconds programmers recur to alternative serialization methods. These days one of the fastest serializers is Kryo, but its main problem is that it can't be used in conjunction with other popular frameworks (Hibernate, EJB, Spring, etc.) without their explicit support of this particular serializer or their modification. So as an alternative many people use java.io.Externalizable interface instead putting their own serialization implementations that override the methods used by the Serializable interface.

The question here is: What would be the most efficient Externalizable implementation for common entities (beans containing primitives and java.lang wrappers)?

Well, as I mentioned in my first post the question was about Primefaces based views. So I do have loads of jQuery, just not written manually. This is the problem: I already limit my requests to 1-10 parameters and update only the parts I need to update (as far as PF allows me to), and it's still slow. That's why I started to talk about "Should I forget about JSF as a "quick-to-build" web app dev tool? The apps look nice, they require little coding, but they are slow. And with the Internet connection becoming faster each year people will start complaining more and more.

Tim Holloway wrote:Of course, you could hack it by stacking multiple 1-row tables to look like a multi-row table. I've pulled stunts like that on pre-JSF HTML apps. Eek.

That's exactly the perverse stuff what I was doing to my heavy views. But this is called "putting crutches so the skyscraper wouldn't fall". We are hitting the WebMVC's limits here, aren't we...

Tim Holloway wrote:Speaking of unrealistic expectations, did I ever mention the project they gave me back in my mainframe days? It consisted of a 7-level report done multiple ways. We estimated that each daily run was going to consume 2 and a half 2500-sheet boxes of fanfold paper and propably no more than a page or 2 of the report would ever be actually looked at at any given time. Fortunately, we managed to persuade the users in the direction of sanity.

XDDD In my experience, sanity usually is the opposite of reality.

It highly depends on what classes and methods of this library you will actually use on a runtime level. Chances it will function, chances not. Normally, JRE is backward compatible (old libs should run on later JRE versions).

Also, if the library in question is relatively small, you can always decompile and recompile it. Or even write your own library from the scratch by reverse engineering the original jar. On several occasions I had to use complex old libs that did magical stuff (COBOL adaptors, banking transactions assemblers, etc.) where adaptation/recompilation was the only way to solve the problem.

As far as I see your current architecture does not support CDI. Add the @ManagedBean annotation to OccupantRegistration class and the exception you get will be gone. The problem has nothing to do with @PostConstruct. This annotation is only usefull when you want to preload something on a managedBean construction (execute some queries, make some pre-render calculus).

Thanks, guys. A lot of interesting comments here.

I always limit all my requests using ajax partialSubmit and listing specific ids to submit, so no whole form requests here. Same with updates: I rarely update an entire container. But, as Tim Holloway mentioned, sometimes it's impossible to update only one subtable's row using just PF.

E Armitage wrote:Generally, JSF (these days) is best when you are taking advantage of the automatic property binding to backing beans as you would in CRUD pages. You're better off using stateless views for dashboard type pages with data fetched via AJAX rather than trying to fit that into JSF's bindings. You can still use JSF for the page (to take advantage of templating or for uniformity with other pages) but rather use restful services for getting the data from the server and use JQuery to fetch the data and set it on the page controls.

You mean I should forget about property binding and manually use jQuery for data fetching and view updates? And that without mentioning the stateless views. But wouldn't that multiply the required time for coding, code complexity in several times and render the best JSF's feature (variable binding) just useless? I'm not entirely against the idea, I just need time to get used to it, I guess.

Actually, guys, one of the purposes of my post was exactly this:
Is JSF (or any other "automated" WebMVC) good for heavy views? Or am I actually hitting the limits here? I was considering to move to JavaFX8 for some time by now. As far as I understand I won't have any of these problem there. Or even forget Java completely and move to .Net SOA based apps. Because the idea of spending weeks of jQuery coding for a relatively simple functionality doesn't appeal to me as the most optimal (time/cost) solution.

Any thoughts?

I've been working with JSF1/2 and Primefaces for a few years by now and many times I ended up with clients complaining about page response times. My answer in most of these cases is: "What do you want? You've asked me to put half of the whole application's functionality on one page. Of course it will be slow." Yes, I'm talking about those pages where the client wants too see and control just everything, when even if а mosquito that flies by suddenly farts, the page should show it. So, on a functional level I see no problem: we put a dozen of containers here, dozen of buttons there, some more output containers over there, and everything is freakin' dynamic, of course. I certainly try to minimize the messages that are being sent or received to/from the server limiting them almost to numbers and Strings, but this is not enough.

The main problem, as far as I see it, is the partial DOM update, where I have to rerender certain parts of a page (and sometimes almost the whole page) to update the data. And, holy ***, this does take time. And the more complex your view structure is - the more time these DOM updates take. So in the end depending on the page's structure it could take 20 or even 40 seconds to see the update, especially on mobile devices. I understand this is a jQuery/JavaScript related problem, but I don't believe I'm the first one to raise this topic.

Are there any methods to optimize or reduce a complex JSF/Primefaces view response time without sacrificing all the epicness of web2 concept?

To clarify the case I am talking about let's see a real-life example.

I have a quote creation page for a house repairs company (page image).
This page allows user to create unlimited stages of repairs. Each stage can have an unlimited number of sections or areas. Each section/area can contain an unlimited number of repair jobs. Each time a job is added/modified the area subtotals and grand totals are being updated (job cost, materials cost, completion time, etc.). So in this particular case while a small number jobs is handled (10-30) all is fine. But when we pass to hundreds each new operation begins to take more and more time, until the response time is just "not acceptable".

I've already spent some time trying to optimize it, but I it seems I cannot solve this problem alone.

Any suggestions?

Any IDE would be OK since I strongly do not recommend relying on those fancy (and also very limited) visual designers, which means at the end of the day you'll be working directly with source code (jsp, xhtml, java). The problem with any of visual editors is their very limited usefulness, since they can't show you anything but the most basic html/jsp structure you create. So if you are not planning to make just crude primitive scriptless views, don't use them. I'd say more, turn them off setting a default xhtml/jsp editor instead.

At the top of the ladder are: MyEclipse, NetBeans, Eclipse and IntelliJ IDEA. While the last one is probably the most advanced IDE (by its built in functions and some unique minor features), it is also the most different IDE compared to the rest. This means that if you grow too accustomed to it, at some point you will automatically hate (and I mean it) all other IDEs out there. And IntelliJ IDEA is not a common choice for most of Java development companies. So as a personal recommendation I'd go for Eclipse or Netbeans as they are the most common choice in dev teams as well as the fact that they are free. And if you don't mind to spend some money, MyEclipse is a great choice for any JavaEE developer.

Hope it helps.

Hello,

I have a WL configuration/deployment question. I have several EAR applications where some apps depend on the others to start. While it's not a problem when the apps launching is done manually, the deployment order is not enough when doing a complete server restart with the automatic launch of all installed apps, since my "primary" apps require certain time (several seconds) to completely launch themselves, and only then the others would start correctly.

The question is: Is it possible to set wait time for one application autodeploy so the other would wait that time before it's automatically deployed as well?

If yes, could anyone point me to the right direction, please? Because the WL12c online documentation doesn't help a bit.

Thanks and regards

Ok. I didn't understand you the first time because I did not see two inputs, just one.

The problem you have is related to how JSF works. The command button by default submits only the form it resides in. So to be able to update the "view model" submitting both values, both inputs have to be inside the form where the command button is. Once you have the managed bean's variables updated the rest is trivial. The correct xhtml code would be:
<h:form id="TbtestCreateForm"> <p:inputText value="#{tbtestController.selected.name}" /> <p:inputText value="#{tbtestController.myHardcodedValue}" /> <p:commandButton actionListener="#{tbtestController.saveNew}" value="#{myBundle.Save}" /> </h:form>

I see you use Primefaces namespace. In this case you can specify the input fields or the wrapper element that contains the input fields you want to submit by specifying the partialSubmit="true" and process="listOfIdsOfTheElementsToSubmit" (http://www.primefaces.org/showcase/ui/ajax/partialSubmit.xhtml). This ca help you minimize the data sent to the server in case you have more input fields in the same form.

On the other hand it sounds pretty strange to me you want to submit a "hardcoded" value in the first place. By looking at your example I can see it comes from the managed bean. Why don't you just use it as a local variable inside the managed bean itself instead of submitting it, since the hardcoded value won't change anyway.

Btw, what are you trying to do in general? Is this some kind of combo field simulation?

Not sure what you ment by "hard code/set manually the string value in the form and store it in database along with the int value informed by the user, in the same operation (the same object)."

Anyways here are some observations:

1. Not sure of you need both actionListener in commandButton. You can easy use action attribute which is the primary managed bean method called after clicking the button. ActionListener is normally used when you need to execute something before the main action method is called.

2. If you use EJB pattern as you mentioned it's much easier to inject the EJB interface using @EJB annotation thus making available the Facade's local interface in the managed bean.

3. Just for the notice. @SessionScoped managed beans maintain their scope during the entire user session. Not sure if that was your intention. If you need to maintain the managed bean while being on a particular page only the usage or @RequestScoped or @ViewScoped is recommended to avoid unpredictable behavior.

4. I see you have a middle layer method called persist(). In most small/medium sized applications there is no need for the middle layer in case you use JSF and EJB. A good and clean approach would be to have managed beans containing the atomic methods realizing their correspondent view actions and EJBs (Facades) containing persistence related methods. As I mentioned before the session beans can be injected into the managed beans directly by using @EJB annotation.

Example: http://www.developer.com/java/ent/integrating-jpa-jsf-and-ejb-in-java-ee7-applications.html
A nice tutorial: http://netbeans.dzone.com/articles/develop-java-ee-6-app-jsf2

Hope it helps. If not, please specify your question.