JSP debugging

Hello,

Any feedback on JSP debugging, Tomcat configuration etc in build #642?
All bugreports suggestions and questions are welcome.

--

Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"


15 comments
Comment actions Permalink

Eugene Zhuravlev wrote:

Hello,

Any feedback on JSP debugging, Tomcat configuration etc in build #642?
All bugreports suggestions and questions are welcome.


Is it planned to support Jetty as well?
Jetty is the standard Servlet/JSP-container in JBoss.

ciao

Marc Salm
http://www.codebasket.de
--
My software never has bugs. It just develops random features.

0
Comment actions Permalink

Sorry for an offtopic post but could you tell me why they use Jetty as
default instead of tomcat? Which is better?

Regards,


--
Glen Stampoultzis (TriNexus Pty Ltd)
Fixed:61 3 9753-6850 Mob:61 (0)402 835 458
ICQ: 62722370 EMail: glens@apache.org
URL's: http://jakarta.apache.org/poi http://www.krysalis.org

"Marc Salm" <m.salm@mediacare.de> wrote in message
news:3D6A2CD2.80406@mediacare.de...

Eugene Zhuravlev wrote:

Hello,

>

Any feedback on JSP debugging, Tomcat configuration etc in build #642?
All bugreports suggestions and questions are welcome.

>

Is it planned to support Jetty as well?
Jetty is the standard Servlet/JSP-container in JBoss.

>

ciao

>

Marc Salm
http://www.codebasket.de
--
My software never has bugs. It just develops random features.

>


0
Comment actions Permalink

We are going to open the corresponding API, so that particular AppServer
support could be plugged in, just like current Tomcat support

--

Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"


"Marc Salm" <m.salm@mediacare.de> wrote in message
news:3D6A2CD2.80406@mediacare.de...

Eugene Zhuravlev wrote:

Hello,

>

Any feedback on JSP debugging, Tomcat configuration etc in build #642?
All bugreports suggestions and questions are welcome.

>

Is it planned to support Jetty as well?
Jetty is the standard Servlet/JSP-container in JBoss.

>

ciao

>

Marc Salm
http://www.codebasket.de
--
My software never has bugs. It just develops random features.

>


0
Comment actions Permalink

I tried it but I'm getting some errors.

When you try to save a web config (from Project Properties) you get:

2002-08-26 08:21:23,635 ERROR - ellij.project.impl.ProjectImpl -
2002-08-26 08:21:23,635 ERROR - ellij.project.impl.ProjectImpl - IntelliJ IDEA (Ariadna) 3.0 Build #642
2002-08-26 08:21:23,635 ERROR - ellij.project.impl.ProjectImpl - JDK: 1.4.0_01
2002-08-26 08:21:23,635 ERROR - ellij.project.impl.ProjectImpl - VM: Java HotSpot(TM) Client VM
2002-08-26 08:21:23,635 ERROR - ellij.project.impl.ProjectImpl - Vendor: Sun Microsystems Inc.
2002-08-26 08:21:23,635 ERROR - ellij.project.impl.ProjectImpl - OS: Windows 2000
2002-08-26 08:21:23,645 ERROR - ellij.project.impl.ProjectImpl -
org.jdom.IllegalDataException: The data "null" is not legal for a JDOM attribute: A null is not a legal XML value.
at org.jdom.Attribute.setValue(Attribute.java:517)
at org.jdom.Attribute.(Attribute.java:245) at org.jdom.Attribute.]]>(Attribute.java:265)
at org.jdom.Element.setAttribute(Element.java:1393)
at com.intellij.j2ee.web.c.e.writeExternal(e.java:40)
at com.intellij.openapi.components.a.a.a(a.java:137)
at com.intellij.openapi.project.b.c.a(c.java:205)
at com.intellij.openapi.project.b.c.q(c.java:227)
at com.intellij.openapi.project.b.c.save(c.java:221)
at com.intellij.openapi.application.b.d.saveAll(d.java:53)
at com.intellij.ide.i.ds.actionPerformed(ds.java:0)
at com.intellij.openapi.actionSystem.b.w.a(w.java:6)
at com.intellij.openapi.actionSystem.b.w.processMouseEvent(w.java:120)
at java.awt.Component.processEvent(Component.java:4818)
at java.awt.Container.processEvent(Container.java:1525)
at java.awt.Component.dispatchEventImpl(Component.java:3526)
at java.awt.Container.dispatchEventImpl(Container.java:1582)
at java.awt.Component.dispatchEvent(Component.java:3367)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3359)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3074)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3004)
at java.awt.Container.dispatchEventImpl(Container.java:1568)
at java.awt.Window.dispatchEventImpl(Window.java:1581)
at java.awt.Component.dispatchEvent(Component.java:3367)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:445)
at com.intellij.ide.q.a(q.java:9)
at com.intellij.ide.q.dispatchEvent(q.java:23)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:191)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:144)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:130)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:98)
2002-08-26 08:21:23,715 INFO - com.intellij.localVcs.a.bb - enter: save(repositorySize=10866)
2002-08-26 08:21:28,402 ERROR - ellij.project.impl.ProjectImpl -
2002-08-26 08:21:28,402 ERROR - ellij.project.impl.ProjectImpl - IntelliJ IDEA (Ariadna) 3.0 Build #642
2002-08-26 08:21:28,402 ERROR - ellij.project.impl.ProjectImpl - JDK: 1.4.0_01
2002-08-26 08:21:28,402 ERROR - ellij.project.impl.ProjectImpl - VM: Java HotSpot(TM) Client VM
2002-08-26 08:21:28,402 ERROR - ellij.project.impl.ProjectImpl - Vendor: Sun Microsystems Inc.
2002-08-26 08:21:28,402 ERROR - ellij.project.impl.ProjectImpl - OS: Windows 2000
2002-08-26 08:21:28,402 ERROR - ellij.project.impl.ProjectImpl -
org.jdom.IllegalDataException: The data "null" is not legal for a JDOM attribute: A null is not a legal XML value.
at org.jdom.Attribute.setValue(Attribute.java:517)
at org.jdom.Attribute.(Attribute.java:245) at org.jdom.Attribute.]]>(Attribute.java:265)
at org.jdom.Element.setAttribute(Element.java:1393)
at com.intellij.j2ee.web.c.e.writeExternal(e.java:40)
at com.intellij.openapi.components.a.a.a(a.java:137)
at com.intellij.openapi.project.b.c.a(c.java:205)
at com.intellij.openapi.project.b.c.q(c.java:227)
at com.intellij.openapi.project.b.c.save(c.java:221)
at com.intellij.ide.ck.b(ck.java:31)
at com.intellij.ide.ck.a(ck.java:36)
at com.intellij.ide.cl.run(cl.java:5)
at com.intellij.util.p.run(p.java:1)
at com.intellij.util.q.run(q.java:6)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:443)
at com.intellij.ide.q.a(q.java:9)
at com.intellij.ide.q.dispatchEvent(q.java:12)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:191)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:144)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:130)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:98)
2002-08-26 08:21:28,442 INFO - com.intellij.localVcs.a.bb - enter: save(repositorySize=10866)
2002-08-26 08:21:34,581 ERROR - ellij.project.impl.ProjectImpl -
2002-08-26 08:21:34,581 ERROR - ellij.project.impl.ProjectImpl - IntelliJ IDEA (Ariadna) 3.0 Build #642
2002-08-26 08:21:34,581 ERROR - ellij.project.impl.ProjectImpl - JDK: 1.4.0_01
2002-08-26 08:21:34,581 ERROR - ellij.project.impl.ProjectImpl - VM: Java HotSpot(TM) Client VM
2002-08-26 08:21:34,581 ERROR - ellij.project.impl.ProjectImpl - Vendor: Sun Microsystems Inc.
2002-08-26 08:21:34,581 ERROR - ellij.project.impl.ProjectImpl - OS: Windows 2000
2002-08-26 08:21:34,581 ERROR - ellij.project.impl.ProjectImpl -
org.jdom.IllegalDataException: The data "null" is not legal for a JDOM attribute: A null is not a legal XML value.
at org.jdom.Attribute.setValue(Attribute.java:517)
at org.jdom.Attribute.(Attribute.java:245) at org.jdom.Attribute.]]>(Attribute.java:265)
at org.jdom.Element.setAttribute(Element.java:1393)
at com.intellij.j2ee.web.c.e.writeExternal(e.java:40)
at com.intellij.openapi.components.a.a.a(a.java:137)
at com.intellij.openapi.project.b.c.a(c.java:205)
at com.intellij.openapi.project.b.c.q(c.java:227)
at com.intellij.openapi.project.b.c.save(c.java:221)
at com.intellij.ide.ck.b(ck.java:31)
at com.intellij.ide.ck.a(ck.java:36)
at com.intellij.ide.cl.run(cl.java:5)
at com.intellij.util.p.run(p.java:1)
at com.intellij.util.q.run(q.java:6)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:443)
at com.intellij.ide.q.a(q.java:9)
at com.intellij.ide.q.dispatchEvent(q.java:12)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:191)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:144)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:130)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:98)

Then after setting up a run/debug settings for your webapp you get:

2002-08-26 08:17:15,178 ERROR - com.intellij.ide.q - Error during dispatching of java.awt.event.MouseEvent[MOUSE_RELEASED,(417,109),button=1,modifiers=Button1,clickCount=1] on frame0
2002-08-26 08:17:15,188 ERROR - com.intellij.ide.q - IntelliJ IDEA (Ariadna) 3.0 Build #642
2002-08-26 08:17:15,188 ERROR - com.intellij.ide.q - JDK: 1.4.0_01
2002-08-26 08:17:15,188 ERROR - com.intellij.ide.q - VM: Java HotSpot(TM) Client VM
2002-08-26 08:17:15,188 ERROR - com.intellij.ide.q - Vendor: Sun Microsystems Inc.
2002-08-26 08:17:15,188 ERROR - com.intellij.ide.q - OS: Windows 2000
2002-08-26 08:17:15,188 ERROR - com.intellij.ide.q -
java.lang.NullPointerException
at com.intellij.j2ee.web.WebApp.equals(WebApp.java:27)
at com.intellij.execution.i.i.a(i.java:74)
at com.intellij.execution.i.i.reset(i.java:77)
at com.intellij.execution.g.bo.b(bo.java:93)
at com.intellij.execution.g.bo.d(bo.java:102)
at com.intellij.execution.g.p.valueChanged(p.java:2)
at javax.swing.JList.fireSelectionValueChanged(JList.java:1318)
at javax.swing.JList$ListSelectionHandler.valueChanged(JList.java:1332)
at javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:187)
at javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:167)
at javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:214)
at javax.swing.DefaultListSelectionModel.changeSelection(DefaultListSelectionModel.java:402)
at javax.swing.DefaultListSelectionModel.changeSelection(DefaultListSelectionModel.java:411)
at javax.swing.DefaultListSelectionModel.setSelectionInterval(DefaultListSelectionModel.java:435)
at javax.swing.JList.setSelectedIndex(JList.java:1728)
at com.intellij.ui.cf.a(cf.java:32)
at com.intellij.execution.g.bo.a(bo.java:47)
at com.intellij.execution.g.bg.reset(bg.java:5)
at com.intellij.execution.g.bi.]]>(bi.java:17)
at com.intellij.execution.a.f.actionPerformed(f.java:0)
at com.intellij.openapi.actionSystem.b.j.actionPerformed(j.java:2)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1767)
at com.intellij.openapi.actionSystem.b.z.fireActionPerformed(z.java:45)
at com.intellij.ui.b.a.n.doClick(n.java:160)
at com.intellij.ui.b.a.n.access$300(n.java:230)
at com.intellij.ui.b.a.o.mouseReleased(o.java:5)
at java.awt.Component.processMouseEvent(Component.java:5021)
at java.awt.Component.processEvent(Component.java:4818)
at java.awt.Container.processEvent(Container.java:1525)
at java.awt.Component.dispatchEventImpl(Component.java:3526)
at java.awt.Container.dispatchEventImpl(Container.java:1582)
at java.awt.Component.dispatchEvent(Component.java:3367)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3359)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3074)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3004)
at java.awt.Container.dispatchEventImpl(Container.java:1568)
at java.awt.Window.dispatchEventImpl(Window.java:1581)
at java.awt.Component.dispatchEvent(Component.java:3367)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:445)
at com.intellij.ide.q.a(q.java:9)
at com.intellij.ide.q.dispatchEvent(q.java:23)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:191)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:144)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:130)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:98)
2002-08-26 08:17:18,893 ERROR - ellij.project.impl.ProjectImpl -
2002-08-26 08:17:18,893 ERROR - ellij.project.impl.ProjectImpl - IntelliJ IDEA (Ariadna) 3.0 Build #642
2002-08-26 08:17:18,893 ERROR - ellij.project.impl.ProjectImpl - JDK: 1.4.0_01
2002-08-26 08:17:18,893 ERROR - ellij.project.impl.ProjectImpl - VM: Java HotSpot(TM) Client VM
2002-08-26 08:17:18,893 ERROR - ellij.project.impl.ProjectImpl - Vendor: Sun Microsystems Inc.
2002-08-26 08:17:18,893 ERROR - ellij.project.impl.ProjectImpl - OS: Windows 2000
2002-08-26 08:17:18,893 ERROR - ellij.project.impl.ProjectImpl -
org.jdom.IllegalDataException: The data "null" is not legal for a JDOM attribute: A null is not a legal XML value.
at org.jdom.Attribute.setValue(Attribute.java:517)
at org.jdom.Attribute.(Attribute.java:245) at org.jdom.Attribute.]]>(Attribute.java:265)
at org.jdom.Element.setAttribute(Element.java:1393)
at com.intellij.j2ee.web.c.e.writeExternal(e.java:40)
at com.intellij.openapi.components.a.a.a(a.java:137)
at com.intellij.openapi.project.b.c.a(c.java:205)
at com.intellij.openapi.project.b.c.q(c.java:227)
at com.intellij.openapi.project.b.c.save(c.java:221)
at com.intellij.openapi.application.b.d.saveAll(d.java:53)
at com.intellij.openapi.application.b.d.exit(d.java:158)
at com.intellij.ide.i.cl.actionPerformed(cl.java)
at com.intellij.openapi.actionSystem.b.j.actionPerformed(j.java:2)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1767)
at com.intellij.openapi.actionSystem.b.z.fireActionPerformed(z.java:45)
at com.intellij.ui.b.a.n.doClick(n.java:160)
at com.intellij.ui.b.a.n.access$300(n.java:230)
at com.intellij.ui.b.a.o.mouseReleased(o.java:5)
at java.awt.Component.processMouseEvent(Component.java:5021)
at java.awt.Component.processEvent(Component.java:4818)
at java.awt.Container.processEvent(Container.java:1525)
at java.awt.Component.dispatchEventImpl(Component.java:3526)
at java.awt.Container.dispatchEventImpl(Container.java:1582)
at java.awt.Component.dispatchEvent(Component.java:3367)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3359)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3074)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3004)
at java.awt.Container.dispatchEventImpl(Container.java:1568)
at java.awt.Window.dispatchEventImpl(Window.java:1581)
at java.awt.Component.dispatchEvent(Component.java:3367)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:445)
at com.intellij.ide.q.a(q.java:9)
at com.intellij.ide.q.dispatchEvent(q.java:23)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:191)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:144)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:130)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:98)

0
Comment actions Permalink

Well, I would love to use the new feature, but there are several
problems for me and probably others as well. First we yre using
WebLogic, but this could be solved with the OpenAPI as you mentioned
in another post.

The other problem is that we don't have any project where the working
files have the same structure as the deployed web application. So it
would never be possible to configure a complete web application inside
our working directories as the current implementation needs.

Would it be possible - probably not in Ariadna but maybe the next
version or through some plugin - to debug JSPs in standard remote
debugging mode somehow?! Wouldn't it be sufficient to tell the IDE
where the AppServer generates the java files from the JSPs to be able
to analyze them in order to map the JSP source lines to JAVA code
source lines for breakpoint purposes?

This would mean the IDE needs some plugin to parse the generated JAVA
files to associate the correct JSP source lines and the AppServer
would have to be set up to compile JSPs in debug mode for having debug
information.

Any comments on this?!

Michael

On Mon, 26 Aug 2002 14:06:51 +0400, "Eugene Zhuravlev"
<jeka@intellij.com> wrote:

>Hello,
>
>Any feedback on JSP debugging, Tomcat configuration etc in build #642?
>All bugreports suggestions and questions are welcome.

0
Comment actions Permalink

AFAIK JSP debugging is done as described below (well, it would be nice to have at least preliminary 5-line doc on each feature...)
Web app support must be enabled, web app configured to point to the folder under CATALINA_HOME webapp folder. WEB-INF must be properly populated with classes and libs, and only with all this set up one can do JSP debugging.
BTW it's not clear whether "context path" should start with '/' or not - don't remember whuch option works.

Anyway, it's tedious to set up this configuration, copy classes, libs and JSPs to tomcat folder, etc., since I prefer to have all my java files in src/java-release, jsps in src/web-apps/name/, jars in lib/jar. I know that ant task is properly suited for this, but it's another step to be set up and performed.

it would be perfect to have 'advanced' webapp run time configuration that allows to specify what classes and libs to copy to tomcat folder (it's ok) or, to be able to start tomcat against project's libs and classes. Though not all libs/classes could be required it's still ok. But not sure whether tomcat can be made started in this configuration.

0
Comment actions Permalink

Hi Michael,

The other problem is that we don't have any project where the working
files have the same structure as the deployed web application. So it
would never be possible to configure a complete web application inside
our working directories as the current implementation needs.


All you need is just set up a web app in "File | Project Properties | Web"
and have a WEB-INF directory with the proper data in the root directory of
your web application. WebApp run configuration allows you to associate any
of your configured web apps with one of the context paths configured in
Tomcat's "server.xml" configuration files. If you don't want to deploy your
application or put your classes to directories where Tomcat assumes they
should be, there's a possibility to use classpath from your project, so
Tomcat will be able to locate your code. Could you give us some examples of
the configuration problems you mentioned?

Would it be possible - probably not in Ariadna but maybe the next
version or through some plugin - to debug JSPs in standard remote
debugging mode somehow?! Wouldn't it be sufficient to tell the IDE
where the AppServer generates the java files from the JSPs to be able
to analyze them in order to map the JSP source lines to JAVA code
source lines for breakpoint purposes?


This is how it is currently done. Main purposes of the current Tomcat
integration are:
- to start Tomcat with the options that ensure the JSPs are compiled with
debug info and java files are generated in easily parseable format, so the
user does not have to bother with manual configuration.
- to provide an interface that translates JSP line nuimbers into Java line
numbers and vice versa.
Any other integration will have to implement the same API once the API is
opened. BTW, we played with the new debug API, supporting JSR045 in JDK
1.4.0, but found it unusabe with JRun's JSP compiler, the only compiler
available that supports extended debug info described in the JSR045.



--

Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"


0
Comment actions Permalink

Glen Stampoutlzis wrote:

Sorry for an offtopic post but could you tell me why they use Jetty as
default instead of tomcat? Which is better?


That, you have to ask the developers of JBoss.
Perhaps, because it's much smaller, easier to configure, lesser
footprint, ...

ciao

Marc Salm
http://www.codebasket.de
--
My software never has bugs. It just develops random features.

0
Comment actions Permalink

Hi Eugene,

thanks for your reply, maybe I just didn't do the right thing all the
time. I always configured web applications by specifying the web root
to be inside the project's sources. The problem is that there is no
such path. First, some files that go inside the WEB-INF directory are
located under $PROJECT_ROOT$/etc/... for example. Second, some
configuration files get patched during deployment according to the
target system. Third, the JSPs are merged together from more than one
directory since we build multiple web applications that share some
common pages. Maybe there's a better way to handle such things but it
won't change at the moment.

But your mail gave me some idea of how I could also configure a web
application. I just used the deployed folder from inside Tomcat
instead. This one of course is a complete and runnable web
application. Is this one way it is supposed to work? At least it is
what I meant in my previous post.

I didn't get it running for now, but at least the server starts. This
has probably to do with the fact that I didn't use Tomcat for too long
and have to read a little about configurations first. ;)

Another question on this topic: when debugging a complete application
(EJB + Web), I'm starting the app server in debug mode and attach via
remote debugging. This gives me everything except for the JSP source
debugging. The current debug configuration wouldn't support such a
scenario which means debugging more than a single web application
(i.e. a single web context and web root wouldn't be sufficient). Will
something like this be possible in the future somehow?

Michael

On Tue, 27 Aug 2002 11:21:25 +0400, "Eugene Zhuravlev"
<jeka@intellij.com> wrote:

>Hi Michael,
>
>> The other problem is that we don't have any project where the working
>> files have the same structure as the deployed web application. So it
>> would never be possible to configure a complete web application inside
>> our working directories as the current implementation needs.
>
>All you need is just set up a web app in "File | Project Properties | Web"
>and have a WEB-INF directory with the proper data in the root directory of
>your web application. WebApp run configuration allows you to associate any
>of your configured web apps with one of the context paths configured in
>Tomcat's "server.xml" configuration files. If you don't want to deploy your
>application or put your classes to directories where Tomcat assumes they
>should be, there's a possibility to use classpath from your project, so
>Tomcat will be able to locate your code. Could you give us some examples of
>the configuration problems you mentioned?
>
>> Would it be possible - probably not in Ariadna but maybe the next
>> version or through some plugin - to debug JSPs in standard remote
>> debugging mode somehow?! Wouldn't it be sufficient to tell the IDE
>> where the AppServer generates the java files from the JSPs to be able
>> to analyze them in order to map the JSP source lines to JAVA code
>> source lines for breakpoint purposes?
>
>This is how it is currently done. Main purposes of the current Tomcat
>integration are:

- to start Tomcat with the options that ensure the JSPs are compiled with

>debug info and java files are generated in easily parseable format, so the
>user does not have to bother with manual configuration.
>- to provide an interface that translates JSP line nuimbers into Java line
>numbers and vice versa.
>Any other integration will have to implement the same API once the API is
>opened. BTW, we played with the new debug API, supporting JSR045 in JDK
>1.4.0, but found it unusabe with JRun's JSP compiler, the only compiler
>available that supports extended debug info described in the JSR045.

0
Comment actions Permalink

Another question on this topic: when debugging a complete application
(EJB + Web), I'm starting the app server in debug mode and attach via
remote debugging. This gives me everything except for the JSP source
debugging.


In order to get JSP source debugging you'll have to use "WebApp" run
configuration instead of simple "Remote". This is because we need to
translate java and jsp line numbers somehow. The WebApp run configuration
uses attachement to the server just like "Remote" configuration does(and
there will be a possibility to attach to already running server). The main
difference between these configurations is that when started from WebApp
configuration, the debugger does some extra job for translating java-jsp
line numbers (and unfortunately now this is AppServer-specific). We'll be
able to merge functionalities of these debugging configurations when JSR045
is fully supported (I mean not just the API, but also really workable
implementation of the API). Thus JSP debug information will always be
available, no matter what type of run configuration you use. Until then
we'll have to use the current approach.

The current debug configuration wouldn't support such a
scenario which means debugging more than a single web application
(i.e. a single web context and web root wouldn't be sufficient). Will
something like this be possible in the future somehow?


This will be also possible with full JSR 045 support which both JPDA and
AppServers are going to provide.

--

Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"

"Michael Descher" <michael.descher@gmx.de> wrote in message
news:01knmugfdaq4erg00no8tkm10mrvso9a4h@4ax.com...

Hi Eugene,

>

thanks for your reply, maybe I just didn't do the right thing all the
time. I always configured web applications by specifying the web root
to be inside the project's sources. The problem is that there is no
such path. First, some files that go inside the WEB-INF directory are
located under $PROJECT_ROOT$/etc/... for example. Second, some
configuration files get patched during deployment according to the
target system. Third, the JSPs are merged together from more than one
directory since we build multiple web applications that share some
common pages. Maybe there's a better way to handle such things but it
won't change at the moment.

>

But your mail gave me some idea of how I could also configure a web
application. I just used the deployed folder from inside Tomcat
instead. This one of course is a complete and runnable web
application. Is this one way it is supposed to work? At least it is
what I meant in my previous post.

>

I didn't get it running for now, but at least the server starts. This
has probably to do with the fact that I didn't use Tomcat for too long
and have to read a little about configurations first. ;)

>

Another question on this topic: when debugging a complete application
(EJB + Web), I'm starting the app server in debug mode and attach via
remote debugging. This gives me everything except for the JSP source
debugging. The current debug configuration wouldn't support such a
scenario which means debugging more than a single web application
(i.e. a single web context and web root wouldn't be sufficient). Will
something like this be possible in the future somehow?

>

Michael

>

On Tue, 27 Aug 2002 11:21:25 +0400, "Eugene Zhuravlev"
<jeka@intellij.com> wrote:

>

>Hi Michael,
>
>> The other problem is that we don't have any project where the working
>> files have the same structure as the deployed web application. So it
>> would never be possible to configure a complete web application inside
>> our working directories as the current implementation needs.
>
>All you need is just set up a web app in "File | Project Properties |

Web"

>and have a WEB-INF directory with the proper data in the root directory

of

>your web application. WebApp run configuration allows you to associate

any

>of your configured web apps with one of the context paths configured in
>Tomcat's "server.xml" configuration files. If you don't want to deploy

your

>application or put your classes to directories where Tomcat assumes they
>should be, there's a possibility to use classpath from your project, so
>Tomcat will be able to locate your code. Could you give us some examples

of

>the configuration problems you mentioned?
>
>> Would it be possible - probably not in Ariadna but maybe the next
>> version or through some plugin - to debug JSPs in standard remote
>> debugging mode somehow?! Wouldn't it be sufficient to tell the IDE
>> where the AppServer generates the java files from the JSPs to be able
>> to analyze them in order to map the JSP source lines to JAVA code
>> source lines for breakpoint purposes?
>
>This is how it is currently done. Main purposes of the current Tomcat
>integration are:

- to start Tomcat with the options that ensure the JSPs are compiled

with

>debug info and java files are generated in easily parseable format, so

the

>user does not have to bother with manual configuration.
>- to provide an interface that translates JSP line nuimbers into Java

line

>numbers and vice versa.
>Any other integration will have to implement the same API once the API is
>opened. BTW, we played with the new debug API, supporting JSR045 in JDK
>1.4.0, but found it unusabe with JRun's JSP compiler, the only compiler
>available that supports extended debug info described in the JSR045.

>


0
Comment actions Permalink

Hi Evgeniy.

You missed the error post by Kevin, but I have encountered the same problem. After setting IDEA for web application support project file does not save and debug does not work at all.
It seems to me thae 642nd build is absolutely useless for now.

Vitaly

0
Comment actions Permalink

Hi,

Is there any hope of getting the resin application server offically
supported? Or is their documentation for users to add there own jsp server?

I have resin mostly working now (using remote debugging and pointing
resin's webapp dir to IDEA build WEBINF directory, but it is a little
flakey. Sometimes I can set breakpoints in the jsp that work and
sometimes I can't.

Any pointers would be greatly appreciated.

Thanks Spencer


Eugene Zhuravlev wrote:
>>Another question on this topic: when debugging a complete application
>>(EJB + Web), I'm starting the app server in debug mode and attach via
>>remote debugging. This gives me everything except for the JSP source
>>debugging.


In order to get JSP source debugging you'll have to use "WebApp" run
configuration instead of simple "Remote". This is because we need to
translate java and jsp line numbers somehow. The WebApp run configuration
uses attachement to the server just like "Remote" configuration does(and
there will be a possibility to attach to already running server). The main
difference between these configurations is that when started from WebApp
configuration, the debugger does some extra job for translating java-jsp
line numbers (and unfortunately now this is AppServer-specific). We'll be
able to merge functionalities of these debugging configurations when JSR045
is fully supported (I mean not just the API, but also really workable
implementation of the API). Thus JSP debug information will always be
available, no matter what type of run configuration you use. Until then
we'll have to use the current approach.

>>The current debug configuration wouldn't support such a
>>scenario which means debugging more than a single web application
>>(i.e. a single web context and web root wouldn't be sufficient). Will
>>something like this be possible in the future somehow?


This will be also possible with full JSR 045 support which both JPDA and
AppServers are going to provide.

--

Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"

"Michael Descher" <michael.descher@gmx.de> wrote in message
news:01knmugfdaq4erg00no8tkm10mrvso9a4h@4ax.com...

>>Hi Eugene,
>>
>>thanks for your reply, maybe I just didn't do the right thing all the
>>time. I always configured web applications by specifying the web root
>>to be inside the project's sources. The problem is that there is no
>>such path. First, some files that go inside the WEB-INF directory are
>>located under $PROJECT_ROOT$/etc/... for example. Second, some
>>configuration files get patched during deployment according to the
>>target system. Third, the JSPs are merged together from more than one
>>directory since we build multiple web applications that share some
>>common pages. Maybe there's a better way to handle such things but it
>>won't change at the moment.
>>
>>But your mail gave me some idea of how I could also configure a web
>>application. I just used the deployed folder from inside Tomcat
>>instead. This one of course is a complete and runnable web
>>application. Is this one way it is supposed to work? At least it is
>>what I meant in my previous post.
>>
>>I didn't get it running for now, but at least the server starts. This
>>has probably to do with the fact that I didn't use Tomcat for too long
>>and have to read a little about configurations first. ;)
>>
>>Another question on this topic: when debugging a complete application
>>(EJB + Web), I'm starting the app server in debug mode and attach via
>>remote debugging. This gives me everything except for the JSP source
>>debugging. The current debug configuration wouldn't support such a
>>scenario which means debugging more than a single web application
>>(i.e. a single web context and web root wouldn't be sufficient). Will
>>something like this be possible in the future somehow?
>>
>>Michael
>>
>>On Tue, 27 Aug 2002 11:21:25 +0400, "Eugene Zhuravlev"
>><jeka@intellij.com> wrote:
>>
>>
>>>Hi Michael,
>>>
>>>
>>>>The other problem is that we don't have any project where the working
>>>>files have the same structure as the deployed web application. So it
>>>>would never be possible to configure a complete web application inside
>>>>our working directories as the current implementation needs.
>>>
>>>All you need is just set up a web app in "File | Project Properties |
>>

Web"

>>>and have a WEB-INF directory with the proper data in the root directory
>>

of

>>>your web application. WebApp run configuration allows you to associate
>>

any

>>>of your configured web apps with one of the context paths configured in
>>>Tomcat's "server.xml" configuration files. If you don't want to deploy
>>

your

>>>application or put your classes to directories where Tomcat assumes they
>>>should be, there's a possibility to use classpath from your project, so
>>>Tomcat will be able to locate your code. Could you give us some examples
>>

of

>>>the configuration problems you mentioned?
>>>
>>>
>>>>Would it be possible - probably not in Ariadna but maybe the next
>>>>version or through some plugin - to debug JSPs in standard remote
>>>>debugging mode somehow?! Wouldn't it be sufficient to tell the IDE
>>>>where the AppServer generates the java files from the JSPs to be able
>>>>to analyze them in order to map the JSP source lines to JAVA code
>>>>source lines for breakpoint purposes?
>>>
>>>This is how it is currently done. Main purposes of the current Tomcat
>>>integration are:
>>>- to start Tomcat with the options that ensure the JSPs are compiled
>>

with

>>>debug info and java files are generated in easily parseable format, so
>>

the

>>>user does not have to bother with manual configuration.
>>>- to provide an interface that translates JSP line nuimbers into Java
>>

line

>>>numbers and vice versa.
>>>Any other integration will have to implement the same API once the API is
>>>opened. BTW, we played with the new debug API, supporting JSR045 in JDK
>>>1.4.0, but found it unusabe with JRun's JSP compiler, the only compiler
>>>available that supports extended debug info described in the JSR045.
>>




0
Comment actions Permalink

I had the same problem. The only workaround I've found was to manually edit my project file (.ipr) - I added something like       ]]>
One should close IDEA before the editing. After this I restarted IDEA, and was able to create a WebApp settings for the application.
Anyway, it didn't help - I am able to run Tomcat and the application, but IDEA doesn't want to stop at the breakpoints in the JSP files :).
Some explanations would be good :)

0
Comment actions Permalink

Hi Spencer,
As soon as we open corresponding API to write AppServer integration plugins,
there will be a possibility to write Resin plugin.

Sometimes I can set breakpoints in the jsp that work and
sometimes I can't.


Do you mean source-level JSP breakpoints?

--

Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"


"Spencer Marks" <smarks@digisolutions.com> wrote in message
news:3D6F9B29.5010101@digisolutions.com...

Hi,

>

Is there any hope of getting the resin application server offically
supported? Or is their documentation for users to add there own jsp

server?
>

I have resin mostly working now (using remote debugging and pointing
resin's webapp dir to IDEA build WEBINF directory, but it is a little
flakey. Sometimes I can set breakpoints in the jsp that work and
sometimes I can't.

>

Any pointers would be greatly appreciated.

>

Thanks Spencer

>
>

Eugene Zhuravlev wrote:
>>Another question on this topic: when debugging a complete application
>>(EJB + Web), I'm starting the app server in debug mode and attach via
>>remote debugging. This gives me everything except for the JSP source
>>debugging.
>
>

In order to get JSP source debugging you'll have to use "WebApp" run
configuration instead of simple "Remote". This is because we need to
translate java and jsp line numbers somehow. The WebApp run

configuration

uses attachement to the server just like "Remote" configuration does(and
there will be a possibility to attach to already running server). The

main

difference between these configurations is that when started from WebApp
configuration, the debugger does some extra job for translating java-jsp
line numbers (and unfortunately now this is AppServer-specific). We'll

be

able to merge functionalities of these debugging configurations when

JSR045

is fully supported (I mean not just the API, but also really workable
implementation of the API). Thus JSP debug information will always be
available, no matter what type of run configuration you use. Until then
we'll have to use the current approach.

>
>
>>The current debug configuration wouldn't support such a
>>scenario which means debugging more than a single web application
>>(i.e. a single web context and web root wouldn't be sufficient). Will
>>something like this be possible in the future somehow?
>
>

This will be also possible with full JSR 045 support which both JPDA and
AppServers are going to provide.

>

--

>

Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"

>

"Michael Descher" <michael.descher@gmx.de> wrote in message
news:01knmugfdaq4erg00no8tkm10mrvso9a4h@4ax.com...

>
>>Hi Eugene,
>>
>>thanks for your reply, maybe I just didn't do the right thing all the
>>time. I always configured web applications by specifying the web root
>>to be inside the project's sources. The problem is that there is no
>>such path. First, some files that go inside the WEB-INF directory are
>>located under $PROJECT_ROOT$/etc/... for example. Second, some
>>configuration files get patched during deployment according to the
>>target system. Third, the JSPs are merged together from more than one
>>directory since we build multiple web applications that share some
>>common pages. Maybe there's a better way to handle such things but it
>>won't change at the moment.
>>
>>But your mail gave me some idea of how I could also configure a web
>>application. I just used the deployed folder from inside Tomcat
>>instead. This one of course is a complete and runnable web
>>application. Is this one way it is supposed to work? At least it is
>>what I meant in my previous post.
>>
>>I didn't get it running for now, but at least the server starts. This
>>has probably to do with the fact that I didn't use Tomcat for too long
>>and have to read a little about configurations first. ;)
>>
>>Another question on this topic: when debugging a complete application
>>(EJB + Web), I'm starting the app server in debug mode and attach via
>>remote debugging. This gives me everything except for the JSP source
>>debugging. The current debug configuration wouldn't support such a
>>scenario which means debugging more than a single web application
>>(i.e. a single web context and web root wouldn't be sufficient). Will
>>something like this be possible in the future somehow?
>>
>>Michael
>>
>>On Tue, 27 Aug 2002 11:21:25 +0400, "Eugene Zhuravlev"
>><jeka@intellij.com> wrote:
>>
>>
>>>Hi Michael,
>>>
>>>
>>>>The other problem is that we don't have any project where the working
>>>>files have the same structure as the deployed web application. So it
>>>>would never be possible to configure a complete web application inside
>>>>our working directories as the current implementation needs.
>>>
>>>All you need is just set up a web app in "File | Project Properties |
>>

Web"

>
>>>and have a WEB-INF directory with the proper data in the root directory
>>

of

>
>>>your web application. WebApp run configuration allows you to associate
>>

any

>
>>>of your configured web apps with one of the context paths configured in
>>>Tomcat's "server.xml" configuration files. If you don't want to deploy
>>

your

>
>>>application or put your classes to directories where Tomcat assumes

they

>>>should be, there's a possibility to use classpath from your project, so
>>>Tomcat will be able to locate your code. Could you give us some

examples

>>

of

>
>>>the configuration problems you mentioned?
>>>
>>>
>>>>Would it be possible - probably not in Ariadna but maybe the next
>>>>version or through some plugin - to debug JSPs in standard remote
>>>>debugging mode somehow?! Wouldn't it be sufficient to tell the IDE
>>>>where the AppServer generates the java files from the JSPs to be able
>>>>to analyze them in order to map the JSP source lines to JAVA code
>>>>source lines for breakpoint purposes?
>>>
>>>This is how it is currently done. Main purposes of the current Tomcat
>>>integration are:
>>>- to start Tomcat with the options that ensure the JSPs are compiled
>>

with

>
>>>debug info and java files are generated in easily parseable format, so
>>

the

>
>>>user does not have to bother with manual configuration.
>>>- to provide an interface that translates JSP line nuimbers into Java
>>

line

>
>>>numbers and vice versa.
>>>Any other integration will have to implement the same API once the API

is

>>>opened. BTW, we played with the new debug API, supporting JSR045 in JDK
>>>1.4.0, but found it unusabe with JRun's JSP compiler, the only

compiler

>>>available that supports extended debug info described in the JSR045.
>>
>
>

>
>


0
Comment actions Permalink

I can't even get it to setup correctly. When I do set it up, and it looks like, I lose all my settings when I click on the debug button.
This is with build 642 using JDK 1.4.1 on Windows XP. Also there needs to be some clear documentation somewhere as to how to do this... although there might be in the idea dir but I didn't look there yet. I wish the help buttons would work already so we can figure things out a bit quicker.

0

Please sign in to leave a comment.