Re: Bean -> DOM

[Incze Lajos]

On Fri, Mar 01, 2002 at 02:38:20PM +0300, Roman V. Petrov wrote:
> Did anyone write JavaBean->XML DOM converter that
> can be used with Struts? Sources, URLs and ideas
> will be appreciated.
> 
1. domify.sourceforge.net.
2. jakarta-commons/jxpath (xpath access to bean and/or xml resources)

Not DOM, but may fill your bill

and MANY-MANY others. The order above is not by rank. I simply supposed
that you want to give your beans to some xml mechanism (e.g. xsl) to
process. Domify is simply that. I've mentioned the jxpath, also
because it seems to me a more inventious answer to the same question.

incze

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Form beans and JAXB........

[Incze Lajos]

On Fri, Jan 11, 2002 at 10:31:54PM -0600, Niraj Juneja wrote:
> Hi Jon,
> 
> Thanks for the reply,
> 
> I have not worked with Castor so I cannot comment on that(although I did get
> an email from castor to evaluate their product).
> 
> As far as JAXB goes. Right now it is in Early Access and I think it is due
> its first relase now. In its Early access release it supports only DTD's but
> one of the goals of the specification is to support XML Schema. So I guess
> the first release should support XML Schema.
> 
> On Validation : I believe the validation it does is whatever validation you
> can describe in your schema. So if you say that your Element can contains
> boolean so the Validation will check for stuff like that. But I am not sure
> if by validations you mean stuff like the "Date should be in between X and Y
> days".  I don't think JAXB can do validations like this...
> 
> Yes I did read about the Form Beans / and the XML schema thread. In my
> opinion the struts developers should concentrate on making Form beans JAXB
> compliant rather than writing one more XML/object product. 
> 

You also can consider the "Zeus" (zeus.enhydra.org).

incze

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 5821] New: - Upload failed on load some binary file.

[Incze Lajos]

> Upload failed on load some binary file. 
> 
>Summary: Upload failed on load some binary file.
>Product: Struts
>Version: 1.0 Final
>   Platform: PC
> OS/Version: Other
> Status: NEW
>   Severity: Blocker
>   Priority: Other
>  Component: File Upload
> AssignedTo: [EMAIL PROTECTED]
> ReportedBy: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED],[EMAIL PROTECTED]
> 
> 
> I used FormFile to upload a binary file. 
> I tried following: 
> text file, the upload succeed.
> java class file, succeed. 
> pix image file, failed. 
> pix pdm file failed. 
> 
> In the case of failure. the checksum of binary file is changed, even though the 
> size is still same. 
> 
> I am using w2k and IE browser.

It can be a tomcat issue, not struts. You could find similar reports on the
tomcat list. Check the tomcat upload fail reports, maybe you have to upgrade
your tomcat (and maybe apache connector).

incze

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: FW: Opinion on design ideas???

[Incze Lajos]

> Though, I suppose, if someone really, really doesn't want to forward
> control, 
> another approach would be to use a "ViewAction" as a base class, and
> then 
> call a render method at the end of perform. 
> 
> public ActionForward render(
> ActionMapping mapping, ActionForm form,
> HttpServletRequest request, HttpServletResponse response) 
> throws IOException, ServletException;
>  
> If the rendering process needed to be tweaked, then the subclasses would
> all inherit the changes on the next compile. 
> 
> If you had more than one rendering technique, there could be more than
> one base class in the hierarchy, and if the interfaces were compatible,
> you could just change which one it extends. 
> 
> If the base class extended org.apache.struts.actions.DispatchAction,
> then you could also call the render method directly, and forego the
> subclass.
> 
> This eliminates another pass through the forward guantlet, and the 
> ActionForm and ActionMapping would be unchanged.
> 
> If "render" were used an adapter, the rendering logic could be put
> into another class, that render would call in the same way 
> other Actions call business logic, so that the whole thing is 
> not hopelessly bound to Struts.
> 
> An embarrassment of riches, this framework ;-)
> 
I want to stop myself, but can't resist now. This is exactly the design
we talked about: with only one difefrence: that should reside one layer up,
in the controler. It feds both the servlet dispatcher techniques and the
other possibilities. You could use even pluggable adapters atc. etc.
Now, I'll really stop on this. Promise.

incze

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: FW: Opinion on design ideas???

[Incze Lajos]

> > That was the one side of the coin. The other is the dispatcher mechanism.
> > It was only a _question_, I am really wonder, why does it count to be
> > the standard, that you give the rendering to a different SERVLET.
> > Is there any advantage (e.g. in the above example using an XSL servlet
> > and forward to it)?
> 

Thanks Craig and Ted for the answers. Will be thinking on them.

incze

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: FW: Opinion on design ideas???

[Incze Lajos]

> You should note, however, that it is also possible for an Action to create
> the view directly, if you want to:
> 
>   public ActionForward perform(...) ... {
> 
> ...
> PrintWriter writer = response.getWriter();
> writer.println(...);
> ...
> return (null);
> 
>   }
> 
> Returning null, instead of an ActionForward instance, tells the controller
> servlet that the response has already been created.  Of course, you could
> do other things (like call a Velocity template) instead of writing the
> response directly, as well.
> 
> Thus, anything for rendering the view layer that is accessible only
> through API calls is also usable in Struts.
...
> Craig

I know, I know. But: do you want to rewrite your action e.g. just because
X team decides to change the view presentation mechanism? Clearly not.
You really want that the action update the model and then depending on
the result of the update operation and the current running context give
back and abstract view to be presented.

E.g. you have some form to add a customer to your customer base. After
the action you want to present the list of your customers. Up until
now, you've used jdbc/jsp. Now your collegue decides to kepp the customers
in XML file. The cheapest way now is to give the file to an xsl sheet
to render. But the action should remain the same: update the customer list
and give back that you'd like to render the table of current customers.

Currently, in this situation you have to change your original action and
writing the new rendering. If the actionservlet would use ActionForwards as
facades (the same way as with Action itself) you have to write only the
new rendering. If these renderings were general enough to be configurable
by struts config - then you have to write nothing, just change the
configuration. I think that's all what I was speaking about (and if
I did not misunderstood him, Donnie Hall). It's only seems to me that 
this way it is easier to attach configurable view mechanisms to the
framework and the coupling between the controler servlet, the user actions,
and the rendering mechanisms would become minimal.

That was the one side of the coin. The other is the dispatcher mechanism.
It was only a _question_, I am really wonder, why does it count to be
the standard, that you give the rendering to a different SERVLET.
Is there any advantage (e.g. in the above example using an XSL servlet
and forward to it)? 


incze

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: FW: Opinion on design ideas???

[Incze Lajos]

On Mon, Dec 03, 2001 at 03:29:26PM -0500, Ted Husted wrote:
> The standard ActionForward and ActionInclude Actions create a
> RequestDispather in the Action, and do call another servlet directly,
> without going back to the container. 
> 
> http://jakarta.apache.org/struts/api-1.0/org/apache/struts/actions/ForwardAction.html
> 
> I recently suggested some additional methods for ActionServlet which
> would allow one Action to call another, in case there was a centralized
> Action that was rendering a view. I'm just waiting for someone to offer
> to test it, since this is not something I need to do myself.
> 
> To support JavaServer pages, we do eventually have to forward back to
> the container, so the JSP can be rendered. AFAIK, there is not a
> portable way that the ActionServlet could "call" a JSP directly. So
> forwarding is the default because it should be able to get you anyplace
> you want to go. 
> 
> But nearly anything that is possible in a servlet, is possible in an
> Action, if you want to do it. 

What Donnie Hall wrote seems to be a symmetric solution, all the others
are just workarounds.

You would have Action - to raise user events to the model
  and  ActionForward - to render a view choosen by the action

The Controler only knows that the Action "performs" and the ActionForward
"renders" (or "processes" or "forwards" or whatever). Then you can have
ForwarderActionForward, IncludeActionForward, CallerActionForward, 
BuilderActionForward etc. Just: the Forwarder... gets a dispatcher and forwards,
the Caller... just calls something, the Builder... works from custom properties
etc. If you do this you can use the _very_same_action_ to raise an event
and give back a logically defined ActionForwarder and don't have to bother
in the event branch of the processing what _technical_ mechanism for the
view was choosen. I think that the processActionForward() code in the
ActionServlet should be the very same like the ProcessActionPerform.
Why not the Actio? Because it should be separate from the rendering
mechanism.

incze

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: FW: Opinion on design ideas???

[Incze Lajos]

No, the question is entirely independent from velocity. There are
many possibilities to render a view. E.g. Maverick "domifies" a data
structure and gives it to an XSL transformer, etc. What I was wonder
was simply the WRAPPING of the view helper. To me it seems to be
natural to hide (and make it configurable) the calling mechanism
of the view renderer. You can dispatch a servlet from a wrapper object
if yo want. What bothers me is that in ActionServlet a new servlet
dispath is wired. (I do understand that it can be a velocity servlet,
an xsl servlet etc.) The question is: why is the default to dispatch
a new servlet? What is my benefit over a simple call (that could dispatch
a new servlet if needed)?

 see that what you wrote ("Typically, the View Helper is another servlet...")
seems to be a commonplace somehow - but don't understand.

Anyway, don't bother with me, if that's the course, let be it the
course. Just wanted to learn something. Thanks

incze

On Mon, Dec 03, 2001 at 01:56:06PM -0500, Ted Husted wrote:
> If the one and only goal is getting Struts to use Velocity templates,
> then, yes, a VelocityAction is going work every bit as well as a
> VelocityServlet. And maybe that's the way to go. A developer could
> choose to either extend it, or maybe just forward to a base
> VelocityAction that did what the VelServlet is trying to do. Both
> approaches could probably be supported at once.
> 
> But, if it were me, I'd first think in terms of a VelocityServlet that
> is designed to answer from a URI, and create a chained VelocityContext
> from a request/session/application contexts. 
> 
> Then, I would subsubclass that into a VelocityActionServlet that knew
> about the Struts resources. (If that part were actually needed.)
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/struts/
> 
> 

> > > Typically, the View Helper is another servlet, but there's no reason why

> > >
> > 
> > I've never understood this claim. As I see a servlet is a processing unit
> > of an HTTP request/response turn. You want to isolate a servlet if the
> > iprocessing unit is directly callable from the HTTP connection. There is
> > no any other structural feature in the servlet over a simple subroutine call
> > to a view. Even you have to work some to put everything into the request
> > that could be available otherwise. I can't see any benefit in declaring
> > that the viewer helper is another servlet if it was not actvatable directly
> > from outside by an URL. Am I missing something?
> > 
> > incze

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: FW: Opinion on design ideas???

[Incze Lajos]

> Typically, the View Helper is another servlet, but there's no reason why
> it couldn't be another Action. (After all, the dispatchers are typically
> servlets too.) 
...
> > 
> > I agree with that to the extent that the view will be in another servlet,
> > which means in the vast majority of cases. My primary concern with overuse
> > of the contexts is in things not directly related to the request / session
> > itself.
> > 
> 

I've never understood this claim. As I see a servlet is a processing unit
of an HTTP request/response turn. You want to isolate a servlet if the
iprocessing unit is directly callable from the HTTP connection. There is
no any other structural feature in the servlet over a simple subroutine call
to a view. Even you have to work some to put everything into the request
that could be available otherwise. I can't see any benefit in declaring
that the viewer helper is another servlet if it was not actvatable directly
from outside by an URL. Am I missing something?

incze

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: About Log4j using

[Incze Lajos]

>   Can anybody suppose any idea about logging mechanism or about some
>   logging implementation without static stuff?
>   
> -- 
> Best regards,
>  Oleg  mailto:[EMAIL PROTECTED]

I'm not sure that with or without statics but some generic logger interface
work has started in the commons project. It's in a very early state and
gives you a generic Log interface and a LogSource factory which defaults
to log4j if available or to a NoOpLog logger if not. I think the plan was
to adapt this intterface to avalon's logkit and jdk1.4's log package, too.

incze

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: WML Tag library on TO DO list

[Incze Lajos]

On Sun, Aug 12, 2001 at 10:32:24PM +0300, smtp1.ixir.com wrote:
> 
>   Hi,
>   I have been listening for a while and have not heard anything on WML tag
> library.
>   Did anyone volunteered on this issue and I missed that. The reason I am
> asking
>   is I have a WML tag library I can contribute. It needs some work to cover
> all the
>   WML tags and also needs some polishing but I can start working on it.
> 
>   Regards
> 
>   Gorkem
> 

Don't exactly know what WML means at the moment. But. To start a WML 1.x
would be wasting of efforts as WML goes to be xhtml and mobile displays
are evolving very quickly. (And yes, people will by them, you can
be sure, I know them.) But if WML will be xhtml then there is not
real no special task. I would rather propose a see and wait position.


incze

DbForms

[Incze Lajos]

Don't know, how aware the list is of this:

http://www.dbforms.org/

and an article:

http://www.onjava.com/lpt/a//onjava/2001/07/18/dbforms.html
--
(Seems to support Struts.)

incze

FYI: WebSphere Version 4 Application

[Incze Lajos]

>From theserverside.com:

--
  Posted By: Floyd Marinescu on July 26, 2001 
  A review version of the new Websphere 4
  development Redbook has been posted. This
  amazing redbook covers everything related to
  enterprise desgin from requirements gathering,
  component modeling, project management, an
  overview of Jakarta Struts, Ant, JUnit, EJB
  performance tips and more. 

  The quality of these redbooks never ceases to
  amaze me!
--
See at: http://theserverside.com/home/thread.jsp?thread_id=8121

Re: TODO 1.1 - XML Digester

[Incze Lajos]

On Mon, Jun 25, 2001 at 10:38:56AM -0400, Immanuel, Gidado-Yisa wrote:
> The todo list shows for:
> 
>   XML Digester [org.apache.struts.digester]
> 
> the following task:
> 
>   Refactor Dependencies. Refactor import dependencies, here
>   and within the utilities package, with the goal of being
>   able to use the Digester package in standalone applications
>   without having to import the servlet API classes.
>   [STRUTS-USER, Martin Cooper, 01/02/2001] 
> 
> I looked at the Digester package, and it seems like this has
> already been done.  Did I miss something?

As  digester moved to the "commons" project, I think this todo
item is mislading, anyway. It should simply reflect that the
digester would be imported from commons.incze

WSFL article

[Incze Lajos]

IBM's developerworks now has a gentle introduction on thw WSFL
(webervices flow language) at

http://www-106.ibm.com/developerworks/webservices/library/ws-ref4/index.html?dwzone=webservices


incze

Re: Multipart request handling

[Incze Lajos]

On Sun, Jun 10, 2001 at 07:09:06PM -0700, Martin Cooper wrote:
> Incze,
> 
> The fix for this - unwrapping the request - has been made on the main trunk
> (Struts 1.1) in CVS, but has not been applied to the Struts 1.0 branch. If
> you can, you might want to try using the latest nightly build until the
> change gets into 1.0. There is a bug in Bugzilla (#2039) for this, so
> hopefully it will be fixed before 1.0 ships.
> 
> --
> Martin Cooper
> 

My fault that haven't checked the bugzilla. Just searched the mail lists
at www.mail-archive.com. Haven't seen the sign of this patch but very recent
messages on the user list on the topic. Thanks for the pointer I'll go for
the nightly build. incze

Multipart problems

[Incze Lajos]

Something really went wrong in the multipart request handling
(manipulation).

The only scenario that works at the moment for me, when the
file and the other request parameters all are good, so the
file upload was successful. I'm testing with tomcat3.3 and
tomcat4 (m3 and b5 versions) and the struts b3 version.

When something is wrong the multipart handlibg manipulates
something dirty (rewraps/repackages? the request) and there
is a problem here.

Tomcat3 and Tomcat4 fails differently but that's sensible.
   incze
--
E.g. the log shows this when the filename and upload was ok
but the ActionForm validation routine retuned an error (tomcat4b5,
struts1b3):


2001-06-10 02:16:06 action: Processing a POST for /actions/upload
2001-06-10 02:16:06 action:  Looking for ActionForm bean under attribute 'upload'
2001-06-10 02:16:06 action:  Creating new ActionForm instance of class 
'geocom.mvc.UploadForm'
2001-06-10 02:16:06 action:  Storing instance under attribute 'upload' in scope 
'request'
2001-06-10 02:16:06 action:  Populating bean properties from this request
2001-06-10 02:16:06 action:  Validating input form properties
2001-06-10 02:16:06 action:   Rolling back the multipart request
2001-06-10 02:16:06 action:   Validation error(s), redirecting to: 
/WEB-INF/jsp/submit.jsp
2001-06-10 02:16:07 StandardWrapperValve[action]: Servlet.service() for servlet action 
threw exception
java.lang.IllegalArgumentException: Request is not a 
javax.servlet.ServletRequestWrapper
at java.lang.RuntimeException.(RuntimeException.java:49)
at java.lang.IllegalArgumentException.(IllegalArgumentException.java:45)
at 
org.apache.catalina.core.ApplicationHttpRequest.calculateParent(ApplicationHttpRequest.java:427)
at 
org.apache.catalina.core.ApplicationHttpRequest.setRequest(ApplicationHttpRequest.java:563)
at 
org.apache.catalina.core.ApplicationHttpRequest.(ApplicationHttpRequest.java:126)
at 
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:338)
at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:292)
at 
org.apache.struts.action.ActionServlet.processValidate(ActionServlet.java:2137)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1564)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509)   
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:254)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:194)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:255)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)   
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:225)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:518)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)   
 at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2252)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:446)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)   
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)   
 at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:875)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:952)
at java.lang.Thread.run(Thread.java:498)

Multipart request handling

[Incze Lajos]

I've just verified that the detected behaviour (upload bombs when
form validation fails) has reason. When a validation error occurs
the following code gets executed:

//does our form have a multipart request?
if (formInstance.getMultipartRequestHandler() != null) {
//rollback the request
if (debug > 1) {
log("  Rolling back the multipart request");
}

formInstance.getMultipartRequestHandler().rollback();
}
...
rd.forward(request, response);
return (false);

What is missing here is the code snippet from the normal executionpath:

//set the request back to it's normal state if it's currently wrapped,
//to avoid ClassCastExceptions from ServletContainers if forwarding
if (request instanceof MultipartRequestWrapper) {
request = ((MultipartRequestWrapper) request).getRequest();
}

That's only one point, but the whole ActionServlet code should be scanned
through as there are places (e.g. the forward and include mapping type for
the first sight) where the same problem seems to occur.

incze

Re: Work flow RFC

[Incze Lajos]

On Tue, Jun 05, 2001 at 11:46:58AM -0700, Frye, Dave wrote:
> Keep in mind that Microsoft uses there own version of DTDs and XML Schemas
> that are not W3C conformant.  You would then have to use their XSL tools,
> which, of course, would be Wintel-based.  This would not make for a very
> platform independent solution...
> 

I know of two Workflow DTD's. The one seems to be emerging
beeing a strategic element for the IBM web services effort
(altough the DTD is open). It is the WSFL (Web Services Flow
Language - http://www-4.ibm.com/software/solutions/webservices/resources.html)
which is pretty general, and an even more general one from
the W3C submissions, XTND (XML Transition Network Definition
http://www.w3.org/TR/xtnd/ ). There was an "official" workflow
standard initiative some years ago, but it became really big
(see www.wfmc.org for the Workflow Management Coalition).
Don't think these would give "the" solution, but (mainly the
IBM spec) provide a good vocabulary.   incze

SourceForge: Project Info - Ruby Web Application Framework

[Incze Lajos]

Just interesting. The charter of the project says:

Based on the Jakarta Struts project, the Ruby Web Application framework 
is a framework for developing web/wap applications founded in the Ruby 
programming language.

http://sourceforge.net/projects/ruby-waf/

JSR-000126 template/component specification

[Incze Lajos]

Maybe some of you on the list are interested or even want to
participate. (Just saw in the news.)

http://java.sun.com/aboutJava/communityprocess/jsr/jsr_126.html
   icnze

Re: cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html FormTag.java

[Incze Lajos]

On Sun, Apr 29, 2001 at 03:11:40AM -, [EMAIL PROTECTED] wrote:
> craigmcc01/04/28 20:11:40
> 
>   Modified:src/share/org/apache/struts/taglib/html FormTag.java
>   Log:
>   Migrate the attributes created by the  tag (the form tag
>   instance itself, and a reference to the form bean itself) from page scope
>   to request scope.  Among other things, this change enables the use of a
>   separate JSP page (accessed by  or the template tag library)
>   to contain the input fields, nested inside an  tag instance.

Many thanks.   incze

Re: cvs commit: jakarta-struts/src/share/org/apache/struts/util BeanUtils.java

[Incze Lajos]

>   Port a fix from the "commons" version of this module (which Struts will
>   ultimately migrate to when the commons version is released).
>   

Just some questions. Will the beanutils be facotred out from struts
or they will remain here (with some sort of sync mechanism)? Also,
are there other candidates to be factored out to commons (e.g.
digester)?  incze

Re: struts and cocoon

[Incze Lajos]

> Does Cocoon ship with servlet_2_2.jar inside its WEB-INF/lib
> directory?  If so, that seems like a bad idea, because it would cause
> class loading conflicts in the container.  In general, you should rely on
> the container's installed version of the servlet API classes for whatever
> container you run on.
> 
> The 2.3 (Proposed Final Draft) version of the Servlet Spec requires
> 2.3-compatible containers (like Tomcat 4.0) to support programs built
> against the 2.2 API classes in a backwards compatible fashion.  Right now,
> Struts is only dependent upon 2.2 APIs, so it will run on current and
> future containers.
> 
> Craig
> 
> 
[incze@incze docs]$ tar tzvf /d/GZ/Cocoon-1.8.tar.gz | grep 'servlet.*jar'
-rw-r--r-- 0/0   40944 2000-09-23 00:43:16 cocoon-1.8/lib/servlet_2_2.jar


Don't know how later editions are built. incze

Re: struts and cocoon

[Incze Lajos]

On Tue, Aug 29, 2000 at 10:09:31AM -0400, Ali Ozoren wrote:
> Hi all-
> 
> I’ve been trying to get cocoon and struts together, however one is using the
> servlet.jar the other servlet_2_2.jar.
> 
> Is it possible to combine these two?
> 
> Thanks!
> 
I guess they are the same. Struts has to differentiate because it
works with servlet_2_3.jar, too (even if it doesn't exist officially).
incze

Re: development issues

[Incze Lajos]

On Wed, Mar 28, 2001 at 12:11:37AM +1000, Jim Richards wrote:
> 
> >In Dec-2000 issue of Javaworld, there was an article by "Thor Kristmundsson"
> >about enhancing Struts framework with regex validation and automatic
> >properties. Though the article is outdated due to recent development in
> >Struts but I liked the idea and spent some time implementing it.
> 
> I'm not keen of using regex for the validation of form fields, as I find them too
> limiting. There are somethings you just can't do with regex that a general 
> bit of coding can handle (eg, credit card validation and good date checking).
> 
> 
> --
> Kumera - a new Open Source Content Management System
> for small to medium web sites written in Perl and using XML
> http://www.cyber4.org/kumera/index.html

I do think also, that - as somebody (sorry, I was lazy to search for the name)
mentioned a couple of monthes ago on the list - a java.text-like framework
/MessageFormat, DateFormat, NumberFormat et. al./ is what more appropriate
for a validation framework. In general you have a small grammar that controls
the input string parsing by some XxxxFormat class' parse method when it
tries to translate the input string into the Xxxx class according to a
format description given in the above mentioned small grammar. Also you'll
use the same format description when using XxxxFormat.format() to render
a string from an Xxxx type object. (You will need that when rendering
pages from business data.) Format descriptions can be cached, so
parsing occurs only once. This framework does not exclude using regular
expressions you can use them as one of the well defined grammars. But regexp
is really not enough. You can't validate even a date with it. Also,
you may need internationalization: the java.text framework was built
to cope with it, with regexp you are out of luck.

The other side of the coin is that no doubt this is much more complex
work then with regexps.incze

[jhunter@collab.net: Servlets.com: IE5 file upload workaround]

[Incze Lajos]

[FYI] Don't know that the struts upload module was effected by this
issue.  incze

- Forwarded message from Jason Hunter <[EMAIL PROTECTED]> -

Date: Sun, 25 Mar 2001 13:09:13 -0800
From: Jason Hunter <[EMAIL PROTECTED]>
To: Servlets Announce <[EMAIL PROTECTED]>
Subject: Servlets.com: IE5 file upload workaround

Hi everyone,

I just posted a new build of com.oreilly.servlet to Servlets.com.  I've
enhanced MultipartParser (the file upload component) with a workaround
to handle Internet Explorer 5 browsers that don't send the proper line
breaks.

http://www.servlets.com/resources/com.oreilly.servlet/

-jh-

--
For help subscribing and unsubscribing, email
[EMAIL PROTECTED]


- End forwarded message -

Re: BaseFieldTag

[Incze Lajos]

> I'm not sure this is true. In section 17.12.2 of the HTML 4.01 spec
> (http://www.w3.org/TR/html401/interact/forms.html#adef-readonly) it says; 
> 
> "The following elements support the readonly attribute: INPUT and TEXTAREA."
> 

It is supported according to the dtd (and for the TEXTAREA element, too)
This is form the "strict" dtd, not the "loose" one:






The Html 4.01 spec contains a pertty usable table of the attributes,
what are specified in what dtd ahat are the deprecated ones. It is at
the $SPECHOME/index/attributes.html.  incze

Offtopic: http://jakarta.apache.org

[Incze Lajos]

Does anybody else experiancing this problem or only my ISP
hoosed up it's DNS. From here (Hungary) the whole apache.org
domain is unreachable. http requests sent to jakarta.apache.org
go to h31.sny.collab.net (which seems to have the same IP address
by nslookup. If it's a local problem I can wait and see. incze

Re: Request go ahead for structural changes in CVS

[Incze Lajos]

> If we impose on the developer only that he has the right "ant" or
> "ant.bat" script available in his or her PATH, do we care anything about
> Ant's internal organization?  It seems to me that the Ant environment
> should take care of finding its own pieces.
> 
> Craig
> 

Everything used to work seemlessly until somebody comes up
with some dependent ant tasks and supposes a "normal" ant
dist environment. This can be avoided but there is a pretty
strong coherence in the apache group and sometimes these
dependencies remain in the scripts. E.g. the current build
script contains the servlet.jar at it's usual jakarta project
place and if you don't have this jar at that place, the build
will fail (as the target compile.library does not include
the system classpath. (I routinely issued - almost every day -
an 'ant clean; ant dist' command with my preset classpath, and
experianced that the clean build fail. Ok, I could override
the servlet.jar with ant -D) Build.sh contains the usual _HOME
dirs and places things at their usual relative places.

So, I wholehartedly support the bare ant command, just wanted
to raise the exclam mark that in general these properties can't
suppose the "normal" HOME dir layout. Users can gather their
common parsers, jars etc. (I used to fail - now have 15 xalan.jars
23 xerces.jars, 17 parser.jars, etc.) We should have classpath
properties independent form .home properties, etc.incze

Re: Request go ahead for structural changes in CVS

[Incze Lajos]

On Mon, Mar 19, 2001 at 08:16:46PM +0100, Incze Lajos wrote:

> I can cause some difficulties to ant's RPM-distribution-linux-users as it's
> directory scheme follows the some Linux file system standards, not the
> original ant distribution. (On the other hand it can be repaired with some
> symlinks. So, at least a warning would be nice. E.g. the ant binary structure
> is this one:
> 

Terrible copy/paste (1st line is missing):
/usr/bin/ant
> /usr/doc/ant-1.2
> /usr/doc/ant-1.2/LICENSE
> /usr/doc/ant-1.2/README
> /usr/doc/ant-1.2/TODO
> /usr/doc/ant-1.2/WHATSNEW
> /usr/share/ant/bin/antRun
> /usr/share/java/ant.jar
> /usr/share/java/jaxp.jar
> /usr/share/java/optional.jar
> /usr/share/java/parser.jar)
>incze

Re: Request go ahead for structural changes in CVS

[Incze Lajos]

On Sun, Mar 18, 2001 at 02:30:55PM -0800, Craig R. McClanahan wrote:
> 
> 
> On Sun, 18 Mar 2001, Vincent Massol wrote:
> 
> > Here follows the status (inline in the mail below). Please tell me if I have
> > made any blunder and I'll correct it. Also, I have made some changes that
> > are against standards/issues that have been approved/agreed upon (like
> > formatting of Ant build files, ...), please tell me and I'll correct it.
> > Thanks.
> > 
> > - Original Message -
> > From: "Vincent Massol" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Sunday, March 18, 2001 1:11 PM
> > Subject: Request go ahead for structural changes in CVS
> > 
> > 
> > > I'd like to have the go ahead for making the changes to the struts
> > directory
> > > structure, as mentionned in the thread "[PROPOSAL] Struts Source Directory
> > > Structure".
> > >
> > > Namely, I'd like to commit the following changes that I have locally on my
> > > computer (step 1) :
> > > - Move jakarta-struts/src/doc to jakarta-struts/doc
> > 
> > done
> > 
> Fine.
> 
> > > - Move jakarta-struts/src/conf to jakarta-struts/conf
> > 
> > done
> > 
> Also fine.
> 
> > > - Move build.xml, build.bat and build.sh to the new jakarta-struts/build
> > > directory
> > 
> > waiting for approval
> > 
> 
> I'm fine with the organizational change, and I modified the output of all
> the build processes to go to "target" instead of "build" now.
> 
> One thing I've been toying with is how we can get out of having
> "build.sh" and "build.bat" scripts completely, and just use the
> "ant" script (from $ANT_HOME/bin) directly to run our builds.  In order to
> set local environment variables, how about this:
> 
> * If there is a "build.properties" file in the directory you are
>   running the build from (this will be "build" after the scripts
>   are moved), load it at the top of build.xml.
> Note that the dependency on Ant would be that you have $ANT_HOME/bin on
> your PATH in order to execute the builds by typing things like:
> 
>   ant compile.javadoc
> 
> instead of saying
> 
>   ./build.sh compile.javadoc
> 
> What do you think?

I can cause some difficulties to ant's RPM-distribution-linux-users as it's
directory scheme follows the some Linux file system standards, not the
original ant distribution. (On the other hand it can be repaired with some
symlinks. So, at least a warning would be nice. E.g. the ant binary structure
is this one:

/usr/doc/ant-1.2
/usr/doc/ant-1.2/LICENSE
/usr/doc/ant-1.2/README
/usr/doc/ant-1.2/TODO
/usr/doc/ant-1.2/WHATSNEW
/usr/share/ant/bin/antRun
/usr/share/java/ant.jar
/usr/share/java/jaxp.jar
/usr/share/java/optional.jar
/usr/share/java/parser.jar)
   incze

Re: content map population

[Incze Lajos]

On Tue, Mar 13, 2001 at 09:57:36AM +0100, Cedric Dumoulin wrote:
> 
>   Not yet, but in a few days I will provide such facilities for
> Templates. If you want to know how it will work, I have put an extract
> of a previous mail at the end of this mail.
> 
> Cedric

Will be this facility part of the 1.0 struts release or it is for the 1.1
(not-yet-existent) source tree? incze

Re: Using session bean for action form is a design flaw

[Incze Lajos]

On Thu, Mar 01, 2001 at 01:18:55PM -0500, Tony & Kian Heffner wrote:
> Hi,
> Since action form is stored as JSP session bean, large scale web application
> that are running on a load balancing cluster environment will not be able to
> use Struct.

Could you give some details why do you think so? Just courious.
incze

Re: localizing direct template content with bean:message

[Incze Lajos]

On Thu, Mar 01, 2001 at 12:46:17PM -0500, Deadman, Hal wrote:
> I wanted to localize direct content when using templates such as the
> title of a page. I modified the bean:message tag so it would read its
> key from the tag body if it wasn't specified as an attribute. Is there a
> better way to internationalize direct content with templates? Are there
> any other reasons that someone would want to get the bean:message key
> from the body of the tag? Are there reasons why this doesn't make sense?
> 
>  
> 
> 
> 
> 

You don't need to modify the current code as your goals are pretty
straight with it:


  


and



 incze

Re: cvs commit: jakarta-struts/src/doc todo-1.1.xml

[Incze Lajos]

On Tue, Feb 20, 2001 at 05:28:31PM -, [EMAIL PROTECTED] wrote:
> craigmcc01/02/20 09:28:30
> 
>   Modified:src/doc  todo-1.1.xml
>   Log:
>   Correct email contact address for Rob.
>   
>   TODO:  figure out why my stylesheet is eating the  tags on volunteers...
>   

You explicitely say the XSLT script to drop out the anchor tag
and preserve only the text content. That's what the xsl:valuof
element does.

  

  

  
.
  


  
  
  ^


Instead a simply apply-template would do, which would conclude
into the default template there. incze

Re: Automatic Form filing

[Incze Lajos]

On Wed, Jan 31, 2001 at 04:50:51PM -0800, Craig R. McClanahan wrote:
> Incze Lajos wrote:
> 
> > On Wed, Jan 31, 2001 at 01:55:46PM -0800, Joerg Beekmann wrote:
> > >
> > >
> > > > Is it really a security risk, though?  Remember that the
> > > > password displayed here
> > > > did *not* work (otherwise, the user would have been logged
> > > > in), so a potential
> > > > attacker is not learning anything new.  After all, they can
> > > > just try various
> > > > username and password combinations on your login screen, and
> > > > find out exactly the
> > > > same thing, even if the password text were not echoed.
> > > >
> > > I don't understand, seems to me the attacker is learning something.
> > > Two likely reasons for a failed login are:
> > > - simple typo; in this case trying a few variations or in many cases
> > > correcting the spelling will get the attacker in.
> > > - the user has multiple passwords and typed the wrong one. This
> > > might compromise other systems
> > >
> > > Joerg
> >
> > I fully understand to Joerg. Refrain the password (which can be seen
> > in hte HTML source view) is a bug.
> >
> > 1. As any sysadmin can tell you, users - if they can - will select
> >meaningful passwords. I sight enough somtimes to know what the typo
> >was, and what the real passowrd is.
> >
> > 2. Another issue is privacy. Users think what they type TOTALLY ENCRYPTED
> >and you can get very inconvenient situations when something thought
> >to be secret will be unveiled in clear text. So, it's simply HURTING
> >A CONTRACT (that's why I'm calling it bug, not risk).
> >incze
> 
> These arguments make sense ... I just checked in a patch.
> 
> Note that doing this breaks a different contract ("all Struts form tags
> redisplay the previous values from the corresponding form bean property"),
> but in the case of conflicting goals security needs to win.
> 
> Craig
> 
I think not echoing the password is a better solution even in this respect.
You echo user input on purpose: she can see the value that was input by
her. But do you really give her this feedback in case of the password field?
Not, she can only see BULLETS, and the best she can do (if does not want to
mine after the error in the page source) to CLEAR ACTUALLY THE PASSWORD 
FIELD and retype the password. So, echoing back the wrong password is not
the same than echoing back a text input field. It is worse in the usability
or feedback point of view, also.incze

Re: Automatic Form filing

[Incze Lajos]

On Wed, Jan 31, 2001 at 01:55:46PM -0800, Joerg Beekmann wrote:
> 
> 
> > Is it really a security risk, though?  Remember that the 
> > password displayed here
> > did *not* work (otherwise, the user would have been logged 
> > in), so a potential
> > attacker is not learning anything new.  After all, they can 
> > just try various
> > username and password combinations on your login screen, and 
> > find out exactly the
> > same thing, even if the password text were not echoed.
> > 
> I don't understand, seems to me the attacker is learning something. 
> Two likely reasons for a failed login are: 
> - simple typo; in this case trying a few variations or in many cases 
> correcting the spelling will get the attacker in.
> - the user has multiple passwords and typed the wrong one. This 
> might compromise other systems
> 
> Joerg

I fully understand to Joerg. Refrain the password (which can be seen
in hte HTML source view) is a bug.

1. As any sysadmin can tell you, users - if they can - will select
   meaningful passwords. I sight enough somtimes to know what the typo
   was, and what the real passowrd is.

2. Another issue is privacy. Users think what they type TOTALLY ENCRYPTED
   and you can get very inconvenient situations when something thought
   to be secret will be unveiled in clear text. So, it's simply HURTING
   A CONTRACT (that's why I'm calling it bug, not risk).
   incze

bean define with scripting funs

[Incze Lajos]

Weird thing at  (probably a tomcat error - I use
tomcat 3.2.1 with the IBM jdk 1.3 on linux): 

Here is a sample JSP (copied from the "Bean User Guide"):

--
<%@page language="java" contentType="text/html;charset=ISO-8859-1"%>

<%@ taglib uri='/WEB-INF/struts-bean.tld' prefix='bean' %>



--

and here is the result:

--
Error: 500

Location: /matademo/WEB-INF/jsp/main.jsp

Internal Servlet Error:

org.apache.jasper.JasperException: Unable to compile class for JSP
at java.lang.Throwable.(Throwable.java:96)
at java.lang.Exception.(Exception.java:44)
at javax.servlet.ServletException.(ServletException.java)
at org.apache.jasper.JasperException.(JasperException.java)

... etc. The relevant portion comes here:

Root cause: 

java.lang.ClassCastException: java.lang.Object
at javax.servlet.jsp.tagext.TagData.getAttributeString(TagData.java)
at org.apache.struts.taglib.bean.DefineTei.getVariableInfo(DefineTei.java:89)
at javax.servlet.jsp.tagext.TagInfo.getVariableInfo(TagInfo.java)
--

The offending code seems to be pretty innocent:

// from org.apache.struts.taglib.bean.DefineTei.java:

public VariableInfo[] getVariableInfo(TagData data) {

String type = data.getAttributeString("type");
if (type == null) {
if (data.getAttributeString("value") != null) //  Line 89
type = "java.lang.String";
else
type = "java.lang.Object";
}

--

As a temporary measure I give type attribute at bean:define and it works.

--
<%@page language="java" contentType="text/html;charset=ISO-8859-1"%>

<%@ taglib uri='/WEB-INF/struts-bean.tld' prefix='bean' %>



--

=
OFF TOPIC:

In tomcat 3.2.1 there are a couple of "showstopper" errors (e.g.
getUserPrincipal().getName() overlives sessions and sticks to the
first logged in user, I have illegal access exceptions if I want
to prepare struts bean variable from request, e.g.


 bombs with illegal access
exception

etc.)
=

So, the question. Doea anybody experiance these things in other
environments or these are simply Tomcat bugs (in this case I will
report it there). (OFF TOPIC: does anybody know when do we have
a next bug fix release of Tomcat. I'd like to use it, but it's
almost impossible at the moment - Imean: too much workaround).
know when will be a release o

Tia  incze

Re: make template content classes serializable

[Incze Lajos]

On Wed, Jan 17, 2001 at 10:42:48PM -0800, Craig R. McClanahan wrote:
> It is on my list (if nobody beats me to it).  Got stuck in an all day meeting
> today.
> 
> Craig

Somebody has beaten you. In my generated javadoc I see:

public class Content
extends java.lang.Object
implements java.io.Serializable

and

public class ContentMap
extends java.lang.Object
implements java.io.Serializable

It's some days old.  incze