jsp:include works fine but not bean:include

[Raj Tilak <ra...@hotmail.com>]

new dns names were added on the new server.
it works fine on local host

but on the default domain server bean:include gives
java.net.ConnectException: Tried all: '1' addresses, but could not connect 
over HTTP to server: 'servername: port'

although the servername and port printed in exception are right.
This works fine with jsp:include.

Does anybody encountered this and resolved it.
Reply would be highly appreciable.

Thanks
Panchasheel

>From: Adam Hardy <ah...@cyberspaceroad.com>
>Reply-To: "Struts Users Mailing List" <us...@struts.apache.org>
>To: Struts Users Mailing List <us...@struts.apache.org>
>Subject: Re: talking about paradigms
>Date: Tue, 16 Nov 2004 17:00:48 +0000
>
>Using filters and different modules for delivering different HTML for 
>different browsers is known in the HTML/CSS world as browser sniffing, and 
>is frowned on by the HTML designer purists, but in the real world such 
>modules could definitely be a highly attractive.
>
>Alot would depend on what you want and how you decide to do it. I'm not 
>sure that it's even worthwhile at this stage in the evolution of the web to 
>generalise.
>
>One issue that I'm looking at as a problem is where to switch between 
>modules, e.g. one for state-of-art HTML with accessibility for the blind 
>and one for 20th Century browsers. I mean, would you want both to have the 
>same URL for the sake of search engines and reference?
>
>It's a big question. You would keep the switch mechanism in the view, 
>right? Perhaps with a filter, or with switches in tiles layout JSPs or 
>definitions?
>
>On 11/16/2004 02:57 PM Dakota Jack wrote:
>>Hello, Adam,
>>
>>You are definitely right that this is a crucial part of any web
>>application, and not only for browsers but also for flash, javascript,
>>etc. versions.  This is so important in the overall picture for web
>>programming that perhaps a whole separate set of interfaces amounting
>>to a separate "module" or "component" should be developed in a
>>pluggable way.  This sort of functionality would seem to be best
>>utilized in something like a filter.  What do you think?  Even though
>>my emphasis is on functionality and separation of concerns, I am
>>definitely putting this on the TODO list.  Thanks.
>>
>>Jack
>>
>>
>>On Tue, 16 Nov 2004 10:17:23 +0000, Adam Hardy
>><ah...@cyberspaceroad.com> wrote:
>>
>>>Jack,
>>>one thing you missed off the diagram is the HTML reader. A public
>>>website often has to cater for:
>>>
>>>- old browsers like Netscape 4
>>>- text only browsers like lynx
>>>- PDA browsers with no javascript etc
>>>- spiders which ignore sessions
>>>- screen readers for the blind
>>>
>>>all of which make strong demands on the view and often require extra
>>>output from the model.
>>>
>>>Adam
>>>
>>>
>>>
>>>On 11/15/2004 07:46 PM Dakota Jack wrote:
>>>
>>>>The whole discussion about MVC and web frameworks is important, I
>>>>think, because not many cash it out when to do so (cash it out) would
>>>>be helpful for discussion.  We might try some way of refering to this
>>>>such as WEBMVC.  Anyway, the MVC pattern, taken literally, is
>>>>impossible in a web framework.  What is possible is something like the
>>>>following where the arrows indicate where there is a coupling:
>>>>
>>>>  View <==> Controller <==> Model
>>>>
>>>>Here the Model and the View are completely decoupled.  But, even this
>>>>is almost a total representation of what is really going on.  What is
>>>>really going on is that the response object is ultimately HTML and
>>>>that the JSP pages are part of creating the response object, so that
>>>>JSP pages inherently provide a smart-serverside View.  This all is not
>>>>simple to cash out.  I have a sample beginning of cashing this out at
>>>>http://131.191.32.112:8080/ , which, if others want to provide
>>>>alternative way of viewing this I will show them all.  The most
>>>>important thing, I think, is to distinguish between the View data and
>>>>the Model data.  That is the distinction, I think, that Craig makes in
>>>>JSTL between iteration and sql statements in JSP.
>>>>
>>>>Jack
>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>
>>
>>
>
>
>--
>struts 1.2 + tomcat 5.0.19 + java 1.4.2
>Linux 2.4.20 Debian
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org