Re: Serving up a Flash file

2005-02-18 Thread Shey Rab Pawo
Another way of responding to your question would be to say that your
conclusion about Mr. Bainbridge's remarks is only true if you let the
web server do all the work in retrieving the file.  Then, of course,
the reading of the entire request URL must be with the server.  That
is what you seem to have assumed must happen.  But, that is not
necessary.  That is not, in my opinion, even desirable, because it
ties your web application to the logic and the relationship between
the browser and the web server.  The web application ideally should be
decoupled from those assumptions, even if they are usually not.


On Fri, 18 Feb 2005 00:03:40 -0800, Paul Erion <[EMAIL PROTECTED]> wrote:
>     > Shey Rab Pawo <[EMAIL PROTECTED]> wrote:
> > Your conclusion is not correct.  What Mr. Bainbridge told you is true,
> > but that does not restrict where you can store the files on the server.
> 
> Ok, now I'm confused ...
> 
>[Bainbridge]: What you need to do is generate the Flash file in
>in a directory that Jboss/Tomcat serves files from like
>webapps\yourwebappname\flash_files or similar or
>similar and then the value= in your embed needs to be
>relative to the location of the JSP that includes the tag.
> 
> My interpretation of the first part of the above is that the generated
> Flash files need to reside in the web app's directory structure.
> However, you're saying that that's not the case -- they can reside
> wherever on the server.  So, is it the second part of Mr. Bainbridge's
> statement that provides the clue for accessing these files?  That as
> long as the Flash file's path is specified relative to the location of
> the JSP (which includes the "embed" tag), then I'm good to go.
> 
> Paul
> 


-- 
The radiance of all the stars does not equal a sixteenth part of the
moon's radiance, likewise, good deeds giving us merit, all these do
not equal a sixteenth part of the merit of loving-kindness..

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



Re: Serving up a Flash file

2005-02-18 Thread Shey Rab Pawo
You need to break things down and to see what the browser is doing,
what your server is doing, what the web application is doing and what
your business logic is doing.  These all have differing parts to play
in this kind of a situation.  The "URL" is merely the communication
between the browser and your web server.  Your web server can
cooperate with your web application and do anything it wants
independent of the actual "URL" returned.  The HTTP URL is not like a
FILE address.  I use a Struts action, which involves a URL like
"resource.do?file=whatever.swf".  My web server, being aware I am
running Struts, notices that the URL ends in .do and sends the URL to
the Struts controller class, ActionServlet.  The Struts ActionServlet,
having read the configuration details for "resource.do",  sends the
request to a class I call ResourceAction.  ResourceAction is a request
processing class that retrieves resources like swf files and returns
them as an output stream to the client browser.  ResourceAction does
not care about the restrictions the server has in grabbing files and
can go anywhere on my server.  ResourceAction sees the name/value pair
"file=whatever.swf" and uses preprogrammed logic to go get the called
"whatever.swf".

You can do this a lot of different ways.  This is one.  

Do you understand?  It is best to get an idea of how it all works. 
This takes a while.  You will get it but you have to make sure you
understand what is happening, if you want to keep from being confused.


On Fri, 18 Feb 2005 00:03:40 -0800, Paul Erion <[EMAIL PROTECTED]> wrote:
> > Shey Rab Pawo <[EMAIL PROTECTED]> wrote:
> > Your conclusion is not correct.  What Mr. Bainbridge told you is true,
> > but that does not restrict where you can store the files on the server.
> 
> Ok, now I'm confused ...
> 
>[Bainbridge]: What you need to do is generate the Flash file in
>in a directory that Jboss/Tomcat serves files from like
>webapps\yourwebappname\flash_files or similar or
>similar and then the value= in your embed needs to be
>relative to the location of the JSP that includes the tag.
> 
> My interpretation of the first part of the above is that the generated
> Flash files need to reside in the web app's directory structure.
> However, you're saying that that's not the case -- they can reside
> wherever on the server.  So, is it the second part of Mr. Bainbridge's
> statement that provides the clue for accessing these files?  That as
> long as the Flash file's path is specified relative to the location of
> the JSP (which includes the "embed" tag), then I'm good to go.
> 
> Paul
> 


-- 
The radiance of all the stars does not equal a sixteenth part of the
moon's radiance, likewise, good deeds giving us merit, all these do
not equal a sixteenth part of the merit of loving-kindness..

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



Re: Serving up a Flash file

2005-02-17 Thread Shey Rab Pawo
Your conclusion is not correct.  What Mr. Bainbridge told you is true,
but that does not restrict where you can store the files on the
server.

> So, if I understand you (and remember
> I'm a bit dense) it's just not possible, via the "embed/object" tag to
> specify/access a file that doesn't reside in the directory hierarchy
> that JBoss/Tomcat serves files from.
> 


-- 
The radiance of all the stars does not equal a sixteenth part of the
moon's radiance, likewise, good deeds giving us merit, all these do
not equal a sixteenth part of the merit of loving-kindness..

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



Odd temp file being created: "+~JF38289.tmp"

2005-02-15 Thread Shey Rab Pawo
I hope that this is a Tomcat question.  I am using Tomcat 5.0 and
Struts 1.2.6.  I am getting a temp file seemingly related to my fonts
whenever I dynamically create new image buttons on the fly, which I do
on almost all pages, and then cache them.  My code to get the fonts,
reading from .ttf files, is as follows:


  public synchronized static Font getFont(String fontLogicalName,
Map attributes) {
Filefile = null;
Fontfont = null;
FileInputStream fontStream   = null;
String  physicalName = null;
String  familyName   = null;
boolean realValue= true;

physicalName = (String)fonts.get(fontLogicalName + "FONT");
familyName   = (String)fonts.get(fontLogicalName + "FAMILY");

attributes.put(TextAttribute.FONT,fontLogicalName);
attributes.put(TextAttribute.FAMILY,familyName);

if(physicalName == null) {
  try {
font = new Font(attributes);
  } catch (Exception e) {
// ERROR HANDLING
  }
}

try {
  file = new File(MY_CLASSPATH_TO_FONT_FILE);
  fontStream = new FileInputStream(file);
  font = Font.createFont(Font.TRUETYPE_FONT,fontStream);
  font = font.deriveFont(attributes);
  fontStream.close();
} catch (FileNotFoundException fnfe) {
  // ERROR HANDLING
} catch (IOException ioe) {
  // ERROR HANDLING
} catch (FontFormatException ffe) {
  // ERROR HANDLING
}

return font;
  }

Does anyone see why I am getting these files?  Is this Tomcat related?
 The names are like "+~JF38289.tmp".  Any help?


-- 
The radiance of all the stars does not equal a sixteenth part of the
moon's radiance, likewise, good deeds giving us merit, all these do
not equal a sixteenth part of the merit of loving-kindness..

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



Re: Session Objects

2005-02-08 Thread Shey Rab Pawo
Could you explain why this won't work across a cluster?  Thanks.


On Tue, 8 Feb 2005 17:28:59 -, Dale, Matt <[EMAIL PROTECTED]> wrote:
> 
> Yes it will, this won't work accross a cluster. 
> Hi all,
>   I' am storing session objects in a SINGLEON class object to keep all 
> active sessions. Does it give any problems in clustered enviornment since 
> singleton is a static referrence.
> 
> Regards,
> Jagga
> 

-- 
The radiance of all the stars does not equal a sixteenth part of the
moon's radiance, likewise, good deeds giving us merit, all these do
not equal a sixteenth part of the merit of loving-kindness..

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