The addition of the
Root
class in 7.0.0.alpha was a great advance, making it easy to map different URLs to different panels of your application.
Now in 7.0.0.beta1, the
Root
class has disappeared.
How now are we supposed to map for example
/foo
to one panel and
/bar
to another one??
Some refactorings in the Vaadin classes have been made for beta1. Especially, several classes have gotten new names which make much more sense than the old ones. I have noticed the following important renamings:
Root → UI
Application → VaadinSession
com.vaadin.terminal.gwt.server.ApplicationServlet → com.vaadin.server.VaadinServlet
Please correct me if I got something wrong here. Besides that, there have been a lot more refactorings.
OK, so then are you able then to configure a custom
VaadinSession
via web.xml somehow? If so what is the servlet parameter (and where is this documented)?
Thanks.
Don’t ask me about documentation, I found out about that while giving a Vaadin training course 
I figure the corresponding documentation will be provided anytime soon (hopefully).
You configure the VaadinServlet (not the VaadinSession) in the web.xml with the following snippet:
<servlet>
<servlet-name>My Application</servlet-name>
<servlet-class>com.vaadin.server.VaadinServlet</servlet-class>
<init-param>
<description>
Vaadin UI class to use</description>
<param-name>UI</param-name>
<param-value>com.example.myapplication.MyApplicationUI</param-value>
</init-param>
</servlet>
The rest remains the same.
OK but I think you’re missing my point:
In 7beta1 it doesn’t appear possible to map different URLs to different roots (i.e., UIs).
I can see that in 7beta1
VaadinSession.getUIForRequest()
is the method that determines the
UI
for a request, but how does one use this? Sure, I can override it, but there doesn’t appear to be any way to configure the servlet to use my overridden class because there’s no correponding servlet parameter.
I’m either completely missing something, or else 7beta1 has taken a great step backwards because now you can’t have multiple roots (aka UIs) in the same application (aka session).
The purpose was definitely not to disallow use of multiple UI:s - quite the opposite. There is now a separate facility called
UIProvider
to make this more flexible.
Unfortunately it seems that the traditional method of deploying multiple servlets - one for each UI is broken in beta1. Created a ticket for that
http://dev.vaadin.com/ticket/9619
.
Thanks for reporting this critical issue.
I don’t know directly what needs to be done, but I’m hoping either the migration guide or the Vaadin 7 wiki can help you out:
Here is an example on how to use UIProviders:
Deploy with your own custom servlet
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">
<display-name>Vaadin Web Application</display-name>
<context-param>
<description>Vaadin production mode</description>
<param-name>productionMode</param-name>
<param-value>false</param-value>
</context-param>
<servlet>
<servlet-name>Vaadin</servlet-name>
<servlet-class>t.t.MyServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Vaadin</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>
The servlet then chooses the UI
public class MyServlet extends VaadinServlet {
protected void onVaadinSessionStarted(WrappedHttpServletRequest request,
VaadinServletSession session) throws ServletException {
session.addUIProvider(new AbstractUIProvider() {
public Class<? extends UI> getUIClass(WrappedRequest request) {
String path = request.getRequestPathInfo();
if (path != null) {
if (path.startsWith("/ui1"))
return UI1.class;
if (path.startsWith("/ui2"))
return UI2.class;
}
return null; // No default UI set
}
});
super.onVaadinSessionStarted(request, session);
}
}
Couple of notes here. In almost all cases it would be better to use new high level views with
Navigator
instead of multiple UI:s. Multiple UI:s would be preferred over views when you want to have completely different UI for the same system - for example serving a mobile ui user agent is determined to be a smartphone.
This wiki article
also shows the same thing Joonas presented.
The tutorials in the wiki
is the best place to find what has changed and how to do them. Check them out
There is also a draft version of the Vaadin 7
Book of Vaadin
but it is not really up to date yet regarding the changes in Beta 1.
Thanks to all for the information about the new classes.
I’m a little surprised at how dramatically this central design element has changed between alpha3 and beta1.
On one hand, I’m very supportive of “creative destruction” as necessary to get things right. Better right than sooner.
On the other hand, next time I’ll think a little harder before trying out the next alpha release cycle. It’s cost a good bit of time having to keep adjusting. Guess that’s life on the bleeding edge.
I feel you, but it is a good thing that they change. We have lived now with Vaadin 6 for a few years and no API changes can be made in minors. Even IT Mill Toolkit 5 had the same API as Vaadin 6 has. Now, when we go to 7, there is a chance for API fixes that haven’t been possible to do earlier, and the next possibility to do them is for Vaadin 8 in a couple of years. It’s now or “never”.
I think there is a larger problem here. Bug #9619 is just a symptom of this larger problem.
I’ll try to describe it by way of how I’m getting confused/stuck trying to upgrade the
Spring Stuff
add-on to 7.0.0.beta1.
In 7.0.0.alpha3, the Spring Stuff add-on associates a separate Spring application context with each Vaadin
Application
instance. This made sense because
Application
was not a GUI component, rather it represented the overall Vaadin application, which in turn may have multiple browser windows with multiple GUI roots. Although there are multiple GUI roots, they share a single
Application
and therefore Spring application context - which is how it should be.
In trying to upgrade to 7.0.0.beta1, I can’t figure out what object to associate the Spring application context with, because you guys have deleted it.
Obviously the
UI
class is wrong, because a single Vaadin application can have more than one of those. It represents a single browser window, not the application (previously I was confused about this too but deleted that post!)
That leaves the
VaadinSession
. But
VaadinServlet
only supports one
VaadinSession
per HTTP session! This is a completely broken design, because that means a client can only ever run one Vaadin application at a time from a single server, which surely isn’t right.
In effect, you have squeezed out the very notion of “Vaadin application”. This is the very thing that Spring Stuff was designed to help with.
But #9619 reports that multiple servlets don’t work, which is true, but that is just a symptom of the 1:1 relationship between HTTP session and
VaadinSession
.
You need to put back an intermediate class “in between”
VaadinSession
and
UI
that represents the “Vaadin application”.
In relational terms there should be a many-to-one relationship between HTTP session and Vaadin application, and a many-to-one relationship between Vaadin application and browser tab (root, UI, whatever you call it).
7.0.0.beta1 is missing that intermediate “Vaadin application” entity. We had that back in alpha3 but it got nuked in beta1. Please put it back!
This depends on how you define “application”. The approach in Vaadin 7 beta 1 uses the default notion that one .war is one “web application”. Within the .war, you share classloader, you share static files and you also share session data. Why would Vaadin work in any other way?
If you want to have multiple isolated applications on the same server, you can deploy multiple .war files and rely on the isolation already provided by the servlet container. This works as long as you haven’t overridden the server’s configuration so that it shares sessions between multiple contexts.
One suggestion is that we could add API to VaadinService (which is 1:1 with VaadinServlet) to let you choose a key to use for retrieving a VaadinSession from the HttpSession but keeping the default to using the same key for all instances and just use the servlet container’s isolation. This would let you define how different servlets are grouped together.
So what you are saying is that you don’t need any help from Spring Stuff any more? Sounds like the feature here is that we have simplified Spring integration to the point where you don’t need any thing special to get everything working smoothly. 
What?!? You are looking at the world from a totally Vaadin-centric view and assuming that “Vaadin application” == “Web application”. That is a very brash assumption to force on the world.
Your statement is like saying, why would anyone put more than one Java Swing application into the same JAR file? Or, why would anyone ever want to run two different operating systems on the same computer? Etc. etc. Just because you can’t imagine an answer to a question doesn’t mean there isn’t one!
By the same logic, you’re saying that anyone who ever puts more than one
tag in
web.xml
is crazy!
I’m sorry but I think you are living in a little dream world. At a company I recently worked with selling enterprise software for $100K a pop (we hired Henri from Vaadin to help rewrite our GUI) our
web.xml
contains
six
different Vaadin servlets. These are all separate applications that operate independently but connect to a common shared underlying database/DAO layer, etc. They need to be separate so that, among many other reasons, they’re not all contending for the same Java lock during UI updates.
That would be great. Like I said,
something
is needed to support a many-to-one relationship from HTTP session to
VaadinSession
. And please allow this mechanism to be confgurable using a servlet
in
web.xml
(right now there’s not even a way use your own
VaadinSession
implementation).
I wish it were so. I would love for you to integrate Spring Stuff and take the load off my hands Right now though it’s simply not even possible for it to work on 7.0.0.beta1.
I work for the company Archie speaks of and as a paying Vaadin customer this change is completely unacceptable. I am not about to inflate my deployment by 5 orders of magnitude to deploy 6 different WAR files. Archie is correct; assuming one Vaadin application == one WAR file is a naive and presumptuous assertion on Vaadin’s behalf. I expect my users to be able to launch one instance of every Vaadin app I provide in my
single
WAR file in their HTTP session. This will need to be fixed or my company will not upgrade to Vaadin 7 and if we’re not going to upgrade there is no point in maintaining any PRO accounts or paying for any Vaadin services.
One logical application sharing code, data and settings in one .war is an assumption made by the Java EE specification and nothing that Vaadin 7 has invented.
I see many use cases for having multiple servlets in one web.xml, but I see even more use cases for isolating servlets that aren’t designed to live together into separate .war files.
How do you define the boundaries between different apps in the same .war sharing the same classloader and the same static files? The different “apps” would still have to be aware of each other e.g. as they can’t use different versions of the same 3rd party libraries and you’d also have to explicitly manage how URLs are mapped and where static files are placed to avoid conflicts.
How do other web application frameworks handle isolation of multiple logical apps within the same .war?
Why do you want to use different VaadinService implementations? VaadinService is designed as a simple data storage class without much more logic than a couple of simple setters and getters (although there are still some methods and two subclasses that will be refactored before 7.0.0). I think you’re attempting to use the class for something that it hasn’t been designed for if you need to use different implementations of VaadinSession.
#9733
will provide a way of isolating different servlets from each other for the presumably rare cases where some isolation is required but full isolation is not possible. It will most likely be based on
because we don’t want to provide a Java API that in the future would be incompatible with the pluggable state storage mechanism that has been planned but not yet designed nor implemented.
Full Spring integration in the Vaadin core would most likely require having Spring on the classpath, which is not an alternative because we don’t want to force everyone to use Spring.
Yes…
for some definition of the word “application”
. Your error is the claim that web “application” and “Vaadin application” are the same thing. These are NOT the same thing… and I can prove it simply because I know of several counter-examples!! Not to mention 1000+ Spring Stuff add-on downloads.
Maybe you have never personally experienced a situation where they are not the same thing. That’s fine. Just don’t then assume that this will be true for the entire rest of the world.
Analogy from history: people used to think “The Internet” and “Internet Explorer” were the same thing, because they never used them separately. You are making an analogous mistake.
I’m glad you asked. Maybe some explanation will help!
You Vaadin guys seem to think the world revolves around Vaadin, as if the only type of Java object in the world was the Vaadin widget. But in a large enterprise application, Vaadin is just one small component/toolkit in a much bigger picture. There are all sorts of other things going on in the server backend: data flows, threads communicating with external systems, etc. The “Vaadin application” is a relatively small component that provides a web browser client with a view into the overall application. It’s really just a “view.” And as with any complicated system, there are several different such “views” that may need to be instantiated at different times and/or at the same time.
For example, you might have an administrative view, a user view, a reporting view, a service view, a 3rd-party view, etc. Each of these views has not only Vaadin widgets of course, but also a host of other backed supporting objects that exist to support that view (such as data-backed containers, etc).
Finally, at the lowest layer, all of these views share a common base set of objects such as DAO’s and service beans, not to mention classes, libraries, and resources. It’s all one big “enterprise application”, and it’s all one big “web application”, but it has multiple independent (relatively small) “Vaadin applications”, which are just “views” in the general sense.
For scale an efficiency reasons, we cannot instantiate all of these “views” at the same time. Not only would that be stupid and wasteful, but it doesn’t scale from a performance point of view, because having a single view (aka. Vaadin application) creates too much contention on a single, shared lock, when the same user wants to e.g. use the system while they keep open a continually refreshing dashboard.
But look: I shouldn’t have to justify this to you. The very fact that many people are using this kind of entirely reasonable setup should be sufficient evidence to support it. For large enterprise applications, there are good technical reasons for it. But even forget all of that: you should just be letting people do what they want to! Instead of fighting them based on your own assumptions and experience.
In fact, why are we even having a debate about this? The very fact I’m having to explain this to you makes me wonder if you guys really understand or care who your customers are. Simply put, you are being arrogant. You think you know how everyone else is going to want to use Vaadin. That’s a dangerous attitude to have for a project based on open source, especially when you’re also trying to build a business based on that project! Business that think they know everything and don’t understand their customers always end up as so much more roadkill.
I understand that you are trying to simplify things - that is a worthy goal, but in the process you are confusing “simplicity” with “eliminating choices”… these are not the same thing, and the latter can really piss people off.
I think you guys could really learn a lot by studying the Spring Framework codebase (I know I have). Good software design is hard, but they do as good a job as anyone. You need to understand the open/closed principle and the importance of good Javadoc. Most importantly, achieving power and flexibility without unnecessary complexity by having good class hierarchies, lots of interfaces and configurability, and relying on “convention over code”. Vaadin classes are to often difficult to subclass because all extensibility methods are private or don’t exist, so the only option is to copy and paste the whole thing into a new class, which kills maintainability.
When designing code and APIs for an open source project, instead of asking “Why would anyone ever want to do that?”, ask “How can we enable possibilities that we ourselves can’t even imagine?”
You said
VaadinService
but you meant
VaadinSession
correct? (I don’t think there is any problem with
VaadinService
).
Specifically I have two problems:
#1 is self explanatory. All that’s needed is some way to parametrize the HTTP session keys on a per-servlet basis. This can easily be done with a new, optional
.
For #2, one way to do this is with another new, optional
that allows you to specify a custom subclass of
VaadinSession
. This was my first thought, but there are probably simpler ways. For example, just add
onApplicationStartup()
and
onApplicationShutdown()
methods to
VaadinServlet
so that I can subclass that instead.
So while there is a lot of design argument here, from a practical point of view, this is a trivial issue to solve without altering the 7.0.0.beta1 APIs.
Of course my comment was in jest. But in any case, what you said is not true. With a proper class hierarchy, nobody would be forced to do anything. You can easily segregate classes that depend on optional 3rd-party libraries so that people who don’t need them don’t need to touch them. Again, Spring shows how to do this correctly. Their code is works with zillions of 3rd party libraries, but the code is all properly modularized so that you only have to use what you want/need.
When we talk about Vaadin 6 and the Application class it is something different than most people understand by “web application”. For most people a “web application” is a war file. This has caused a lot of confusion during the years of Vaadin 6 because of the naming of the Application class. We can also see it causes confusion in this thread.
In Vaadin 6 a “web application” can contain many servlet mappings, many Application classes and many Window classes, all bound together in one ApplicationContext, which is stored in the HTTP session. When the user opens a given URL, the corresponding servlet is used and based on the servlet an Application class is retrieved from the ApplicationContext and used for the request. In other words, there is one session per “web application”, each user has one ApplicationContext and N Application instances (each Application instance can have M Window instances, in many cases only a main window is used).
In Vaadin 7 this has been simplified by removing the Application level from the description above. After some renamed classes the architecture in Vaadin 7 is that a “web application” can contain many servlet mappings, many UI classes, all bound together in one VaadinSession, which is stored in the HTTP session. When the user opens a given URL, the corresponding servlet is used and based on the servlet a UI class is retrieved from the VaadinSession and used for the request. In other words, there is one session per “web application”, each user has one VaadinSession and N UI instances.
In Vaadin 6 you always create you own Application sub class. In the simple (and very typical) case, you create one MyApplication class, map ApplicationServlet to the root of your context and make it use MyApplication. In Vaadin 7 this is equally simple, you extend UI instead of Application, map VaadinServlet to the root context and make it use MyUI.
A more complex way of using Vaadin 6 is to use multiple application classes and multiple servlet mappings in the same war file (“web application”). In this case you have multiple XYZApplication, ABCApplication, … classes maybe serving different parts of your whole “web application” (all *Application instances are still bound together by ApplicationContext).
Some reasons for using multiple servlets are:
Are you looking for 3) above or something else?
Are you looking for 4) above or something else? Not exactly sure what you mean by “closing”. If you are talking about closing the Application in Vaadin 6 you are probably calling Application.close from a handler and already have somewhere to place this code(?) If you are talking about closing a browser tab, then a UI cleanup event handler would be more appropriate although it will not necessarily fire immediately (uses a heartbeat in Vaadin 7).
There are probably a few more reasons why you want to use many servlets. Mark, Archie and everybody else, if you have a particular one which you do not see how you could solve with Vaadin 7, please post it and we’ll answer you.
If you have some comments on the API, naming or similar and have concrete suggestions - please create one or several tickets at http://dev.vaadin.com.
I can’t see a way to get what I’m looking for with the new beta1 APIs.
Maybe the best approach is for me to explain what I’m trying to do, and you tell me how to do it in beta1.
Suppose we want the following:
You can see that this is all about correct and precise state and lifecycle management. We cannot tolerate creating state unnecessarily, nor memory leaks, or nor global locks. Each of ABC and XYZ have a bunch of non-Vaadin Java objects that need to be created/destroyed along with them to avoid memory leaks, etc.
We had a simple way to do all of this in alpha3. In beta1 I simply cannot figure out how I’m supposed to do it anymore.
Please tell me, how can this be done with the beta1 APIs??
I’m talking about closing the Application. This can occur either via some explicit close() method, or implicitly after a timeout or HTTP session timeout. This all works in alpha3 just fine.
Sorry, I was in a bit of a hurry when writing the response and forgot to mention I was talking about beta2 API where this has been improved a bit.
The “do not share any state” is not strictly true in either Vaadin 6 or 7 in the sense that they are both stored in the shared HTTP session and one can access the state of the other if it wants to. Regarding locking, the locking in Vaadin 7 is done on VaadinSession level, which means to get as far as locking parts of the HTTP session you need to get multiple VaadinSession instances. Something which should be possible once we get #9733 implemented. If you are fine without individual locking, then beta2 should work for you.
Regarding closing there are basically the cases:
I think you can get quite far with beta2 and even further once #9733 is implemented.