Garrett Reinard

Greenhorn
+ Follow
since Dec 10, 2004
Merit badge: grant badges
For More
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 Garrett Reinard

Just as an update, in case you guys encounter this or find someone encountering this in the future...

The solution to the problem was in the application.xml file... (not the orion-application.xml file)

when defining the web modules in the app, I had left out the "<context-root>" element as a child of the "<web" element... I just had a "<web-uri>" element by itself... with the standalone deployment, the context root, etc, was specified in the call to the admin.jar... when using the enterprise manager console with OAS, it actually parses that file and expects that you have defined "<context-root>" as a sub element for each of your web modules... My thoughts are that the only reason they are doing this is to prepopulate the binding textfields, which seems kind of annoying, but none-the-less, that is the fix for my particular problem...


Something to note also, is that all the log files were pretty useless for this problem... I searched through them all on numerous occassions after attempting new deployments... nothing showed up... the only way I figured it out was by deploying a couple other apps we had... one worked, and after digging through it all for a while, I figured out that the only difference in the descriptors was that "<context-root>" element... changed that and bingo...


Thanks all for the help...

-Garrett
19 years ago
Thanks for the clarification...

-Garrett
19 years ago

Originally posted by Jeanne Boyarsky:
Garrett,
I know this problem is mysterious to you too, but you are really unlikely to get an answer without some more specifics.

Some things I can think of that might help expand on the problem:
1) Have you ever sucessfully deployed to the OAS instance?
2) Are there messages in any logs?
3) What is in the ear file? (entity beans, session beans, servlets, ...) Have you ever sucessfully deployed each of those elements before?



Our sys admin has configured the OAS, and at this point, I believe he may have a deployment or so out on it... My application has never been deployed on the OAS server... It is quite possible that there are OAS config problems... That's what we are trying to figure out... I have three different Ears actually, but we are trying to deploy only one of them for now just to make sure it is working... the one we are trying to deploy right now consists of only session beans and maybe a web app or two...

They have all be successfully deployed and tested on standalone OC4J...

Originally posted by Avi Abrami:
Garrett,
Oracle <unstated version> Application Server is very different to OC4J <unstated version> stand-alone. What makes you think that EAR creation and deployment is identical on both of them? Maybe you should install "OAS" (as you call it) on your machine and test using that? (It is free for development purposes.)

Good Luck,
Avi.



Well, if there are differences what are they? To my knowledge, OAS actually uses an OC4J container under the hood. That is why I believe they are compatible... We are using the method suggested by oracle... develop on standalone, deploy to OAS... They both use identical configuration files and archive build structures...

Just out of curiosity, do you even know what OAS is or have you worked with orion web deployments? Your comments lead me to believe that you aren't familiar with the software I am talking about. "OAS" is Oracle Application Server... That's not what I call it, that is what it is called...

I appreciate the fact that you are trying to help, but if you are not familiar with the software I am asking about, your comments are not really relevant or necessary...


Thanks
-Garrett
19 years ago
Hello all...

I'm having a problem... I have an application that when built into an ear file can be successfully deployed to OC4J standalone... The app works too...

However, if I give the sys admin my ear file and he uses the admin console for the real OAS instance... while trying to deploy, an error comes back and just says "NullPointerException" with no other information at all...

has anyone encountered this before...

BTW, my standalone instance is on a Win2k machine, the OAS is on Linux, not sure if that matters but thought I'd mention it...

Thanks,
Garrett
19 years ago
Thanks for the input...

I will read up on the PhaseListener you mentioned...

If at all possible we would like to avoid going into the JSF framework to add code... also, there are concerns that this type of "hit counter" filtering might cause unforseen issues down the road...

thanks,
-Garrett
19 years ago
JSF
Hi all, I need some help/input...

We are working on our first real JSF app and we have been doing pretty well so far, until we started encountering this one problem.

We have a first page, call it "Page1" which has 2 input text fields and a submit button. This page is backed by a managed-bean, call it "Page1FormBean". Now, when the submit call is made, an action listener method in a separate session scoped managed-bean (the view controller), is called which prints out a logger statement, and then continues to populate some other fields in that Page1FormBean with data from the database which corresponds with the user input from Page1.

A navigation rule for "success" is set up to get to "Page2". Once on Page2, the data is retrieved from the Page1FormBean and is displayed to the user. The data is in the form of a collection, and each row is displayed as a h:commandLink. At this point, I am COMPLETELY done using the Page1FormBean. The commandlinks have hard coded actions which are setup in the faces-config file, and they each call to another action listener method in the view controller. When any of the links on Page2 are clicked, the method in the view controller prints a logger message and then populates a managed bean, call it "Page3DisplayBean", with the data from the selection made by the user, which will be used on the next page, "Page3".

Here is the tricky part...

When Page1FormBean is in session scope (in the faces-config.xml file), all of this works perfectly fine. The end result is that we are on Page3 displaying the correct data from the Page3DisplayBean.

However, when Page1FormBean is in request scope, and one of the links on Page2 is clicked, the page simply refreshes and all data elements of the page are blank. The actionListener method which normally prints logger statement is NOT called at all...


Now, I understand why when this page refreshes all of the data is gone, that is simple... The scope of the managed bean limits its life so when the page is refreshed/reloaded a new null one is created and the data is gone... however, this doesn't explain why we are not navigated to Page3. Instead, we are indefinately stuck on Page2.

The problem, as far as we can tell from experimenting and researching the web, is that request scoping should not be used from the JSP level because of the postback nature of JSF... Since the JSF Framework refreshes the view underneath the hood both when the page is loaded, and when it tries to leave, the request scoped bean will be there for the initial load, but not for the post back view refresh...

The solution we have seen up to this point is just to "make everything session scoped". This approach works, and the pages work correctly, but it leaves the door open for old data to remain in memory. This means we have to write bits of rather messy code to make sure that all beans we no longer need are cleaned out or reset.

Finally the Question

Since the problem seems to be that the request scope's lifecycle is barely short of the length needed for this, a scope of 1.5 requests or 2 requests would seem like a logical way to keep the data around long enough to use it, yet still get rid of it in a timely fashion after use.

One possible suggestion was that the beans could be scoped "session" as far as JSF is concerned, but that we could write some code to manage our own sense of a scope... For example, a superclass to all of our beans might have optional constructors which accept an int parameter specifying how many requests that bean should live. Default behavior would remain the same. Then a servlet filter could be used to clean out and remove the beans which have lived through as many requests as they were supposed to...

The missing link is the code needed to increment this internal request cycle counter... I need to find a way to increment this counter... Perhaps there is a given call made on every object in session during each request cycle, or maybe there is a piece of the framework code that could be changed to increment that counter manually during the refresh view cycle, etc...

The other possible solutions are to have something on each of the JSP pages, or at the very least on the main menu page for the application that calls resets on each of these beans... If this is the only way possible, it would be interesting to find out if the JSF framework supports any type of "resetter" components instead of calling value binding methods with hidden components...

Has anyone dealt with anything like this, and could point me in the right direction, or has anyone come up with a solution to this request + 1 scoping problem?

Thanks in advance...

-Garrett

P.S. Sorry for the length...
[ March 14, 2005: Message edited by: Garrett Reinard ]
19 years ago
JSF
The biggest advantage I have seen from using webstart is the ability to get out of the security sandbox which exists with web apps and applets...

With webstart you can create full blown desktop applications and serve them to people over the web... Those applications can read/write files, create socket connections, and just about anything else a local desktop app can do...

Also, they can set up a shortcut on their desktop so that the webstart app can be run like a program file from their PC... Upon startup, webstart will check to see if you have updated the application on the server, and if so, it'll automatically download the update and let them run the newest version of the app automatically...

Also, web start can be set up to allow for auto installation if someone doesn't already have a JRE installed...

I'm sure there are some more quite technical reason why it is nice, but that's just a little input from my experience with it...

-Garrett
19 years ago
The JRE is used to run java apps... I don't believe the JRE has the javac.exe or other development/compilation executables... It contains exclusively the runtime libraries...

The JDK on the other hand is used for development, and thus contains the development/compilation executables, as well as the runtime executables...

Basically the JRE is a trimmed down version of the JDK for people who need not develop java code but must run java applications...

-Garrett
19 years ago
Hello all,

I am tasked with porting code from using weblogic server to using oracle application server... I'm currently running a standalone OC4J instance for testing, etc...

My question is this... Weblogic used weblogic.ejbc in order to expand a jar file filled with ejbs, build and compile the container classes for those ejbs, and repackage it into an ejb jar locally before deployment... Does OC4J have a similar pre-deployment compilation class or does all the container class construction occur during deployment?

Thanks,
Garrett
[ December 16, 2004: Message edited by: Garrett Reinard ]
19 years ago
I'm working on porting an existing app from using weblogic server to using oc4j on an oracle app server. I finally got JDeveloper to recognize all of the beans (by entering each manually and then overwriting them) because the src setup was different than what JDeveloper called for I guess...

Anyways, I'm having a problem when building. I finally got all of the library issues and compilation errors out of the way, but the problem is with JSP's...

The src for the project contains 4 JSP files. During compilation, I get the following error message for each JSP: "JSP files must reside in the server root directory or a subdirectory beneath it"

Now, I need to keep the JSP's in the distribution because they are crutial, but how can I get the JDeveloper compiler to just ignore the 4 JSP files during build, yet still copy them to output so they can be deployed to an ear file with the built code?

Thanks in advance...

-Garrett