J2EE and debug in hosted mode

[Bandesz]

I'm developing a J2EE application with GWT using NetBeans 6.5,
Glassfish v2.

If I debugging only the web project, I can't use any Session Beans
from EJB project, becase I get "Cannot resolve reference Unresolved
Ejb-Ref..." error. I tried in every way to make <ejb-local-ref> tags
in web.xml (or in ejb-jar.xml), but the error stays. (I see now that
it's a dead end)

If I debugging the enterpise project, everythings works except the
hosted mode.

I searched a lot, but I can't make this work, please help.

Thanks,
Bandesz

[gregor]

couple of approaches

1) Simply use -noserver option. You need a build script to deploy your
RPC servlets and your EJB layer to Glassfish on demand and activate
remote debugging to make this work effectively, but lots of people do
it this way. See

http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=google-web-toolkit-doc-1-5&t=FAQ_HostedModeNoServer

2) You can run your RPC servlets in hosted mode Tomcat instance
leaving your session beans on Glassfish with a bit more work. You need
to use trad JNDI to try for a local reference to your session beans,
and if that fails go for the remote reference instead. I don't think
the new annotation stuff works for this.That way you get a local ref
in production and a remote one in dev from the same code. If you use
the ServiceLocator pattern it makes this easier.

[Bandesz]

Thx for the answer, but I need an exact howto, how can I debug the
whole J2EE application with Hosted Mode using Glassfish and Netbeans.

As I said, I searched a lot and haven't found a good description.

Bandesz

On Dec 8, 4:34 am, gregor <greg.power...@googlemail.com> wrote:
> couple of approaches
>
> 1) Simply use -noserver option. You need a build script to deploy your
> RPC servlets and your EJB layer to Glassfish on demand and activate
> remote debugging to make this work effectively, but lots of people do
> it this way. See
>

> http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=goog...

>
> 2) You can run your RPC servlets in hosted mode Tomcat instance
> leaving your session beans on Glassfish with a bit more work. You need
> to use trad JNDI to try for a local reference to your session beans,
> and if that fails go for the remote reference instead. I don't think
> the new annotation stuff works for this.That way you get a local ref
> in production and a remote one in dev from the same code. If you use
> the ServiceLocator pattern it makes this easier.
>

[gregor]

Well, that depends on your IDE and your app server, and unfortunately
I use Intellij and JBoss.

In JBoss the magic command is:

set JAVA_OPTS=-Xdebug -
Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n %JAVA_OPTS
%

which is in the JBoss startup script. I then set up a debug session
within IDEA that starts up JBoss inside IDEA and connects to it for
debugging purposes on port 8787 (IDEA conveniently knows how to do
this). Then I start the GWT module in hosted mode also in debug. As a
result the whole stack is running in debug and break points can be set
anywhere.

It looks like you can do a very similar thing with netbeans/glassfish:

http://weblogs.java.net/blog/arungupta/archive/2007/06/debug_applicati.html

I think you actually end up with two separate debug sessions, one for
your GWT app in hosted mode, and a second remote debug session for
what you have deployed on the app server. However this makes no
practical difference to debugging - GWT calls your server as per
normal and execution will halt at break points wherever they are in
the stack.

regards
gregor

[olivier FRESSE]

When you run in hosted mode, you have 2 java processes running.
The glassfish one, and the GWT shell.
Debugging the glassfish side is easy, it comes OOTB in Netbeans.

Debugging the client side is quite easy too.
You just need to change the way the GWTShell is launched :

java  -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n -Xmx256M -cp "$APPDIR/src:$APPDIR/bin:/home/ofe/dev/gwt-linux-1.5.3/gwt-user.jar:/home/ofe/dev/gwt-linux-1.5.3/gwt-dev-linux.jar" com.google.gwt.dev.GWTShell -out "$APPDIR/www" "$@" ext.test.MyAppli/MyAppli.html;

next you can attach the netbeans debugger to the Shell.

Is it what you're looking for ?

O.

2008/12/14 Bandesz <ban...@blog.hu>

[Bandesz]

I wrote it wrong, not the debug is the problem, I just want to run the
enterprise application (EJB+Web) in Hosted Mode, I wrote debugging
because hosted mode runs if I debug the web application.

If I understand correctly, the build-gwt.xml is responsible for the
hosted mode. If I run the ent. app., the build.xml simply compiles the
EJB and the Web project, makes an EAR package, and starts glassfish in
debug mode.

So how can I write a build file which runs the whole application in
gwt hosted mode?

This is a bottleneck in my development, because the deploy time is now
more than 1 minute. If I could use as I wrote it, the hosted mode
shows the changes in couple of seconds, and the autodeploy on the
server side is just seconds.

Bandesz

On Dec 14, 5:49 pm, "olivier FRESSE" <olivier.fre...@gmail.com> wrote:
> When you run in hosted mode, you have 2 java processes running.
> The glassfish one, and the GWT shell.
> Debugging the glassfish side is easy, it comes OOTB in Netbeans.
>
> Debugging the client side is quite easy too.
> You just need to change the way the GWTShell is launched :
>

> java  *-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n
> * -Xmx256M -cp

> "$APPDIR/src:$APPDIR/bin:/home/ofe/dev/gwt-linux-1.5.3/gwt-user.jar:/home/ofe/dev/gwt-linux-1.5.3/gwt-dev-linux.jar"
> com.google.gwt.dev.GWTShell -out "$APPDIR/www" "$@"
> ext.test.MyAppli/MyAppli.html;
>
> next you can attach the netbeans debugger to the Shell.
>
> Is it what you're looking for ?
>
> O.
>

> 2008/12/14 Bandesz <band...@blog.hu>

[gregor]

The simplest is to run hosted mode with the -noserver flag. Then you
deploy your EAR with your Ant script once and run & debug your GWT
client code in hosted mode just hitting the refresh button as you go.

[olivier FRESSE]

I don't think so...

-noserver only removes the GWT embedded tomcat which manages the GWT RPC mechanism.
I'm afraid you'll still have 2 java processes.
One for the client, one for the server... In fact, the GWTShell plays the role of the browser.

I'don't see how it could be possible to embed the GWTShell process in the J2EE one.

Regards,

2008/12/14 gregor <greg.p...@googlemail.com>

[jos]

Bandesz,
Gregor is pointing you in the right direction w/ option #1, and the
link he gives is enough to eventually get you there, but there is one
thing you have to do in your GWT code or it will never work. Your RPC
servlets all have a setServiceEntryPoint() call that is made to tell
them where they hookup. By default in hosted mode the GWT runtime will
tell your GWT application that the app server is on localhost so you
need to override that by changing the following code which should be
in your onModuleLoad() method. The code example below is in my
deployment setup, when I'm debugging the application I comment in the
first two lines and comment out the 3rd line. Note in the second
statement I'm telling GWT where the the service entry point really
lives. The third statement would point it back to the localhost
because that's where hosted mode lives.

There is a second important step that I'll mention here. After
compiling your GWT code, it does need to be deployed to your testing
server so that the hosted mode browser takes the code from that
server. Once you switch to -noserver the local tomcat goes away and
there's nothing serving up your application. When you run the hosted
mode debugger, you just need to type in the address of your
application on the address bar like you would if you were really
deployed, your application will be served by your test server and load
up into the hosted mode debug browser.

Try the GWT documentation link and these two points, and it should
work. Admittedly it is a painful process the first time you try to get
it to work, but it does work.

/** ECLIPSE CODE - comment in the next 2 lines and comment out
the line directly
* after these three to run with backend server in eclipse
System.out.println("GWT module base URL - " +
GWT.getModuleBaseURL());
geoServiceTarget.setServiceEntryPoint("http://
staging.abaqus.net/geo/gcb/geoservice");
*/
geoServiceTarget.setServiceEntryPoint(GWT.getModuleBaseURL() +
"geoservice");

On Dec 7, 7:34 pm, gregor <greg.power...@googlemail.com> wrote:
> couple of approaches
>
> 1) Simply use -noserver option. You need a build script to deploy your
> RPC servlets and your EJB layer to Glassfish on demand and activate
> remote debugging to make this work effectively, but lots of people do
> it this way. See
>

> http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=goog...

[olivier]

Well the GWT module isn't loaded at all...
I use seam remoting instead of GWT Servlets.
RPC works fine, the issue is that GWTSehll doesn't see the GWT modules
in the page...

[gregor]

> I'm afraid you'll still have 2 java processes.
> One for the client, one for the server... In fact, the GWTShell plays the
> role of the browser.
>

Exactly so - what I do is start JBoss in remote debug from within IDEA
(debug session 1), then start GWT hosted mode in debug, also in IDEA
(debug session 2). IDEA just switches between them as you step through
break points, I guess that netbeans would do the same. Yes, the dev
shell is just playing the browser.

In my option 2 above you also use two debug sessions like this, but
the difference is that here the GWT debug session includes the GWT RPC
servlet layer. I've found this is useful if you have, say, a session
facade of EJB session beans, independently tested and stable, because
you can simply restart the GWT dev shell in debug while working on the
RPC servlet layer without redeploying the whole ear to the remote
server all the time, but you can still have the second remote debug
session on the remote server to step through EJB code etc if required

This is example of how I did this for connecting a GWT app to
jackrabbit running as a RAR on JBoss - it works for both GWT hosted
mode (using RMI to jump from hosted mode Tomcat to jackrabbit on
JBoss) and deployed. You can use the same trick for session beans (or
I guess any Java EE resource) using local/remote interfaces, and
probably Spring as well, but I haven't tried that. Of course, if you
have a lot of such resources, this code gets tedious, which is where
the ServiceLocator pattern comes in....


Properties jndiprops = new Properties();
jndiprops.put(Context.INITIAL_CONTEXT_FACTORY,
"org.jnp.interfaces.NamingContextFactory");
jndiprops.put(Context.URL_PKG_PREFIXES,
"org.jboss.naming:org.jnp.interfaces");
jndiprops.put(Context.PROVIDER_URL, "jnp://localhost:
1099");
InitialContext ctx = new InitialContext(jndiprops);


// try for JNDI same VM
try {
log.info("Looking for local JCA jackrabbit
connection.....");
repos = (Repository) ctx.lookup("java:jcr/local");
log.info("Local JCA jackrabbit connection found.");
} catch (NamingException e) {
log.info("Failed getting JCR on local JNDI, trying
RMI....");
}
// so try RMI (for GWT hosted mode)
if(repos==null) {
ClientAdapterFactory adapter = new ClientAdapterFactory
();
RemoteRepository rr = (RemoteRepository) ctx.lookup
("jnp://localhost:1099/jcrServer");
repos = adapter.getRepository(rr);
if (repos!=null) {
log.info("Obtained jcr over RMI....");
} else {
log.error("Fatal error: Unable to obtain local or
RMI jcr connection - stopping....");
throw new Exception("JCR ( Jackrabbit)
Unavailable");

}
}



> I'don't see how it could be possible to embed the GWTShell process in the
> J2EE one.
>
> Regards,
>

> 2008/12/14 gregor <greg.power...@googlemail.com>