Portability is still very important even though it may not seem important
at any one particular time when you know how everything is to be done.
The problem is that things change over time. Here are some events that
can require portability even when you thought you'd never need it.
1. You could move to a different version of UNIX with a slightly
different file system where the assumptions you once made about the
filesystem layout are no longer valid. Maybe your company is using AIX
now, but eventually they will realize the that Linux is the future.
2. You might decide to switch to specialized hardware that just runs a
JVM or Java operating system which does not have a normal UNIX
filesystem. I don't know what this might be, but it's possible that
somebody might make some product like this that is worth using, at least
to run an EJB server.
3. Your company may replace your CTO with someone who wants everything to
run on Windows 2000. A catastrophe, for sure. That's an extreme case,
but you could imagine something similar but more realistic.
4. Your company may acquire a smaller company who insists on using
Windows NT or AS/400 machines and your EJB business objects have to run
on their machines so that your businesses can interoperate. Or your
company could get bought by someone who wants to run everything on an IBM
mainframe.
5. Maybe your company will decide to resell the technology that you've
developed. In the case that your objects are system specific, that is
going to severely limit your potential market.
Portability is part of the ability to change and adapt quickly.
Until everyone realizes that Linux is the one true way, portability is
still necessary. ;-)
Quoting Xiaopong Tran <[EMAIL PROTECTED]>:
> Thanks for the reply.
>
> > Xiaopong Tran wrote:
> > > The EJB specs said that EJBs are not allowed
> > > to access the file system for security issues.
> >
> > Correct. This is an optional feature in jBoss though.
> >
> > (Note: and it is actually spec compliant to not enforce this at all..)
> >
>
> So, whether a container enforces this or not, it's still
> spec compliant?
>
> > > Can someone clarify what security issues are
> > > involved here? It sounds strange to me here
> > > that accessing the file system from an EJB
> > > would cause any security problem, as EJBs
> > > are designed to be run on a the server in
> > > the back end, in a "well-controlled" environment.
> > > It's not like the applet situation where you
> > > don't know what you get.
> >
> > It has less to do with security than portability. If you do file
access
> > you are potentially making your beans less portable. If you have to
> > access files through some resource manager, this ensures that your
beans
> > are always portable to another server.
> >
> > See, the spec has as its primary goal "If it's an EJB, it IS
portable",
> > and these restrictions are a way of enforcing this. No "well, maybe,
> > unless you've done this or that, ..or..". None of that. With EJB, they
> > *ARE* portable, period.
> >
> > Does this answer your query?
> >
>
> Well, portability is a design issue, more or less related
> to the programmer's skill. But security is something else.
>
> If I don't hard-code my system-dependent stuffs (e.g. directory),
> and put it as a variable during the deployment, that's my
> problem and I should not be forbidden from accessing
> that directory. The container should not throw an exception
> on me, right?
>
> Besides, if I develop the beans for my own company's usage
> only, and I know perfectly that they will only be deployed
> on a specific platform only (e.g. Unix, no NT in my server room!),
> I can hardcode whatever I want (not to mean this is desirable),
> that is my decision made consciously.
>
> Anyways, that looks more like a burden that anything
> else.
>
> Thanks for the quick reply.
>
> Xiaopong
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
--
Bill Chatfield - [EMAIL PROTECTED]
Vice President of Technology
NetCommunity - http://www.netcommunity.com
Try the Flash Pilot demo - http://www.flashpilot.com
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
