David Yutzy

Using JSR-168, you'll have to construct the URL so that it links back to the processAction method() of the portlet, passinng the link action you want to take.

Then, from there, you cn redirect to the .jsp of your choice.

We're using Sun Portal v7, but I didn't see that in the configuration. We can setup based on Org who gets what tabs, content, portlets, etc. but I didn't see anything in there about managing the various options...

Trying to figure out if it's possible to have roles to determine if the maximize, minimize, edit, view, config, etc. states are able to be setup for only certain roles.

EXAMPLE:

Config (user.isinrolle = Admin)
Edit (user.isinrolle = Manager)

What I found out was that if the user has not logged in, the "state" or "persistence" is not maintained and is causing this error.

Apparently, when you have the user as "authlessanonymous", no session is kept and thus cannot be persisted from screen to screen and neither are the objects (I was getting null values during state changes and look-ups).

Deploy this portlet to a user who is logged in and everythign worked as expected.

Maybe I'm not understanding the concept, but when setting the WindowState to MAXIMIZED, isn't the portlet supposed to take up all of the container space?

Well, mine doesn't. I don't get an error, but the portlet doesn't seem to be able to switch states, although in Pluto is works just fine, in P7 it doesn't.

All of the code works, but when I have the portlet as either "thin" or "thick" or any other width value, it just stays the same size.

Any ideas?

NOTE: What I'm trying to accomplish is this: When the user fills out a search form, the portlet switches to MAXIMIZED to display the results so I cann display more columns than what would normally be shown in the narrow or thin state.

What I found out was that if you have a portlet that changes window state or needs to pass information from any method (in any scope: Application or Portlet) to a JSP file, state is not persisted in "authlessanonymous" mode, meaning, nobody is logged in.

Once the user logs in, the portlet works as coded.

This is kind of strange since Pluto doesn't ask you to login and the portlet works, so it must maintain session and implement a default login.

Ok...

Creating a JSR168 portlet and it works fine in Pluto, but I get the following when I deploy to P7:

ERROR: Content not available. REASONE: Invalid request for a change in window state

Here is what the portlet is supposed to do:

* Display a form
* User clicks find
* Lookup is performed
* Window state in processAction() method of portlet is changed to MAXIMIZED
* I'm guessing this is where the error is occuring

I also think that for the TableContainer, I have some sort of attribute incorrect having to do with one of the *channelsIs* values.

I tried toggling them one way or another without any effect.

I then took out all the window state code from the portlet and now when I submit the form, the lookup succeeds, but the value I set in the processAction into Session isn't found when the portlet is rendered.

Again, this all works perfectly fine in Pluto, so it has to be some sort of Sun Portal specific "something" that I'm missing.

Anyone have any experience in writing JSR 168 portlets for Sun Portal?

I was trying to get around swapping files from local to staging to production if at all possible, whether it be xml or .properties because of the I/O involved. This is a massively active site and the I/O would kill it. Same for the DB, a lot of repetitive calls just to get settings...

Can anyone point me to a site/reference that shows how to use annotations for conditional compiles?

Scenario:

Let's say I have a bunch of code that only runs locally on my laptop, but when I'm ready for deployment, I'd like to compile the code with a different set of values to work on Solaris, what's thebest way to do this?

I was thinking annotations, but if anyone has any further suggestions, I'm all ears.

Very useful, but to get what I need, I have to somehow parse the "low" and "high" bits of the 64-bit number returned into 2x32 bit numbers.

Any idea how to do this?

Ok...

I'm writing some code that reads attributes from Active Directory and the attribute value returned is thus:

this.pwdLastSet = 127560719042795072

public synchronized String getPwdLastSet() { String retVal = null; Date date = new Date(); long dt = Long.parseLong(this.pwdLastSet); date.setTime(dt); retVal = date.toLocaleString(); return retVal;

What I get back is some jacked up date. Try substituting date.getTime() instead of this.pwdLastSet and it still comes back all crazy.
[ March 23, 2005: Message edited by: David Yutzy ]

Anyone know of additional javadoc stylesheets? I remember seeing a tool that generaated javadoc as a different set of HTML tiles / stylesheets.

Yes, we have this indexed on jSessionID.

We typically encounter "blocking" issues with SQL Server anyway every once in a great while, but more so when using PS because of the huge CPU spike, which seems to cause everything else to run slower which seems to cause blocking scenarios, etc...

Using SP there is no real perceptable CPU activity at all with the same code.

When running SQL Profiler and tracing the activity, you can see from my previous post that it's creating temp procedures with every call and we've been able to watch the CPU spike on our staging server which we can isolate to a single user and it spikes to 100% every time I do a PS.

The tables have about 6.5 million records and the SQL is like:

SELECT * FROM myTable WHERE lName = 'last' and fName like 'first%' and zipCode like '4%'

It returns about 10 fields.

Using a SP is instant and no CPU, PS is 100% CPU spike.

We've had bitter experience with MS's JDBC Driver and it's aweful. On high traffic sites, it brings the application server to it's knees pretty quick.

We're using JTDS and haven't looked back.

It sounds like you are not properly closing your connections, statements, or something like that.

We're using SQL Server 2000 and process over 100 million DB operations a month with no issues.

One word of caution, eventhough many people say you do not have to close Statements, PreparedStatements, or CallabelStatements before closing Connections: do it. It does matter. Don't leave it up to the driver to handle this. We've found vast differences in how drivers handle this, especially the MS Type 3 Driver, which is aweful BTW.
[ November 04, 2004: Message edited by: David Yutzy ]