Paul Prusko

Greenhorn
+ Follow
since Feb 16, 2008
Merit badge: grant badges
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Paul Prusko

The specification clearly says that:

An enterprise bean must not use the java.io package to attempt to access files and directories
in the file system.



There is no mention about its internal directory structure to use as a trusted location or work around but rather a suggestion to use resource manager like JDBC. You are right that the deployment should not rely on local machine resources and storing a file in server's root directory solves only a part of the problem because you still have to deal with writing a stream to a destination which is not transactional - unless you use a resource adapter.

Writing logs to database doesn't make sence. How the support people look into the logs when somthing happened in system? Do they need to fetch from database?


Indeed I think it can make sense because you can easily query the database and filter only those entries that you might be interested in. You can also sort them or put in the order you wish to extract logs of given invoker. Moreover it is a step towards making a dump of the logs to a file system by the rdbms on a daily basis so that you have an archive. This gives you an alternative but at the same time does not violate the specification. What do you think?

Cheers,
Paul.
Thanks again,
Indeed, using MDB is my intention. Regarding storage approach writing to file from EJB component is my major concern because as we know it, J2EE specification restricts any IO operation from within EJB. Even though J2EE container providers usually do not prevent you from realizing this approach and in most cases it will work I would not like to break this restrictions and pose problems with distributability of components. Does this mean that the only thing I'm left with is writing logs to the database? There are some other solutions like using resource adapters for writing to the local file system or JDBC driver for writing to flat file but do they come at a reasonable expense?

Regards,
Paul.
Thanks for your reply, Prabhakar.
It's nice article which can be useful at configuration stage.
However, I'm not facing configuration or class-loading issues at the moment but looking for design approaches to realize logging mechanism. Indeed, log4j is what I consider to make use of but first I need to be sure that my solution is compliant with J2EE specification in terms of persisting to file or DB and that it performs well as a JMS messaging scheme.

Could anyone point out some suggestions, considerations?
Thanks,
Paul.
Hi Ranchers,

I've been searching through the posts to find some answers/ways to go with logging
approches in EJB components and in general throughout J2EE environment. As the specification
denies writing directly to files from EJB components I'm close to base the solution on JMS messaging. However
I still wonder if this is a good and reasonable approach for large projects. First of all:
1. would the performance significantly degrade in face of the load with JMS messages and the need to process them?
2. if I collect the messages from the queue inside message driven bean (MDB) based message listener what choice do
I have to persist the log messages? I can think of writing to the database, sending emails, anything else?
3. is there any safe way to do it with MSB to finally end up with log files? The point is I need to do it all inside the
J2EE application server.

I'd appreciate your thoughts and a helping hand.
Cheers,
Paul.
The toString() method called in

is invoked on obj reference which is of type AB but refers to actual object instance of type BA which is a subtype of the former. As the subtype has got the toString method overriden in the BA subclass this is what gets called at runtime. That's why you can see the output Good Bye which greeting instance variable of BA is initialized to and is not changed ever after.

Regards,
Paul.

Raju Champaklal wrote:oh yes...i got that error...i was actually expecting to get Exceptionininitializererror...when this exception thrown?



ExceptionInInitializerError is thrown when something goes wrong within static initialization block while your exception was thrown in instance initializer. You can obtain it by simply reimplementing your class as follows:



Regards,
Paul.

Raju Champaklal wrote:int a[][]=new int[5][];


As far as the code is concerned it does throw an ArrayIndexOutOfBoundsException but as you placed it inside the initializer the exception is thrown when an object of this class is created/instantiated. Try writing new A() in main() method to check it out.

Going back to your first question:

Raju Champaklal wrote:
int a[][]=new int[5][];

does this mean that
a[0]=null;
a[1]=null; and so on till a[4] ? i think this is why i get null pointer exception when i try to sue a[0][0];



This is an array of arrays so the cells you refer to by the first dimension are actually references to the second array so they indeed are initialized to contain null values. This also implies that you cannot refer to a[0][0] since there isn't anything initialized there which results in NullPointerException.

Regards,
Paul.

Erez Pitchon wrote:Hi

Why does the first line not compile while the second does?

Long L1 = 23;
Short S1 = 23;



Hi,
I think that the second line compiles because the compiler implicitely reconizes that 23 fits into short and then boxes it to Short. In case of the first line things get a bit tricky nonetheless one should remember that you can only box and then widen not the other way around so this time the compiler can only try to box the int type to Integer and then try to widen to Long. The last operation failes since Long and Integer hold the same level in the type hierarchy, I mean they are not in the same inheritance tree path (neither of them extends the other).

Regards,
skyeweaver
Hi,

you can think of cases where down-casting does not cause any runtime exceptions like the one below:
( suppose class Dog extends Animal )

so this is not a rule that down-casting ends up with a runtime problem.
Regards,
Paul.
You get a compiler error when trying to assign a value to a static final variable in an instance initializer block and not for instance variables because static variables live in the number of only one and are so called class variables shared by all instances of the same class. Now, since the initializer block gets executed every time an object is created the variable would be initialized as many times as the constructor and init.blocks will. That is - I think - why the compiler complains about this line. Static final variables can be initialized only once.

Regards,
Paul.
Hi,

I can see it that way:
Exceptions thrown by JVM are those which are its response to events taking place under JVM's control - like ArrayIndexOutOfBoundsException is thrown because the JVM has detected an attempt to access an element which it by no means can reach for. On the other hand, my view about exceptions thrown programatically is such that programmers take into account some rules about their methods' arguments which must be abode by because only then the method's logic will work correctly and that's the way in which callers are informed and given a possibility to extract and handle improper use of some situations - like IllegalArgumentException or NumberFormatException.

Regards,
Paul
Maybe I didn't get the point, Jack.
Anyway, Pawni Jain is right. In addition I can add that when declaring a variable like byte b = 3 (or - in case of byte type - with any other value <= 127) the compiler is smart enough to notice that this number will fit into 8-bit byte so it narrows this - otherwise int literal - implicitely to byte.

Regards.
Paul.
Hi,

The compiler does narrow the byte b = 3; as it is doing in line 1. However the last line of your code appears to be the real problem here because you are trying to add to bytes which will result in an int so you cannot assign it to byte type variable. Looking at your code, it seems you might get a compile error in line 2 because you define variable b which has already been defined in line 1.

Regards
Paul.
You see, the compiler is not narrowing long primitive to float. As I wrote in my previous post a long can fit in the float parameter type and this is what the compiler is doing - it matches long type parameter to tha method definition which takes the smallest type but wider than long, in case the exact type is not found - which is what you have in your code. This is all about grasping the idea of how numbers are represented and which one can fit into another. Please, have a look at the article which I suggested you before.

Paul.
Hi,
even though it may seem that conversion from long(64bits) to float(32bits) is a narrowing conversion, it truly isn't. The point is floats are represented using scientific notation which handles larger range of values. To get a good explanation, please, refer to the following article courtesy of Corey:
http://radio.javaranch.com/corey/2004/06/01/1086120368000.html

Regards,
Paul.
[ May 19, 2008: Message edited by: Paul Prusko ]