getDate on a resource

2003-12-13 Thread Dmitry Beransky
Hi,

In my application i need to determine the last modification date of a 
resource.  I'm doing this with the following few lines of code:

  URL resource = context.getResource(uri);
  URLConnection conn = resource.openConnection();
  Date date = new Date(conn.getDate());
however, the date returned is 0.  A call to getResource() returns a url 
looking like "jndi:/localhost/reclass/layout.jsp".

Am I not doing this right?  What's the proper way to find out a resource's 
date?

I'm running Tomcat 4.1.27.

Thanks
Dmitry
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: bug #21252

2003-09-02 Thread Dmitry Beransky
At 01:55 PM 9/2/2003, John Corrigan wrote:
Why is the the location of the JDK a problem here?  The endorsed directories
and classpath seem to be the problem to me.
As far as I can see the only problem is (just like the bug report says) the 
total length of the invocation command.  Here are the facts:

1.  I've been running Tomcat out of exactly the same location for several 
months and on different smaller projects with no problems.
2.  The problem showed up when I added an extra source path to the project
3.  The problem went away when I made Tomcat's location path shorter by 
renaming its home directory and moving it to the top of the file system.
4.  I have no problems running other Java applications with the same JDK.

Thanks
Dmitry 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: bug #21252

2003-09-02 Thread Dmitry Beransky
I just moved the tomcat installation to c:\tomcat and that solved the 
problem.  I guess the invocation command was indeed getting too long.  I'm 
fine for now, but the way I structure my dev projects, I'll be adding more 
paths in the future, so this problem may yet return.

Is this solvable at all?  I'm a bit confused as there is a comment in the 
bug report left by Remi Maucherat that indicates that the issue has been 
resolved.

Dmitry

At 01:40 PM 9/2/2003, you wrote:
Have you tried placing the values for the switches inside quotes?  Since
your paths contain spaces that would seem to be an issue.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: bug #21252

2003-09-02 Thread Dmitry Beransky
At 12:03 PM 9/2/2003, you wrote:
I'm assuming that you are running under windows since you didn't specify the
environment.  What is that path to the jvm.dll being used by Tomcat?
Yep, that bug is indeed windows specific.  The JDK path is 
"c:\java\j2sdk1.4.1_02".  I'm launching Tomcat from inside IntelliJ IDEA 
and the invocation command doesn't specify which jvm.dll to use (neither 
client nor server), so I assume whatever's the default gets used.  I'm 
including the full launch command as generated by IDEA below (it's pretty big)

I've only run into this problem recently after adding a few more source 
paths to the project.  A simpler project works just fine.

Thanks
Dmitry
C:\java\j2sdk1.4.1_02\bin\javaw.exe -Djava.endorsed.dirs=C:\Program 
Files\jakarta-tomcat-4.1.27\bin;C:\Program 
Files\jakarta-tomcat-4.1.27\common\lib;C:\Program 
Files\jakarta-tomcat-4.1.27\common\endorsed -Dcatalina.base=C:\Documents 
and Settings\dmitry\.IntelliJIdea\system\tomcat_ReclassRequests_8338efab 
-Dcatalina.home=C:\Program Files\jakarta-tomcat-4.1.27 
-Djava.io.tmpdir=C:\Program Files\jakarta-tomcat-4.1.27\temp -classpath 
C:\java\j2sdk1.4.1_02\lib\tools.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\bin\bootstrap.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\common\lib\activation.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\common\lib\ant.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\common\lib\commons-collections.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\common\lib\commons-dbcp.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\common\lib\commons-logging-api.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\common\lib\commons-pool.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\common\lib\jasper-compiler.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\common\lib\jasper-runtime.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\common\lib\jdbc2_0-stdext.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\common\lib\jndi.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\common\lib\jta.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\common\lib\mail.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\common\lib\naming-common.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\common\lib\naming-factory.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\common\lib\naming-resources.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\common\lib\servlet.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\catalina-ant.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\catalina.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\commons-beanutils.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\commons-digester.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\commons-fileupload-1.0.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\commons-logging.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\commons-modeler.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\jaas.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\jakarta-regexp-1.2.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\mx4j-jmx.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\servlets-common.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\servlets-default.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\servlets-invoker.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\servlets-manager.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\servlets-webdav.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\tomcat-coyote.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\tomcat-http11.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\tomcat-jk.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\tomcat-jk2.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\tomcat-util.jar;C:\Program 
Files\jakarta-tomcat-4.1.27\server\lib\tomcat-warp.jar;C:\java\jakarta-servletapi-4\lib\servlet.jar;C:\Documents 
and 
Settings\dmitry\IdeaProjects\ReclassRequests\reclassrequests\web\WEB-INF\classes;C:\java\j2sdk1.4.1_02\jre\lib\charsets.jar;C:\java\j2sdk1.4.1_02\jre\lib\jaws.jar;C:\java\j2sdk1.4.1_02\jre\lib\jce.jar;C:\java\j2sdk1.4.1_02\jre\lib\jsse.jar;C:\java\j2sdk1.4.1_02\jre\lib\rt.jar;C:\java\j2sdk1.4.1_02\jre\lib\sunrsasign.jar;C:\java\j2sdk1.4.1_02\jre\lib\ext\dnsns.jar;C:\java\j2sdk1.4.1_02\jre\lib\ext\ldapsec.jar;C:\java\j2sdk1.4.1_02\jre\lib\ext\localedata.jar;C:\java\j2sdk1.4.1_02\jre\lib\ext\sunjce_provider.jar;C:\java\jwsdp-1.2\jsf\lib\standard.jar;C:\java\jwsdp-1.2\jsf\lib\jstl.jar;C:\java\jwsdp-1.2\jsf\lib\jsf-api.jar;C:\java\jwsdp-1.2\jsf\lib\jsf-ri.jar 
org.apache.catalina.startup.Bootstrap start

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


bug #21252

2003-09-02 Thread Dmitry Beransky
Hi,

I've run into the same problem as described by 
http://issues.apache.org/bugzilla/show_bug.cgi?id=21252 (I'm using Tomcat 
4.1.27).  The bug report's comments say that this issue has been 
fixed.  Anyone knows in what version?

Thanks
Dmitry
Here's the error message I'm getting:

org.apache.jasper.JasperException: Unable to compile class for JSP

An error occurred at line: -1 in the jsp file: null

Generated servlet error:
[javac] Compiling 1 source file
[javac] javac: invalid flag: C:\Documents
[javac] Usage: javac
[javac] where possible options include:
[javac]   -gGenerate all debugging info
[javac]   -g:none   Generate no debugging info
[javac]   -g:{lines,vars,source}Generate only some debugging info
[javac]   -nowarn   Generate no warnings
[javac]   -verbose  Output messages about what the 
compiler is doing
[javac]   -deprecation  Output source locations where 
deprecated APIs are used
[javac]   -classpath  Specify where to find user class files
[javac]   -sourcepath Specify where to find input source files
[javac]   -bootclasspath  Override location of bootstrap class files
[javac]   -extdirsOverride location of installed extensions
[javac]   -d Specify where to place generated class files
[javac]   -encoding   Specify character encoding used by source files
[javac]   -source  Provide source compatibility with specified 
release
[javac]   -target  Generate class files for specific VM version
[javac]   -help Print a synopsis of standard options



at 
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:130)
at 
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:293)
at 
org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:353)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:370)
at 
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:473)
at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:190)
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
[...]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


JspC.setArgs()

2003-08-14 Thread Dmitry Beransky
Is there a way to manually compile jsp under Jasper 2 of Tomcat 4.1.x?
Since JspC.setArgs is package private, I can't find another way to pass
the options to the compiler.  I've tried declaring a class inside
org.apache.jasper package, but am still getting an error:

java.lang.IllegalAccessError: tried to access method
org.apache.jasper.JspC.setArgs([Ljava/lang/String;)V from class
org.apache.jasper.JspCompiler
at org.apache.jasper.JspCompiler.compileJsp(JspCompiler.java:25)
at edu.ucsd.som.jcms.JCMS.processRequest(JCMS.java:87)
at
edu.ucsd.som.jcms.j2ee.JCMSWebApplication.doGet(JCMSWebApplication.java:37)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:536)



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



unexpected java.lang.NoClassDefFoundError: javax/management/MBeanRegistration

2003-08-14 Thread Dmitry Beransky
I'm trying to integrate a custom compiled Tomcat 4.1.27 with Intellj IDEA 
(using a third-party plugin allowing invocation of Tomcat 4.1 from inside 
IDEA).

Tomcat quits almost immediately with the following exception:

java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
Caused by: java.lang.NoClassDefFoundError: javax/management/MBeanRegistration
	at java.lang.ClassLoader.findBootstrapClass(Native Method)
	at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:723)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:292)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
	[...]

I know for a fact that MBeanRegistration class is available as part of 
mx4j-jmx.jar package.  Below is included the entire command line that IDEA 
uses to start Tomcat.

Any thoughts on what might be causing this?  I've found a post suggesting 
that the culprit might be "-Djava.endorsed.dirs".  Is there any merit to 
this claim?

Thanks
Dmitry
C:\java\j2sdk1.4.1_02\bin\javaw.exe 
-Djava.endorsed.dirs=c:\projects\jakarta-tomcat-4.1.27-src\build\bin;c:\projects\jakarta-tomcat-4.1.27-src\build\common\libc:\projects\jakarta-tomcat-4.1.27-src\build\common\endorsed 
-Dcatalina.base=C:\Documents and 
Settings\dberansky\.IntelliJIdea\system\tomcat_JCMS_bbf5da37 
-Dcatalina.home=c:\projects\jakarta-tomcat-4.1.27-src\build 
-Djava.io.tmpdir=c:\projects\jakarta-tomcat-4.1.27-src\build\temp 
-classpath 
C:\java\j2sdk1.4.1_02\lib\tools.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\bin\bootstrap.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\common\lib\activation.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\common\lib\ant.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\common\lib\commons-collections.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\common\lib\commons-dbcp.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\common\lib\commons-logging-api.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\common\lib\commons-pool.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\common\lib\jasper-compiler.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\common\lib\jasper-runtime.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\common\lib\jdbc2_0-stdext.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\common\lib\jndi.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\common\lib\jta-spec1_0_1.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\common\lib\mail.jar;c:\projects\jakarta-tomcat-4.1.2!
7-src\
b 
uild\common\lib\naming-common.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\common\lib\naming-factory.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\common\lib\naming-resources.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\common\lib\servlet.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\catalina-ant.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\catalina.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\commons-beanutils.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\commons-digester.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\commons-fileupload-1.0.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\commons-logging.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\commons-modeler.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\jaas.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\jakarta-regexp-1.2.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\mx4j-jmx.jar;c:\!
projec
t 
s\jakarta-tomcat-4.1.27-src\build\server\lib\servlets-common.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\servlets-default.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\servlets-invoker.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\servlets-manager.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\servlets-webdav.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\tomcat-coyote.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\tomcat-http11.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\tomcat-jk.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\tomcat-jk2.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\tomcat-util.jar;c:\projects\jakarta-tomcat-4.1.27-src\build\server\lib\tomcat-warp.jar 
org.apache.catalina.startup.Bootstrap start

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: unexpected java.lang.NoClassDefFoundError: javax/management/MBeanRegistration

2003-08-14 Thread Dmitry Beransky
At 10:07 AM 8/8/2003, Jean-Francois Arcand wrote:

This plug-in is for which version?
The plugin itself is from Sean Taylor 
(http://www.objectorientedsoftware.com/projects/index.html).  I'm using 
IDEA v. 3.0.4

Can you post the entire stack trace?
Exception during startup processing
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
Caused by: java.lang.NoClassDefFoundError: javax/management/MBeanRegistration
at java.lang.ClassLoader.findBootstrapClass(Native Method)
at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:723)
at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:292)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:250)
at java.net.URLClassLoader.access$100(URLClassLoader.java:54)
at java.net.URLClassLoader$1.run(URLClassLoader.java:193)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:140)
at 
org.apache.coyote.tomcat4.CoyoteConnector.initialize(CoyoteConnector.java:1097)
at 
org.apache.catalina.core.StandardService.initialize(StandardService.java:579)
at 
org.apache.catalina.core.StandardServer.initialize(StandardServer.java:2246)
at org.apache.catalina.startup.Catalina.start(Catalina.java:511)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
... 5 more 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: Jasper2's JspC

2003-08-14 Thread Dmitry Beransky
At 01:16 PM 8/13/2003, Subir Sengupta wrote:
Try using jspc with the -compile flag and see what happens.  Your code is
probably not setting something (I don't know what), which is causing it to
not compile.
You're right.  I found a conflict in option settings between the output 
directory and the jsp file name.  The sample jsp I'm trying to compile is 
located in "/layouts/default.jsp", the webapp root api is set to 
"c:/projects/cms/web" and the output directory is set to "c:/temp".  When 
the jsp file gets precompiled with these settings, the resulting .java file 
gets dumped into "c:/temp/default_jsp.java", but when the compiler is 
getting invoked, it's looking for the file in "c:/temp/layouts/".  I'm 
going to comb through JavaC code to see what exactly it is that I'm missing.

Thanks
Dmitry 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: jasper2

2003-08-14 Thread Dmitry Beransky
Woo-hoo!  Thank you!

At 05:32 PM 8/7/2003, you wrote:
You need to check jasper out with the correct branch. The HEAD branch is 
for 5. You need  tomcat_4_branch

-Tim

Dmitry Beransky wrote:
Ok.  But here's the confusing part.  When I try to compile Tomcat 4.1.27 
with Jasper2, I get error messages complaining that there is so such 
function as TagInfo.hasDynamicAttributes().  Surely, this function was 
introduced in JSP 2.0 and is only available in jakarta-servletapi-5.
However, the instructions for building Tomcat 4.1 tell me to use 
jakarta-servletapi-4 library (besides, I couldn't find a binary 
distribution of v5).  So, any thoughts on what is going on here?
Thanks
Dmitry
At 04:29 PM 8/7/2003, you wrote:


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: Jasper2's JspC

2003-08-14 Thread Dmitry Beransky
At 10:42 AM 8/13/2003, Subir Sengupta wrote:
Use the -compile argument.

At 10:42 AM 8/13/2003, Steph Richardson wrote:
Otherwise, JspC will not create .class files for you, but the java files 
that JspC creates can just be compiled with javac, using
Tomcat's classpath
Here's the thing.  Setting -compile flag forces JspC to call 
Compiler.compile().  I'm already making this call (I'm actually bypassing 
JspC, setting all the options and contexts myself and calling 
Compiler.compile() directly).  Compiler.compile() makes a call to 
generateClass() which in turn invokes Ant's javac task to compile the 
file.  The task completes with no errors or exceptions; I'm stepping 
through the execution in a debugger and I can see that 'success' flag is 
set to true upon the javac's completion.  Yet there is no .class file to be 
found anywhere.

Dmitry

-Original Message-
I'm having partial luck manually invoking JspC and compiling JSP pages on
demand.  I get as far as precomiling to .java, but for the world of me
can't figure out how to get the java class compiled to bytecode.  Looking
at the source code for org.apache.jasper.compiler.Compiler, it appears that
I should be getting a .class as well, but I'm not.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Jasper2 & absolute file paths under Windows

2003-08-14 Thread Dmitry Beransky
Is there a way to successfully run Jasper 2 with Tomcat 4.1 under 
Windows?  I'm looking at the source code and there are a couple of places 
where a check for an absolute path is done by looking if the path string 
starts "/", ignoring the possibility of a windows path like "c:/".  One 
such a place is in ParserController.resolveFileName() (looks like this one 
has been fixed in Tomcat 5, but not 4).  Another place is in 
JspCServletContext.getResource(). Any tips on how to work around this?

Thanks
Dmitry
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


jasper2

2003-08-14 Thread Dmitry Beransky
I'm confused.  Is Jasper2 intended for Tomcat 4 or Tomcat 5?

Dmitry

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Jasper2's JspC

2003-08-14 Thread Dmitry Beransky
Hi,

I'm having partial luck manually invoking JspC and compiling JSP pages on 
demand.  I get as far as precomiling to .java, but for the world of me 
can't figure out how to get the java class compiled to bytecode.  Looking 
at the source code for org.apache.jasper.compiler.Compiler, it appears that 
I should be getting a .class as well, but I'm not.

Can anyone offer any pointers or sample source code I could look at 
(reminder, this is for Japser2)?

Thanks
Dmitry
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: unexpected java.lang.NoClassDefFoundError: javax/management/MBeanRegistration

2003-08-11 Thread Dmitry Beransky
Sheesh!  Turned out, I was compiling Tomcat 4 against the wrong cvs branch 
of jakarta-tomcat-connectors.  Once I checked out the TOMCAT_4_1_27 branch 
and recompiled, the error went away.

Thanks for your help
Dmitry
At 10:39 AM 8/8/2003, Jeanfrancois.Arcand wrote:
Try adding the mx4j jar file to the classpath command line to see if it 
work. Or start using Netbeans or Eclipse (just kidding :-) )

-- Jeanfrancois


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: jasper2

2003-08-08 Thread Dmitry Beransky
Ok.  But here's the confusing part.  When I try to compile Tomcat 4.1.27 
with Jasper2, I get error messages complaining that there is so such 
function as TagInfo.hasDynamicAttributes().  Surely, this function was 
introduced in JSP 2.0 and is only available in 
jakarta-servletapi-5.  However, the instructions for building Tomcat 4.1 
tell me to use jakarta-servletapi-4 library (besides, I couldn't find a 
binary distribution of v5).  So, any thoughts on what is going on here?

Thanks
Dmitry
At 04:29 PM 8/7/2003, you wrote:
Both.

-Tim

Dmitry Beransky wrote:
I'm confused.  Is Jasper2 intended for Tomcat 4 or Tomcat 5?
Dmitry


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: loaded jars

2003-07-17 Thread Dmitry Beransky
At 10:35 AM 7/17/2003, Shapira, Yoav wrote:
Make sure you only have one copy of the digest classes throughout the
tomcat installation.
Sure looks like it:

- There is a copy of commons-digester.jar in ./server/lib/;
- ./common/lib doesn't have it;
- ./common/endorsed doesn't have it;
- the demo app's WEB-INF/lib doesn't have it.
thanks
Dmitry 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


autoloading TLDs

2003-07-17 Thread Dmitry Beransky
Hi,

I've noticed that Tomcat 4.1 autoprocesses .tld files from WEB-INFO 
directory.  I've looked through the servlet specs as well as Tomcat docs 
and couldn't find anything describing this behavior.  Any pointers?

Thanks
Dmitry
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: loaded jars

2003-07-17 Thread Dmitry Beransky
what I meant to say was that I appear to have a single copy of the 
commons-digester.jar throughout the installation, yet I still get the 
error.  Any recommendations for tools dealing with debugging of class 
loading problems?

Dmitry

At 10:49 AM 7/17/2003, you wrote:
At 10:35 AM 7/17/2003, Shapira, Yoav wrote:
Make sure you only have one copy of the digest classes throughout the
tomcat installation.
Sure looks like it:

- There is a copy of commons-digester.jar in ./server/lib/;
- ./common/lib doesn't have it;
- ./common/endorsed doesn't have it;
- the demo app's WEB-INF/lib doesn't have it.
thanks
Dmitry


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: loaded jars

2003-07-17 Thread Dmitry Beransky
At 10:35 AM 7/17/2003, Shapira, Yoav wrote:
Make sure you only have one copy of the digest classes throughout the
tomcat installation.
Sure looks like it:

- There is a copy of commons-digester.jar in ./server/lib/;
- ./common/lib doesn't have it;
- ./common/endorsed doesn't have it;
- the demo app's WEB-INF/lib doesn't have it.
thanks
Dmitry  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


loaded jars

2003-07-17 Thread Dmitry Beransky
Hi,

I'm in the process of setting up Tomcat 4.1.x to run JSF.  At the moment, 
I'm having a hard time trying to figure out why I'm getting 
java.lang.NoClassDefFoundError: org/apache/commons/digester/Rule when 
Tomcat is initializing the content for a demo JSF application.

Is there a tool that would let me look at what jars/classes are currently 
loaded by Tomcat and by which class loaders?

Thanks
Dmitry
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: problems configuring JNDIRealm

2001-12-08 Thread Dmitry Beransky

On Sat, 8 Dec 2001, Craig R. McClanahan wrote:

> There will not be any LDAP activity until you actually *submit* the
login
> screen.  

That's what I meant.  I'm sorry, I should've been more explicit.  I do
submit the credentials and get another 401 back.  Meanwhile, there is no
activity on the LDAP side.

Thanks
Dmitry



--
To unsubscribe:   
For additional commands: 
Troubles with the list: 




problems configuring JNDIRealm

2001-12-08 Thread Dmitry Beransky


Hi,

I'm trying to configure use the JNDIRealm for authentication with Tomcat 
4.0.  I've added the JNDI realm to the local host server of the Calalina 
engine in server.xml file, as per the HOW-TO:

 
   
 ldap://prod.domain.com:389";
roleBase="dc=roles,dc=roles,dc=prod,dc=domain,dc=com"
roleName="cn"
roleSearch="(uniqueMember={0})"
roleSubtree="true"
userPassword="userPassword"
userPattern="cn={0},dc=users,dc=prod,dc=domain,dc=com"
digest="SHA"
  />
 .

When Tomcat first starts I can see it binding to the LDAP server.  However, 
when I try to log in to a resource with a browser (I get a login screen, as 
expected), I don't see any activity on the LDAP side.  I've tried debugging 
the JNDIRealm.java code and surely enough, there is a call to start() and 
open(), but authenticate() never gets called.  To the best of my knowledge 
there aren't any error messages anywhere in the logs.  Any ideas what I 
might be missing, what to look for? Anything else I can do to debug this 
problem?

Thanks
Dmitry 


--
To unsubscribe:   
For additional commands: 
Troubles with the list: 




RE: xalan and problem with locating custom libraries

2001-08-10 Thread Dmitry Beransky

At 06:40 AM 8/10/2001, Larry Isaacs wrote:
>In Tomcat 3.3, a more complex classloader hierarchy is
>built which separates the server classes (which includes
>the server's XML parser) from the web application's classes.
>Now web applications can have their own XML parser.

Thanks for this tidbit! Fortunately, I run a development server, so going 
to 3.3 or 4.0 isn't a problem for me.

Although, I must say, this solution doesn't strike me as the most 
elegant.  At least in the case of an xml parser.  Why should we have 
multiple copies of the same damn thing taking up extra resources?  I feel, 
that the real solution must come from xalan itself.  It should be possible 
to hand Xalan a list of class loaders that it can use to load extension 
functions and elements (actually, most libraries that for whatever reason 
do their own class loading should provide such an option).

Regards
Dmitry




xalan and problem with locating custom libraries

2001-08-09 Thread Dmitry Beransky

Hi,

I need to use XSLT from inside jsp.  I decided to go with Xalan/Xerces and 
in order to make them work under Tomcat (3.2.2), I replaced jaxp.jar and 
parser.jar with xalan.jar and xerces.jar in tomcat's lib 
directory.  Everything works fine, until  in my stylesheets I try to make 
use of custom Java extension functions.  These extension functions are 
specific to the application (context) in which they are running and are 
defined in a jar file located in /WEB-INF/lib of the same context as the 
jsp files that initiate XSLT processing.

The problem is that the xsl engine doesn't see my libraries.  And it makes 
sense, since the engine sits in xalan.jar which is loaded at startup and my 
application libraries are loaded later by a different class loader.  An 
obvious work-around would be to have these libraries loaded at startup 
too.  But I REALLY, really hate doing this, because they simply don't 
belong there.  This doesn't strike me as neither a secure nor a scaleable 
solution.  But it's the only solution I can think of.

Is there something else I can do?

Regards
Dmitry