My understanding of programming restrictions is that reading or writing to a file is not portable across EJB2 compliant servers. This makes it very difficult to use XML configuation files either of your own for complex business logic (where env-entries are not suffuciently complex) or for the use of something like jakarta commons-validator framework where you would have to write
InputStream in = getClass().getResourceAsStream("validator.xml");
to get the validation rules.
Is this programming restriction definitive and does anyone have any thoughts on it.
posted 15 years ago
Further to what I wrote above, I have just looked at the spec 24.1.2 on programming restrictions. It says:
"An enterprise bean must not use java.io package to attempt to access files and directories in the file system"
The reason it gives is that "the file system APIs are not well suited for business components to access data. Business components should use a resource manager API such as JDBC to store data."
Does this mean that it is ok to read any XML files such as the one mentioned bundled in the ear archive in the container? After all the container reads the ejb-jar.xml file.
The use of I/O within the business logic of the Enterprise Java Bean
is not advisable
Say for example if you want to form a jar file on the fly and publish the information to a file and store it in a file system...then it is better to go for Servlets.
But in certain cases...were you are developing components for a major system, where it is deployed in multiple location.Definetly we have to maintain...different configuration...like Report Server, Security Certs... and many other things.In that case we can use a separate XML and use parser to parse the information.
SCJP SCWCD SCBCD <br /> <br />what u do in life echos in eternity!
If you are using a wood chipper, you are doing it wrong. Even on this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!