I have a Silverlight application that uses a custom DomainContextGenerator and a custom EntityGenerator:
[DomainServiceClientCodeGenerator("MainCodeGenerator", "C#")]
public class HrCodeGenerator : CSharpClientCodeGenerator
{
protected override EntityGenerator EntityGenerator
{
get { return new HrEntityGenerator(); }
}
protected override DomainContextGenerator DomainContextGenerator
{
get { return new HrDomainContextGenerator(); }
}
}
This class and the referenced generators are contained in a class library referenced by the Host-project of the Silverlight application.
When starting the application in VisualStudio 2012 everything works fine and when I open http://localhost:12345/My-Namespace-MyService.svc in a browser I can see the landing page of the service. When deploying the application to the IIS however the on-the-fly-generation of the .svc-files fails and when opening http://dev.example.com/My-Namespace-MyService.svc I just receive a HTTP 404.
After removing the HrCodeGenerator-class from the project (removing the DomainServiceClientCodeGeneratorAttribute won't do the trick), everything works fine.
Do you have any hint on why it behaves that way and what I can do to prevent that from happening?
I finally solved the issue.
The classes responsible for the client code generation were located in the same library as the services itself. I moved these classes to the web-application project that gets deployed to the server.
I still don't understand how code that gets executed at compile time only and only affects the client side of the application can possibly influence the runtime behavior of the server side of the application. I also don't understand why moving the components to another project fixed the problem.
But as a colleague of mine states: "Sometimes engineering is indistinguishable from magic..."
Related
Recently I started a new Asp.Net core application 1.0, and copied some existing code across from another project. After adding a considerable amount of code, and getting it to compile, I found that starting the application, appeared to start up, but when it tried to hit the Home controller to get the start page of the application, the browser reported it could NOT reach the web page. Reported a This site can’t be reached message (as if the web application was not running). This was very frustrating as the app used to work fine before I added all this extra code.
I ended up having to go back and start a brand new application (in the same project), and add components back into the project one at a time, till i found the thing that had caused this issue. A frustrating day passed where I could not get any errors from the server at all regarding why it failed to find the web page.
After a lot of menial work and cursing, I eventually tracked down the issue.
The issue was that I had added some support to do the database seeding as part of the Configure method of the Startup class. I had made this a Async Static Method, and called the method using an await inside the Configure method. Naturally I had to make the configure method Async which I did.
The reasons for adding these awaits, were so I could use Async calls within my DatabaseSeed method call
public class Startup
{
...
public async void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
...
using (var serviceScope = app.ApplicationServices.GetRequiredService<IServiceScopeFactory>().CreateScope())
{
serviceScope.ServiceProvider.GetService<ApplicationDbContext>().Database.Migrate();
await DbExtensions.EnsureSeedData(app.ApplicationServices);
}
...
}
}
public static class DbExtensions
{
public static async Task EnsureSeedData(IServiceProvider serviceProvider)
{
using (var serviceScope = serviceProvider.GetRequiredService<IServiceScopeFactory>().CreateScope())
{
var context = serviceScope.ServiceProvider.GetService<ApplicationDbContext>();
var auditService = serviceScope.ServiceProvider.GetService<AuditService>();
....
}
...
}
WARNING: DO NOT use the code above as an example of what to do.
So this all compiled fine and the application started up as per normal. But like i stated above, No Http calls would find the web application
So I found out that due to the await call in the configure method (which was also marked as async now), this caused the application to be in a ghost state, and not responding to any routing calls.
My question to anyone that can answer, is why the routed calls didn't register anywhere as an issue, when it failed to access the Web application?
Note I couldn't even get a debug breakpoint to be hit in any controller code.
I’m trying to create a backend for a homepage with GWT. I created a Google Web Application in Eclipse without sample code and now I would like to add the service, but the developer Google guide doesn’t help me. I’m not sure, where to add the interface and how it exactly works.
If I understand the google documentation correctly, I have to add a module and an entry point class, is that correct? It would be great if you could give me some tips and help how to create a rpc service.
If you create a new GWT project in the Eclipse "New Project" wizard, with "Generate project sample code" checked, it will include a fully functioning RPC service with a sample method, which you can then adapt or copy according to your needs.
Out of memory, don't have eclipse in front of me.
First do create a test project with generated testcode, you can delete it afterward.
Yes you will have to add a module.
Create in client the two interfaces for the async calls, inherit it on server side.
Hope I understood your question right.
I'm not sure what would help you the most. Google developer guide was enough for me (at least when I started using it on version 1.6) to create RPC services for my GWT application.
General APP
Module: is the .gwt.xml file. Yes, you'll need it. The GWT compiler will find it automagically and try to compile all the GWT code (the <source> element will tell which subpackage contains Java code that will be converted to JS). It will tell also which class implements the EntryPoint interface. The onModuleLoad will be the code executed when javascript runs in the client page.
RPC
Well, you should first try UI things and only then, when you're confident enough, try the server thing. Anyway the scheme is:
interface MyService extends RemoteService {
List<String> doSomething(String sample, int other);
}
#RemoteServiceRelativePath("../path/to/servlet") // see later
intercace MyServiceAsync {
void doSomething(String sample, int other, AsyncCallback<List<String>> callback);
}
These are the interfaces. Later is the async one. That's what you'll use from client side. Always calling and passing an implementation of AsyncCallback which will receive (sometime later, you don't know when) the result.
First interface is the syncrhonous one. That is what you need to implement on server. You must inherit from RemoteServiceServlet class (it is an implementation of servlet that already does all the values handling), and implement your interface. GWT code does the rest (almost).
public class ServiceImpl extends RemoteServiceServlet implements MyService
{
// implement the method normally
}
From client you'll need to create the service proxy:
private static MyServiceAsync MY_SERVICE = GWT.create(MyService.class);
Yes. I know it's weird how GWT knows MyserviceAsync and MyService work together. Don't worry about that. It works :)
Just use the service like this:
MY_SERVICE.doSomething("value", 111, new AsyncCallback<List<String>>() {
// note that this code executes some time in the future when response from server is back
public void onSuccess(List<String> result) {
Window.alert("Server answered with " + result.size() + " elements!");
}
public void onFailure(Throwable t) {
Window.alert("Server failed: " + t.getMessage());
}
}
Path to server
You'll have to configure your app to make that servlet implementation listen to URL indicated in #RemoteServiceRelativePath. That's the way client knows where to make the request, and the server knows which servlet attends that request. I'd suggest using:
../my-service.gwt as relative path (GWT module gets published in <ROOT>/module_name
and
configuring your web app to use the servlet for /my-service.gwt
But it's entirely upon your preferences :)
Anyway I think Google tutorials are the best. So please copy&paste. Try&modify until you get to understand the whole thing.
We're thinking of converting our PHP Webapp from using no framework (which is killing us) to use Zend Framework. Because of the size of the application I don't think starting from scratch is going to be a viable option for management so I wanted to start researching how to slowly convert from the current site structure to one using Zend Framework but there isn't a lot of information on this process.
So far my plan is to dump the current code base into the public/ directory of the Zend Application, fix the numerous problems that I'm sure this will crop up and then start rewriting modules one at a time.
Has anyone had experience doing this in the past and how did it work out for you?
I've done a few of these now. What worked best for me was putting ZF 'around' the old app, so all requests go through ZF. I then have a 'Legacy' controller plugin, which checks whether the request can be satisfied by ZF, and if not, sends it to the old app:
class Yourapp_Plugin_Legacy extends Zend_Controller_Plugin_Abstract
{
public function preDispatch(Zend_Controller_Request_Abstract $request)
{
$dispatcher = Zend_Controller_Front::getInstance()->getDispatcher();
if (!$dispatcher->isDispatchable($request)) {
// send to the old code...
}
}
}
exactly how you then send the request to your old app depends a bit on how it is implemented. In one project, I examined the request, determined what file from the old code the request would have gone to, and then required that in. It sounds like this might be appropriate for you. In another project my solution was to route all these requests to a LegacyController in the ZF project, which ran the old code to get the resulting HTML and then rendered it inside the Zend_Layout from the new project.
The advantages of this approach are that you can gradually introduce ZF modules as you rewrite parts of the old app, until you reach the point where 100% of requests can be served by ZF. Also, since the ZF project has initialized before your old code is run, your old code can use the ZF autoloader, so you can start replacing classes in the old code with models written in a more ZF-style, and have them used by both parts of the app.
I created a Vaadin Project, then wanted to create a Custom composite and display that as my main window (so i could take advantage of the Visual UI editor). Working with Tomcat Apache Server and the Visual Editor has been a pain! Nothing updates even when i start, stop or restart the server. My mainWindow application will display some Vaadin components and not others. Here is an example i have of my main window code
import com.vaadin.Application;
import com.vaadin.ui.*;
public class DApplication extends Application {
#Override
public void init() {
Window mainWindow = new Window("DApplication");
//Header header = new Header();
//header.setSizeFull();
DHome dHome = new DHome(); // **HERE IS THE COMPOSITE INSTANCE I CREATED IN ECLIPSE**
dHome.setSizeFull();
mainWindow.getContent().setSizeFull();
mainWindow.addComponent(dHome);
setMainWindow(mainWindow);
}
}
Is this a bug or a problem with others using these same tool for making vaadin applications. My application even if i shut off my machine wont update with newly components added to the composite?
When you open the URL for the application, it creates a new user session. The session is preserved even if you reload the page. However, if you use Eclipse, it likes to do hot deployment to Tomcat and you may experience a problem that the application does not return to its initial state after you modify code. As Tomcat likes to persist sessions on server shutdown, the application state can remain even if you restart the server.
Adding the ?restartApplication parameter in the URL tells the Vaadin servlet to create a new Application instance on loading the page. If you also include a URI fragment, the parameter should be given before the fragment.
I want to use GWT with seam Framework, so i add the jar gwt-user-2.2.0.jar to my project. but when i invoke any method from the view (a xhtml page ) this exception is occured:
Caused by: java.lang.UnsupportedOperationException: ERROR: GWT.create() is only usable in client code! It cannot be called, for example, from server code. If you are running a unit test, check that your test case extends GWTTestCase and that GWT.create() is not called from within an initializer or constructor.
at com.google.gwt.core.client.GWT.create(GWT.java:92)
at com.google.gwt.user.client.ui.UIObject.(UIObject.java:188)
... 84 more
I use seam v2.2,I can post the code :
#Name("scheduleHandler1")
public class SheduleHandler1 implements Serializable,EntryPoint
{
public void onModuleLoad() {
MyPopup p = new MyPopup();
RootPanel.get().add(p);
}
From my xhtml view i call this method:
<h:commandLink value="showPopup" action="#{scheduleHandler1.onModuleLoad}" />
Thanks for Help.
GWT is client side technology - the java code that you write compiles down to js+html and is executed inside the browser.
OTOH, SEAM is server side technology - code that you write executes on server when a request is made and the HTML is produced which is returned back to browser for display.
In this sense GWT and Seam do not go well together. Most certainly you can not mix the code in the same compile unit.
You could use Seam for server side REST and GWT on the client side to consume REST, but this would only make sense if you already had an existing Seam REST code.
If you have written some GWT code and want to include it in you html pages (static or produced by Seam) then use them as GWT host pages - you simply include script tag to include GWT js code in the page: http://code.google.com/webtoolkit/doc/latest/DevGuideOrganizingProjects.html
GWT and Seam can actually work together, as you can see in this page in the Seam Reference Documentation.
However, what it looks like you are trying to do, and where the problem looks to me, is that you are trying to mix JSF and GWT. You are trying to call a Seam action from JSF where that action calls some GWT code. Hence, your server side Seam code is calling the client side GWT code and you are getting the exception that says GWT.create() is only usable in client code! It cannot be called, for example, from server code. I'm not sure why you're trying to do this.
JSF is a client side technology, written in XHTML. GWT is also a client side technology written in, well, Java. I'm not sure how these play together.
On the other hand, there is no reason, as per the link above, why your GWT widgets cannot call your Seam components. You just need to follow the instructions.