Byron Estes

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

Recent posts by Byron Estes

I just finished a project with Sun One Portal Server and I agree with everything that was said previously.

Specific to Sun One Portal Server...

Be sure to run the performance tuning scripts they provide and make sure you use the mode that actually makes the changes or be prepared to do them manually.

Consider how many times a particular portet is called. We wrote some pretty generic portlets (JSR-168) to minimize the number of deployed applications. Example: We needed a link list portlet that provided more functionality than the one sun provides (...better user interaction for mainting the list). We created one portlet that used the preferences during channel configuration to establish the listname, who could edit it, etc. A portlet ultimately becomes a servlet. All the channels configured up use that servlet to render the content and respond to actions. We had some 50 channels each with a different list. I had already set up caching both at the data access layer (singleton custom cache)and at the portal presentation layer on the channel itslef (refresh property). This handled most everything but under extreme load (using 6 remote test machines running JMeter) we started throwing some exceptions related to concurrency. I don't recall the specific exception. What we did was to solve that was to deploy more that one instance of the portlet which in turn created more instances. We then altered the channels to spread them across the portlet app instances (especially where more than one instance of a list was on the same "page").

Lastly, make sure you performance test. JMeter does a pretty good job.

Good Luck!
18 years ago
Channels are created in the Sun One Portal based upon one of two methods:
1) One of Sun Proprietary Providers which generate the content or
2) Portlets developed based upon the JSR-168 Specifiction
The site referenced by the last post takes you to a portlet share area. If you browse it, they break out the portlet by category. Select calaboration. Under callaboration there is a JBoss Wiki portlet, although it says JBoss, it also indicates that it is JSR-168 compliant. If that is true you can deploy the portlet application war file into your Sun Portal Server using the pdeploy command. Once deployed you should be able to go into your access manager for the site (Desktop configuation) and create a channel based upon your newly deployed JSR-168 portlet.
18 years ago
From everything I've read they don't get garbage collected, but the do a heck of a job optimizing the "pool".

I did my best to try and "fill up the pool" from simple string concatenation in an infinite loop to random character generation and assembly into Strings. I then tried to watch a performance monitor to see if the memory usage climbed. The CPU would spike but after a very "small" initial memory consumption (...may not even be related to the string pool")it leveled off and remained steady even though it was still "looping". So in the backgroud it is either cleaning up after itself or doing some form of optimization with substrings.
[ May 26, 2005: Message edited by: Byron Estes ]
19 years ago
You also may want to check out Joshua Bloch's "Effective Java"..

Specifically "Item 13: Favor immutability" in Chapter 3 (page 63 in first edition ...not sure if there have been new editions since)
I don't think the person who started this thread was asking about the mechanics involved in making a class immutable. I think, IMHO, that they were asking why was it DESIGNED to be immutable. What was the reasoning or thought process that Sun (James Gosling, et al.) went through that led them to make the String class immutable.

If that is in fact the question, here's a pretty good, no nonsense explanation: Link to article: Reasons Behind Immutability
I don't think you can ever assume anything. The context of the question is critical. My experience was that the questions were fairly tricky. Careful reading and analysis of each was needed. You really need to know the topics inside and out to extract the most out of the question and avoid second guessing yourself. It was definitely one of the most challenging multiple choice exams I ever took.
You could put the result in a hash table where the path signature/pattern is the key and the value is the number of times the path signature/pattern occured in the tree. This could be put into an class where you override the
the equals method to allow/encapsulate the comparison.

...or if you want to make it really fast you could build a master path pattern for the entire tree by sorting the path signatures by their occurence (primary) and then by their signature pattern itself (secondary). If you then built a string out of them in this order, you have what I think would be a decent key that you could then store in a database with your flows, images etc. Then you could evaluate a situation, build it's key and then use the power of the database to find various alternatives.
19 years ago
I think your getting hung up on their nomenclature. When they refer to an enterprise bean they are not referring to one of the various files involved in defining an enterprise java bean (i.e. the remoter interface, the home interface or the bean implementation clase), they are instead refering to it as a conceptual/complete component. They are asking, "What interface does your EJB (...comprised of all the things I mentioned) need to implement so that an application can invoke it's methods".

The answer is EJBObject.

You are equating enterprise bean with the Bean Implementation Class.
When you declare a non-primative variable (i.e. object), it's capable of pointing to an instance of the object type declared.

Until you instantiate an instance of the object using the "new" keyword and assign it to the variable, the variable is null.

In the case of an array, you declare it and you instantiate it. So far so good. The variable points to an instance of the array type you declared.

The DIFFERENCE here is that an ARRAY IS A COLLECTION OF VARIABLES, you simply access them via an index (i.e. objects[1]). When the array is instantiated it doesn't fill all the variables/buckets it contains. It simply provides you with variables capable of receiving/holding pointers to the instances.

Whenever you are using an array of objects you usually go through a 3 step process where you declare it, instantiate it and you fill it with instances of the type it was declared to hold.
[ May 18, 2005: Message edited by: Byron Estes ]
You're basically correct on everything but you left out that the methods you want to expose for REMOTE access by a calling application/component must be promoted to your remote interface skelleton (...which itself EXTENDS the EJBObject interface). Your entity bean must then IMPLEMENT the remote interface you defined in addtion to allowing for the standard methods that comprise the EJBObject interface. Without the EJBObject interface your entity bean is no more distributable or remotable (...don't think that's a word) than a standard POJO. It is the EJBObject interface that allows you to establishes the contract for remote control with the calling application through the container.
I had a 100% on Part I.

I agree with the previous posts, that this is NOT about coding EJB, but I found understanding some of the details help me to better understand the big picture and their application in ways that I could not have if I didn't dig deep.

I used the Mastering EJB book by Ed Roman ( it twice). I read the O'Reilly EJB book (...don't recall the name), one time and I read the Sun Java EJB Specification twice after I read the books (...made more sense then. :-))

I felt I benefited from reading overlapping material because each author had a different approach and having it explained in different ways was helpful and each reinforced the other.
Not exactly...

The issue is this.

Program #1 declares the variable, but doesn't associate an instance with it. The compiler edits are designed to catch this. This variable has local method scope.

Program #2 declares the variable and instantiates the object array to a size of 5. While the array variable refers to a valid instance of the array. The contents of the array which should refer to instances of the objects of the type declared, were never created/initialized. An array is simply a collection of references the references may or may not refer to a valid instance on the object of the collection type. As a result, if it's possible that you will get unitialized instances in your array/collection it's usually a good idea to check that the item is not null before you make any method calls on it.
[ May 18, 2005: Message edited by: Byron Estes ]
My experience was that I found out my score at the Prometric site when I left the testing room. They gave me something indicating my score. As I recall, I couldn't download the assignment immeadiately because Sun did not yet have record of my passing Part I. After Prometric transmitted that information and it got into Sun's site a few days later, I was able to download the assignment.

It's been a couple of years, but that's what I recall.
I hate to dash your hopes, but if the questions are anything like the ones I had they were a bit tricky. I'm not sure if they were ambiguous, but the way they are worded made me feel that they were trying to mislead you at times. Unless you are extremely confident with the material they are very challenging.