We Keep Coding

Do I need to extend ClassLoader to redirect web application resource loading?

My question is two-fold. First, I'll explain the problem, and second, assuming the solution is to implement a class loader, how to go about doing that on a web application.
My problem is this: Our company is using a framework made by another company. It uses xml files to generate web pages and these xml files are located within another library (jar files). It wasn't meant to be dynamic because these libraries are generated often (weekly?), but they determine how many fields there are, what type of information it collects (datetime, combo box, etc.), and so on.
Now the question has been proposed by my company whether or not it would be possible to dynamically move these fields around (by dynamic, I mean ideally you could refresh the page and see the effects of changes made to the layout). I did a few preliminary tests and discovered that modifying the xml does give the desired effect on the web page, however, since these xml files are located in the jars, it means I have two possibilities:
Create a tool which modifies the jar outside of the scope of my web application, though this would obviously imply that it absolutely cannot be dynamic. Moreover, I'd have to create an interface aside from the web application in order to manage the tool. Moreover still, I can't seem to shake the impression that this is an incredibly hacky approach and that I should probably avoid this solution at any cost.
I implement a class loader (specifically getResourceAsStream) and when I see a call to load one such xml file, rather than do the default behavior, I generate the xml file based on the original, modifying information as I require, then returning the resource to the caller (which in this case would be the third-party framework).
First question is, is #2 my best option or do there exist other options (or should I stick to #1)?
My second question is, assuming I should implement my own class loader, how best can I do this on my web application? I'm using Tomcat 7, but if possible I would like the solution to be independent of which web container I'm using.
Any help would be greatly appreciated!

You could probably simply explode the jar to a directory that is on the classpath and update the XML files in place and on the fly. This won't account for any internal caching within the application, (if any, that's a different problem) but it's straightforward to implement and doesn't put you in the shenanigan filled ClassLoader business.

I'm not sure if I understand your question.But I guess you could try using xstream api from thoughtworks.It can generate xml on the fly for you given a Java object and from this point on you can treat these xmls the way you do now to generate your webpages.
I know this answer is very trivialising however if this can lead you to a new api that can help you move to a new approach of generating xml with minimum fuss then I guess it would have served your purpose well.

Best Dashboard Architecture

I need to build a dashboard for an application, the dashboard will have different dashlets and each dashlet can have any one of the following things:
Graphs (JFreeCharts and some Javascript Chart)
Table data from tables
Data from external sources
Maps
What can be a good architecture for such kind of application?
What I have currently in mind is:
Each dashlet should have its own lifecycle and when the dashboard loads it should just show the UI of the dashlets initially.
After the page load each dashlet sends a server call (based on its type) to fetch its data
After the data has been fetched, each dashlet (based on its type) renders the data.

First of all, there are plenty of front-end frameworks to get you started. Some of the more popular ones include:
Backbone
Javscript MVC
Sproutcore
A bit of Google searching can yeild pros and cons of each and I would weight your options accordingly.
That all being said, the basic problem you posed actually seems similar to ours. In the end, we built something a bit different in house. Many of the frameworks out there are optimized to display a singular canonical "view" based on a Model reflected by the DB and a Controller to manage small changes. A dashboard has, in essence, a variety of different modules that must be doing their own independent things as you've mentioned in your question. Because of the high number of independent modules, I feel like you might feel pains in some of the frameworks listed above.
I can't tell you exactly how to implement such a module architecture, but here are some rules of thumb we used when designing ours:
Module Design:
Module-based. (Login module, Map module, each Dashlet may be a module, etc.)
Modules must have one Model, may have no more than one Collection (which is-a Model), and may have one or more Views.
A module may be used in multiple places and pages. The singular Model should stay the same, but the Views are likely different.
Rendering:
Almost all HTML on the page is written and updated by javascript modules. The template files are almost empty except for headers and basic scaffolding.
All modules render their full HTML selves and replace themselves into the DOM. The module should have as complete of a static HTML representation ready to go before inserting into the DOM. This means the render functions use “.replaceWith()” instead of “.append()”.
If simple HTML replacing isn’t an option (i.e. needs to be animated) a transition function should be defined detailing how to go from one rendered state to another.
Because rendering is expensive, Views by default do not auto-refresh on all Model changes. Re-rending happens through events only. _render() is in-fact an internal method.
Orthogonality:
A single inter-module event dispatcher on the page Controller handles all cross-effects between modules.
Modules should never “reach outside” of their own DOM context. If an event in one module affects another, it should go through the page controller dispatcher.
Each module as orthogonal as possible. They depend on each other as little as possible.
Each module in its own file.
Connecting to backend:
All modules use the same global backend adapter. Modules never talk to the backend by themselves. This makes your front-end back-end agnostic.
Recursive:
Modules are commonly included in other modules.
Modules re-render recursively.
Testable:
Because modules render static HTML, they can be predictably tested.
Modules must be testable.
Standard input -> Module -> Predictable static HTML output.
Standard events -> Module -> Predictable static HTML output.
If anyone knows of other frameworks along these lines, please share!

Our web app is based exactly on this architecture and in production since end of last year. You can see it at http://beebole.com
We just optimized the calls to our own server.
There is a single call to get the common data needed by most widgets, each time a screen is loaded.
Then if a widget needs additional data, it makes a call itself to our server.
The external widgets call their own data too, but to another server.

I would advise against using a custom web framework when there are so many free ones available.
As mentioned in another answer, the traditional MVC style frameworks don't really fit well to your 'dashboard' desired style of UI. They are best used for creating static web sites based on data retrieved elsewhere. They don't handle user interaction well and you usually have to hand roll your own AJAX to do anything useful without a page request.
A better breed of web frameworks to look at are the Web 2.0 fraemworks, also known as the frameworks which help you build web applications. It is important to understand the difference between web site and web applications. They are usually differentiated by the latter being interactive and the former being mostly static. Websites which also have some interactive components are still web sites. A good way to think of it is ask yourself "Does this feel like a desktop app?".
For web application development in the Java (JVM) realm, I would use Vaadin. It lets you write Java code similar to Swing programming, with event based methods. You can even avoid writting HTML altogether if you'd like by defining your views programatically. This lets you unittest your view logic (in web apps, there is more than usual) which is not posible with regular HTML template based frameworks. The other main advantage is that it has built in methods which allow you to write Java code to handle dynamic, asynchronous functionality and it all gets translated to JavaScript automatically. No need to write 4 different languages while writing your web app, just write Java for everything! Try it out, it is fun to work with!
Another web app framework that is getting alot of attention is Lift. I do not have experience with it but many devs I have spoken with have promoted it to me. I believe it uses HTML templates with Java code as the back-end. It is also apparently really easy to get started and your web app spun up. It also has built in support for doing AJAX like functionality. Worth looking into at least.
There are probably many more web app frameworks out there that would suit your needs. These all have the advantage of being tested, independently maintained, updated, and secure*. If you roll your own framework for this project, you need to worry about everything yourself. Written a web framework that doesn't offer anything new would be like written yet another programming language that isn't innovative; it is just a waste of time.

I think what you are looking for is more along the lines of managing or controlling your dashboard. I am designing something similar. I would suggest you look at google app engine it can be used to automate and control this: https://developers.google.com/appengine/docs/whatisgoogleappengine
Also look at these open-source dashboards: https://github.com/twilio/stashboard

Java, moving from desktop app to web app

I'm going to write my first Java based web app, and I'm sort of lost how to begin.
Firstly, I would like a web app and a desktop app that do pretty much the same thing, without the hackish idea of embedding a web browser into the desktop app because that doesn't allow to easily make changes to the desktop without affecting the web app and vice versa.
Now, here my questions.
Right now, I have a bunch of POJOs and they communicate with a single class that, right now, uses a flat file as a "database", of course, in production, I would use a legitimate database and just change that single class. Is this a good idea? Will I be able to go from POJOs to a web app?
Should I use a framework? I would like to have this app written pretty soon, seeing that all the buisness logic is there, I just need to wrap it so its usable, so, I don't want to spend an extreme amount of time learning, say, Spring (which AFAIK is huge), but, I don't want to keep reinventing the wheel throughout my app either. I can always just use JSP and scriptlets...
If you said yes to the above, what framework(s) do you suggest? Please note that I would like a framework that I can start using in maybe 3-4 weeks of learning.
Will I have to start from scratch with the POJOs that I have written? They're well over 30k LOC, so, if it is like that, I'll be hesitant.

You will need:
a web framework. Since you have Swing background, JSF 2 will be your best bet (everything will be painful, of course, but JSF will get you up and going quickly and will help you avoid the most tragic mistakes). Also, wrapping business pojos into web guis is the main use-case for JSF and it's biggest focus.
a "glue framework". One thing that is much different with web applications as opposed to desktop ones is that you cannot create view components by yourself - they must be created when browser requests a page. So you have to find a way to create the view objects and deliver all the references to the pojos that represent logic, some of which may have very different lifecycles (this is not a problem on desktop, but on web you have to distinguish between pojos that live along with the whole application, along with a single user session, along with a single request, and so on).
The "glue framework" could also provide the additional benefit of managing transactions. You have three choices:
Spring. It's not half as complex as you thing; you only need to learn some basic stuff.
EJB. You would need a real application server, like Glassfish or JBoss
bare JSF has good support for dependency injection, the only drawback is the lack of automatic transaction management.
If I were in your position, I would go with bare JSF 2.0 - this way you only need to learn one new technology. At first, try to avoid libraries like PrimeFaces - they usually work worse than advertised.
edit - and addendum
or - what is "dependency injection"(abridged and simplified)
When request comes to a web application, a new task starts in a new thread (well, the thread is probably recycled, but that's not important).
The application has already been running for some time and most of the objects you are going to need are already built and should not get created again: you have your database connection pool, maybe some parts of business layer; it is also possible that the request is just one of many request made during one session, and you already have a bunch of POJOs that the user is working on. The question is - how to get references to those objects?
You could arrange your application so that resources are available through some static fields. They may be singletons themselves, or they could be acquired through a singleton locator. This tends to work, but is out of fashion (hard to test, hard to refactor, hard to reuse, lifecycles are hard coded in application). The real code could look like this:
public void doSomething() {
Customer Service cs = AppManager.getInstance().getCustomerService();
System.out.println(cs.getVersion());
}
if you need clustering and session management, you could build a special kind of broker that would know and provide to anyone all kinds of needed objects. Each type of object would be registered as a factory under a different name. This also works and is implemented in Java as JNDI. The actual client code would look like this:
public void doSomething() throws Exception {
CustomerService cs = (CustomerService)new InitialContext().lookup("some_fancy_looking_name_in_reality_just_string");
System.out.println(cs.getVersion());
}
The last way is the nicest. Since your initial object is not created by you but by the server just after http request arrives (details depend on the technology you choose, but your entry point might be a JSF managed bean or some kind of action controller), you can just advertise which references you need and let the server take care of finding them for you. This is called "Dependency Injection". Your acts as if everything is taken care of before your code is ever launched. Spring or EJB container, or CDI, or JSF take care of the rest. The code would look like this (just an example):
#EJB
CustomerService cs;
public void doSomething() {
System.out.println(cs.getVersion());
}
Note:
when you use DI, it really uses one of the two former methods under the hood. The good thing is: you do not have to know which one and in some cases you can even switch them without altering your code;
the exact means of registering components for injection differs from framework to framework. It might be a piece of Java code (like in Guice), an XML file (classic Spring) or an annotation (classic EJB 3). Most of the mentioned technologies support different kinds of configuration.

You should definitely use a framework as otherwise sooner or later you'll end up writing your own.
If you use maven then simply typing mvn archetype:generate will give you a huge list of frameworks to choose from and it'll set up all of the scaffolding for you so you can just play with a few frameworks until you find the one that works for you.
Spring has good documentation and is surprisingly easy to get started with. Don't be put off by the pages of documentation! You could use JPA to store stuff in the database. You should (in theory) just be able to annotate your existing POJO's to denote primary keys and so on and it should just work. You can also use JSP's within Spring if that makes life easier.

... I a bunch of POJOs and they communicate with a single class that, right now, uses a flat file as a "database", of course, in production, I would use a legitimate database and just change that single class. Is this a good idea? Will I be able to go from POJOs to a web app?
qualified yes. if the pojo's are sane you should not have many problems. many people use hiberbate.
Should I use a framework? I would like to have this app written pretty soon, seeing that all the buisness logic is there, I just need to wrap it so its usable, so, I don't want to spend an extreme amount of time learning, say, Spring (which AFAIK is huge), but, I don't want to keep reinventing the wheel throughout my app either. I can always just use JSP and scriptlets...
probably. spring is huge, but things like grails or roo can help.
if you want to have a responsive web app, you will need to do some kind of rich client (AJAX). this may require a lot of your code to run on the client. this means writing a lot of javascript or using gwt. this will be a pain. it probably will not be so easy to just "wrap it". if you have written a swing app, then basically that code will need to run on the client.
If you said yes to the above, what framework(s) do you suggest? Please note that I would like a framework that I can start using in maybe 3-4 weeks of learning.
i like groovy and grails - grails uses spring-mvc, spring, hibernate. but there is roo, play and others.
Will I have to start from scratch with the POJOs that I have written? They're well over 30k LOC, so, if it is like that, I'll be hesitant.
the code that will run on the server can probably be mostly left alone. the code that has to run on the client needs to be rewritten in javascript or maybe you can get some reuse out of that code by using gwt,

The Play Framework is doing great things. I would recommend it highly. Having worked with EJB apps and Tomcat/Servlet/Spring apps it's a breath of fresh air. After framework installation you get a working app in a few seconds. Reminds me of Ruby on Rails or Node.js with the type-safety of Java.
Much quicker turnaround on getting started, faster development cycles, and a clearer configuration model than previous Java web app frameworks.
http://www.playframework.com/

How to merge common parts of WSDL and XSD from different services?

I have to interact with a set of web-services that each come with their own WSDL and XSD. The XSD are sometimes merged in a single file sometimes spread along multiple files (20-30). However, from experience I know that most of the message structure and data share a large common subset, perhaps only 20% are different amongst the different transactions.
Unfortunately I have no control over the server parts or the declaration of the services so getting them to fix it is out of the question. A first version of the client generated each services separately and then used them as individual facades to form a coherent higher level service as an adapter for another system.
I used CXF with the default JAXB binding and imposed different generated packages for each services. I did this because some most services use a common data model but not all use the same version or customization so I have conflicts and thus opted for the brute force so I can get the system done.
However, this causes the memory requirements of the adapter to go through the roof as each services load their context. Right now I have upwards 500M of memory utilized just for the adapter that houses the service clients even before I start sending requests and processing responses. Although I can run the system without problems using current situation this create constraints that jeopardize the deployment of the solution; my client would like to reduce this dramatically (60% or more) so that this system can be installed along side others without requiring hardware upgrades.
Question is follows :
Is there a tool or technique that would allow me to put the common parts of each transactions together such that they can be generated once and referenced where needed ?
I am not bound to CXF or JAXB other than the time required to re-factor the system towards a different framework or data bindings.
Thank you in advance for your help.
--- EDIT ---
Thank you Blaise. This points to a feature of JAXB that would be useful : episodes. Unfortunately I still need to extract the common base part of the different services. So now what I need is a means to extract this common parts through a structural diff, that is a diff tool that would be aware of the structure and type hierarchy the XSD describes so that proper references be put in place to connect the common sections with the specialized parts.

If you want to trim down a little, an alternative marshalling technology (in any framework) might do the trick - drop JAXB and try JiBX, which was added to the latest CXF release, or maybe just StAX.
Since you're looking to do something a little more custom than the conventional JAX-Ws/JAXB style services, you may want to consider Spring-WS.
Spring-WS gives you control over all aspects of the web services stack. It can route messages in different ways (payload, XPath expressions, etc), and you can use any marshalling/serialization technology you want (Jibx, jDOM, SAX, etc)
Here is a table that illustrates the options:
http://static.springsource.org/spring-ws/sites/2.0/reference/html/server.html#d4e1062
If you really want to get fancy, you can take one of the lower level APIs, start marshalling the message and once you hit critical mass for one of your common areas, start a JAXB marshall right on the spot.
The ability to route messages to different 'endpoints' (in Spring-WS) terms, means you can also do things like "accept any message" on this one interface (that looks like DOM/SAX/etc) and then have one big marshalling operation there.
The key thing Spring-WS will buy you here is to break out of the JAX-WS mold, do play a little up front game, and then you can always marshall back to JAXB later, whether it be in interceptors, your app, etc. In theor you can the same with JAXB DOM Source, but it's my opinion that the Spring-WS stack gives you the finest grained control for special situations like you have here.

The best trick is to serve a static wsdl. Just open the wsdl, save it, upload in the server and indicate to the client to point to the static one instead of the dynamic-self generated.

Editor for HMIs in Java

I found this question Creating SCADA diagrams in .NET and mine is roughly the same, except, that I need a Java version.
What I would need, is a editor which can be used standalone to create the GUI. It should support some kind of abstraction of datasources and data items which can be bound to the symbols placed on the view. It must be able to create symbols/components which may consist of other symbols/components and have some way to define the dynamic properties of those using some kind of expressions.
(for instance imagine a traffic light which consists of 3 separate lights but has only one data item associated. So it should be possible to define within the GUI some way which translates the value to a color of one of the sub components. Optimally it should be possible to parametrize the item names via some kind of expression, which would it make it more resilient to copy & paste errors if the items have a common naming schema)
The created GUI should be easy to integrate in a Eclipse RCP environment. Most solutions lack in some way or the other, either no abstraction of the datasource/items, no ability to set metadata on the symbols, or no way to promote value changes to the subcomponents in a easy way.
Any ideas?

I have came across (but never used) a product from ILog. I expect that it won't be cheap.

In the meantime we implemented our own HMI framework. It is still pretty rough around the edges, but for most of our use cases it works just fine.
Have a look at Eclipse SCADA http://www.eclipse.org/eclipsescada