RE: [iPlanet-JATO] EJB in iMT

Matt,
Thanks for your clarifications.That helps a lot.
We have found in a lot of cases, that your new components can be
implemented as JATO ModelsI don't understand this.Is it that EJB acts as the Data Model or something
Thanks,
Gajendran.
"Matthew Stevens"
Subject: RE: [iPlanet-JATO]
EJB in iMT
10/30/01 07:34 PM
Please respond to
iPlanet-JATO
Gajendran,
The iMT for NetDynamics does not current have any translation requirement
for EJBs. If you have a ND 3.x or ND 4.x application then you have no
pre-existing EJBs. ND 5.0 provided an EJB 1.0 container for Session Beans
but the Migration leaves the EJBs untouched. The migration path for ND 5.0
EJBs to J2EE EJBs is clear - it simply requires a recompiling and packaging
and tweaking. I have done this at some customer sites and it is very
straight forward. In many cases, you may find that your choice of an EJB
implementation does not truely take advantage of the features of the EJB
container and you EJBs are simply business objects (stateless and
stateful).
We have found that migrating stateless and stateful ND 5.0 EJBs to JATO
Models is very simple and greatly improves the performance in many cases.
Now that your ND application is migated to J2EE/JATO you can easily add
EJBs
to the application; JATO does not prevent this in any way. Some customers
are even adapting existing or 3rd party EJBs to JATO Models interfaces, but
this is not necessary. Your EJBs will be packaged separately in JAR file
and combined with JATO Application WAR file in an EAR file. We recommend
using a good tool like Forte to generate your EJBs. I personally suggest
that you carefully plan and analyze your requirements before moving forward
with the EJBs. Please make sure that you your new components 'need' the
features of the EJB container/framework. If you need an Entity bean then
use it. We have found in a lot of cases, that your new components can be
implemented as JATO Models. It all depends on the dynamics of the
application and constitution of your data.
matt
-----Original Message-----
From: gajendran.gopinathan@i...
[mailto:<a href="/group/SunONE-JATO/post?protectID=123166177056078154218098066036192063041102166009043241114211116056004136218164200193244096076095219">gajendran.gopinathan@i...</a>]
Sent: Tuesday, October 30, 2001 6:40 AM
Subject: [iPlanet-JATO] EJB in iMT
We have migrated an application in ND3.0 to J2EE using iMT 1.1.1.
Is there any provision in iMT which could generate EJBs?
What is the recommended approach towards this?
Thanks,
Gajendran
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
------------------------Disclaimer------------------------
The views of the author may not necessarily reflect those
of the Company. All liability is excluded to the extent
permitted by law for any claims arising as a result of the
use of this medium to transmit information by or to
IT Solutions (India) Pvt. Ltd.
We have taken precautions to minimize the risk of
transmitting software viruses, but we advise you to
carry out your own virus checks on any attachment to
this message. We cannot accept liability for any loss or
damage caused by software viruses.
------------------------Disclaimer------------------------

Similar Messages

Re: [iPlanet-JATO] More on ComputedColumn issue

Vladimir--
I'm going to answer this question without doing my full homework on it;
please let me know if I hit the mark or not. If I understand correctly, you
have a problem using a model for both UPDATE and SELECT queries because of a
computed column...correct?
If so, this issue is solved in JATO 1.2. 1.2 has an attribute in the field
descriptor to indicate in which type of queries a field should be used. You
can use this attribute to indicate that a field should only be used for
UPDATE queries, SELECT queries, or whatever combination of query types you
require. You can then define synthetic fields for use only during one of
the query types.
Does this sound useful in fixing your issue? A way around this in JATO 1.1
would be to create separate models for SELECT and UPDATE queries. The
SELECT model could contain all the fields for the joined query, but the
UPDATE model would contain info for only one table. The 1.2 feature simple
allows you to do the same using one model.
Todd
----- Original Message -----
From: "vivanov4114" <vivanov@b...>
Sent: Friday, January 11, 2002 8:12 AM
Subject: [iPlanet-JATO] More on ComputedColumn issue
We have a similar problem with do's ComputedColumn after the
translation as Kostas described in his detailed message #439.
We have JATO/iMT version 1.1. Is the resolution of this problem added
to the version 1.2 (or 1.2.1)?
I've tried to adjust the ModelImpl class based on the .sdo file
(using ComputedColumn attributes) for these fields and failed.
Whether I missed something else, or our situation is a little bit
different.
In our case the dataObject has one Computed Field from one table and
another Computed Field from another table along with joint between
these two tables and third one, and, finally, the whole stuff is
under the repeatable (with static fields bindings to these two
computed fields).
The modelImpl class after the translation (as in the #439) has the
same values "" and "." for ..._NAME and QUALIFIED_..._NAME strings
respectively (for each computed do's field).
I guess that we could meet extra problem with this (for manual
adjustment) because of there is no TableName attribute in .sdo file
for computed field (as well as there is no ColumnName attribute for
computed field). If ComputedColumn attribute (computed field) could
play a role of ColumnName attribute (regular case), what would be an
analog of TableName attribute for computed field?
The bottom line of this is as follows: we have a same
SQLException "Invalid Column Name"
from ResultSetModelBase.updateModel() as Kostas described. It causes
the problem for
RequestHandlingTiledViewBase.executeAutoRetrieving() method that
can't bind the proper Model.
Finally, beginDisplay() method from
pgXXXXPriorityCountTiledView.class throws exception and
jasper compiler brings run-time error (Tomcat 3.2).
Kostas, if this problem still exists for translation of such cases,
could you please post a fragment that fixed you original problem in
addition to the message #439 (just to be sure, that I haven't missed
something important).
Thank you very much in advance.
Vladimir Ivanov,
P. S. I've enclosed the excerption from the .sdo file for this
dataObject below.
Class "SQLObject" ;
Name "doPriorityCount" ;
DataFields {
0 { // first df is a computed column from the first
//table
Class "DataField" ;
Name "dfPriorityDesc" ;
ComputedColumn "MIN
(MOS.PRIORITY.PDESCRIPTION)" ;
1 { // second df is a computed column from the second
// table
Class "DataField" ;
Name "dfPriorityCount" ;
ComputedColumn "COUNT
(ASSIGNEDTASKSWORKQUEUE.PRIORITYID)" ;
2 { // third df is a regular df
Class "DataField" ;
Name "MOS_PRIORITY_PRIORITYID" ;
TableName "MOS.PRIORITY" ; // this attribute
// doesn't exist for ComputedColumn
ColumnName "PRIORITYID" ; // this attribute
// doesn't exist for ComputedColumn
DataCachingEnabled "False" ;
DataCachingDuration "0" ;
DataCachingMaxRows "200" ;
DataObjectType "Select" ;
Tables "MOS.ASSIGNEDTASKSWORKQUEUE,MOS.PRIORITY,MOS.DEAL" ;
SQLDistinct "False" ;
SelectFilter {
"MOS.DEAL.SCENARIORECOMMENDED" ;
"=" ;
"'Y'" ;
"AND" ;
"MOS.DEAL.COPYTYPE" ;
"<>" ;
"'T'" ;
SelectOrder {
"MOS.PRIORITY.PRIORITYID ASC" ;
SelectGroup {
"MOS.PRIORITY.PRIORITYID" ;
EnableEntireTableDelete "False" ;
EnableEntireTableUpdate "False" ;
SQLTextOverrideSelect "Partial" ;
SQLTextOverrideDelete "None" ;
SQLTextSelectJoin "MOS.ASSIGNEDTASKSWORKQUEUE.DEALID =
MOS.DEAL.DEALID
AND MOS.PRIORITY.PRIORITYID <> 0
AND MOS.PRIORITY.PRIORITYID =
MOS.ASSIGNEDTASKSWORKQUEUE.PRIORITYID(+)
AND MOS.ASSIGNEDTASKSWORKQUEUE.TASKSTATUSID
(+) = 1 " ;
For more information about JATO, including download information, pleasevisit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp

Todd,
Sorry for the delay with the answer, I've tried to obtain JATO 1.2
and repeat the project migration to verify whether version 1.2 solves
my problem or not (actually, it is a pilot sub-project).
Unfortunately, I still have no 1.2 version.
Let me try to answer on your question without getting the results
with JATO 1.2. Your explanation sounds like version 1.2 is very close
to solve the problem. Actually, our situation is easier because we
have SELECT object only, not SELECT and UPDATE. For data integrity
the only 'Select' ND's do(s) have been used through the whole
project. The backend communication (update, delete) is provided via
EJB like (entity) Java classes.
My question is: could I define synthetic field with 1.1.1 version. By
the way, word synthetic reflects the possibility to construct the
field under certain SQL circumstances (SELECT, UPDATE, e.g.) or the
possibility to construct a `fake' field (for example,
CountColumn of a do) as well. If the later is true, could you please
give a brief idea how to create this synthetic field.
After the translation in the doPriorityCountModelImpl class we've
got:
public static final String COLUMN_DFPRIORITYDESC="";
public static final String QUALIFIED_COLUMN_DFPRIO
RITYDESC=".";
public static final String COLUMN_DFPRIORITYCOUNT="";
public static final String QUALIFIED_COLUMN_DFPRIO
RITYCOUNT=".";
(see my original post please with details, as well).
If this is not a problem for 1.2 please do not waste your time to fix
it for 1.1.1. I need to repeat my results with the version 1.2 anyway.
We have a number of similar idioms through the project. In this
particular case, the CountColumn that counts the field from another
table may bring problem for manual adjustment (see my original
notes). The whole SQL query is as follows (for this case):
SELECT MIN(MOS.PRIORITY.PDESCRIPTION),
COUNT(ASSIGNEDTASKSWORKQUEUE.PRIORITYID),
MOS.PRIORITY.PRIORITYID
FROM MOS.ASSIGNEDTASKSWORKQUEUE, MOS.PRIORITY, MOS.DEAL
WHERE MOS.DEAL.SCENARIORECOMMENDED = 'Y'
AND MOS.DEAL.COPYTYPE <> 'T'
GROUP BY MOS.PRIORITY.PRIORITYID
ORDER BY MOS.PRIORITY.PRIORITYID ASC
During the pre-handler activity (it is the part of our Object
Framework on the top of Netdynamics Object Framework) system passes
id (and mos.deal.dealid = XXX) to the do (select query). After the
run-time execution of this do the results are displayed on the screen
bind to the repeatable statics.
Thank you very much,
Vladimir
--- In iPlanet-JATO@y..., "Todd Fast" <Todd.Fast@S...> wrote:
Vladimir--
I'm going to answer this question without doing my full homework on it;
please let me know if I hit the mark or not. If I understand correctly, you
have a problem using a model for both UPDATE and SELECT queries because of a
computed column...correct?
If so, this issue is solved in JATO 1.2. 1.2 has an attribute in the field
descriptor to indicate in which type of queries a field should be used. You
can use this attribute to indicate that a field should only be used for
UPDATE queries, SELECT queries, or whatever combination of query types you
require. You can then define synthetic fields for use only during one of
the query types.
Does this sound useful in fixing your issue? A way around this in JATO 1.1
would be to create separate models for SELECT and UPDATE queries. The
SELECT model could contain all the fields for the joined query, but the
UPDATE model would contain info for only one table. The 1.2 feature simple
allows you to do the same using one model.
Todd
----- Original Message -----
From: "vivanov4114" <vivanov@b...>
Sent: Friday, January 11, 2002 8:12 AM
Subject: [iPlanet-JATO] More on ComputedColumn issue
We have a similar problem with do's ComputedColumn after the
translation as Kostas described in his detailed message #439.
We have JATO/iMT version 1.1. Is the resolution of this problem
added
to the version 1.2 (or 1.2.1)?
I've tried to adjust the ModelImpl class based on the .sdo file
(using ComputedColumn attributes) for these fields and failed.
Whether I missed something else, or our situation is a little bit
different.
In our case the dataObject has one Computed Field from one table and
another Computed Field from another table along with joint between
these two tables and third one, and, finally, the whole stuff is
under the repeatable (with static fields bindings to these two
computed fields).
The modelImpl class after the translation (as in the #439) has the
same values "" and "." for ..._NAME and QUALIFIED_..._NAME strings
respectively (for each computed do's field).
I guess that we could meet extra problem with this (for manual
adjustment) because of there is no TableName attribute in .sdo file
for computed field (as well as there is no ColumnName attribute for
computed field). If ComputedColumn attribute (computed field) could
play a role of ColumnName attribute (regular case), what would be an
analog of TableName attribute for computed field?
The bottom line of this is as follows: we have a same
SQLException "Invalid Column Name"
from ResultSetModelBase.updateModel() as Kostas described. It causes
the problem for
RequestHandlingTiledViewBase.executeAutoRetrieving() method that
can't bind the proper Model.
Finally, beginDisplay() method from
pgXXXXPriorityCountTiledView.class throws exception and
jasper compiler brings run-time error (Tomcat 3.2).
Kostas, if this problem still exists for translation of such cases,
could you please post a fragment that fixed you original problem in
addition to the message #439 (just to be sure, that I haven't missed
something important).
Thank you very much in advance.
Vladimir Ivanov,
P. S. I've enclosed the excerption from the .sdo file for this
dataObject below.
Class "SQLObject" ;
Name "doPriorityCount" ;
DataFields {
0 { // first df is a computed column from the first
//table
Class "DataField" ;
Name "dfPriorityDesc" ;...........................................
ComputedColumn "MIN
(MOS.PRIORITY.PDESCRIPTION)" ;............................................
1 { // second df is a computed column from the second
// table
Class "DataField" ;
Name "dfPriorityCount" ;
ComputedColumn "COUNT
(ASSIGNEDTASKSWORKQUEUE.PRIORITYID)" ;
2 { // third df is a regular df
Class "DataField" ;
Name "MOS_PRIORITY_PRIORITYID" ;
TableName "MOS.PRIORITY" ; // this attribute
// doesn't exist for ComputedColumn
ColumnName "PRIORITYID" ; // this attribute
// doesn't exist for ComputedColumn
DataCachingEnabled "False" ;
DataCachingDuration "0" ;
DataCachingMaxRows "200" ;
DataObjectType "Select" ;
Tables "MOS.ASSIGNEDTASKSWORKQUEUE,MOS.PRIORITY,MOS.DEAL" ;
SQLDistinct "False" ;
SelectFilter {
"MOS.DEAL.SCENARIORECOMMENDED" ;
"=" ;
"'Y'" ;
"AND" ;
"MOS.DEAL.COPYTYPE" ;
"<>" ;
"'T'" ;
SelectOrder {
"MOS.PRIORITY.PRIORITYID ASC" ;
SelectGroup {
"MOS.PRIORITY.PRIORITYID" ;
EnableEntireTableDelete "False" ;
EnableEntireTableUpdate "False" ;
SQLTextOverrideSelect "Partial" ;
SQLTextOverrideDelete "None" ;
SQLTextSelectJoin "MOS.ASSIGNEDTASKSWORKQUEUE.DEALID =
MOS.DEAL.DEALID
AND MOS.PRIORITY.PRIORITYID <> 0
AND MOS.PRIORITY.PRIORITYID =
MOS.ASSIGNEDTASKSWORKQUEUE.PRIORITYID(+)
AND
MOS.ASSIGNEDTASKSWORKQUEUE.TASKSTATUSID
(+) = 1 " ;
For more information about JATO, including download information, please
visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp

Re: [iPlanet-JATO] Re: Use Of models in utility classes - Pease don't forget about the regular expression potential

Namburi,
When you said you used the Reg Exp tool, did you use it only as
preconfigured by the iMT migrate application wizard?
Because the default configuration of the regular expression tool will only
target the files in your ND project directories. If you wish to target
classes outside of the normal directory scope, you have to either modify the
"Source Directory" property OR create another instance of the regular
expression tool. See the "Tool" menu in the iMT to create additional tool
instances which can each be configured to target different sets of files
using different sets of rules.
Usually, I utilize 3 different sets of rules files on a given migration:
spider2jato.xml
these are the generic conversion rules (but includes the optimized rules for
ViewBean and Model based code, i.e. these rules do not utilize the
RequestManager since it is not needed for code running inside the ViewBean
or Model classes)
I run these rules against all files.
See the file download section of this forum for periodic updates to these
rules.
nonProjectFileRules.xml
these include rules that add the necessary
RequestManager.getRequestContext(). etc prefixes to many of the common
calls.
I run these rules against user module and any other classes that do not are
not ModuleServlet, ContainerView, or Model classes.
appXRules.xml
these rules include application specific changes that I discover while
working on the project. A common thing here is changing import statements
(since the migration tool moves ND project code into different jato
packaging structure, you sometime need to adjust imports in non-project
classes that previously imported ND project specific packages)
So you see, you are not limited to one set of rules at all. Just be careful
to keep track of your backups (the regexp tool provides several options in
its Expert Properties related to back up strategies).
----- Original Message -----
From: <vnamboori@y...>
Sent: Wednesday, August 08, 2001 6:08 AM
Subject: [iPlanet-JATO] Re: Use Of models in utility classes - Pease don't
forget about the regular expression potential
Thanks Matt, Mike, Todd
This is a great input for our migration. Though we used the existing
Regular Expression Mapping tool, we did not change this to meet our
own needs as mentioned by Mike.
We would certainly incorporate this to ease our migration.
Namburi
--- In iPlanet-JATO@y..., "Todd Fast" <toddwork@c...> wrote:
All--
Great response. By the way, the Regular Expression Tool uses thePerl5 RE
syntax as implemented by Apache OROMatcher. If you're doing lotsof these
sorts of migration changes manually, you should definitely buy theO'Reilly
book "Mastering Regular Expressions" and generate some rules toautomate the
conversion. Although they are definitely confusing at first,regular
expressions are fairly easy to understand with some documentation,and are
superbly effective at tackling this kind of migration task.
Todd
----- Original Message -----
From: "Mike Frisino" <Michael.Frisino@S...>
Sent: Tuesday, August 07, 2001 5:20 PM
Subject: Re: [iPlanet-JATO] Use Of models in utility classes -Pease don't
forget about the regular expression potential
Also, (and Matt's document may mention this)
Please bear in mind that this statement is not totally correct:
Since the migration tool does not do much of conversion for
these
utilities we have to do manually.Remember, the iMT is a SUITE of tools. There is the extractiontool, and
the translation tool, and the regular expression tool, and severalother
smaller tools (like the jar and compilation tools). It is correctto state
that the extraction and translation tools only significantlyconvert the
primary ND project objects (the pages, the data objects, and theproject
classes). The extraction and translation tools do minimumtranslation of the
User Module objects (i.e. they repackage the user module classes inthe new
jato module packages). It is correct that for all other utilityclasses
which are not formally part of the ND project, the extraction and
translation tools do not perform any migration.
However, the regular expression tool can "migrate" any arbitrary
file
(utility classes etc) to the degree that the regular expressionrules
correlate to the code present in the arbitrary file. So first andforemost,
if you have alot of spider code in your non-project classes youshould
consider using the regular expression tool and if warranted adding
additional rules to reduce the amount of manual adjustments thatneed to be
made. I can stress this enough. We can even help you write theregular
expression rules if you simply identify the code pattern you wish to
convert. Just because there is not already a regular expressionrule to
match your need does not mean it can't be written. We have notnearly
exhausted the possibilities.
For example if you say, we need to convert
CSpider.getDataObject("X");
To
RequestManager.getRequestContext().getModelManager().getModel(XModel.class);
Maybe we or somebody else in the list can help write that regularexpression if it has not already been written. For instance in thelast
updated spider2jato.xml file there is already aCSpider.getCommonPage("X")
rule:

<mapping-rule>
<mapping-rule-primarymatch>
<![CDATA[CSpider[.\s]*getPage[\s]*\(\"([^"]*)\"]]>
</mapping-rule-primarymatch>
<mapping-rule-replacement>
<mapping-rule-match>
<![CDATA[CSpider[.\s]*getPage[\s]*\(\"([^"]*)\"]]>
</mapping-rule-match>
<mapping-rule-substitute>
<![CDATA[getViewBean($1ViewBean.class]]>
</mapping-rule-substitute>
</mapping-rule-replacement>
</mapping-rule>
Following this example a getDataObject to getModel would look
like this:
<mapping-rule>
<mapping-rule-primarymatch>
<![CDATA[CSpider[.\s]*getDataObject[\s]*\(\"([^"]*)\"]]>
</mapping-rule-primarymatch>
<mapping-rule-replacement>
<mapping-rule-match>
<![CDATA[CSpider[.\s]*getDataObject[\s]*\(\"([^"]*)\"]]>
</mapping-rule-match>
<mapping-rule-substitute>
<![CDATA[getModel($1Model.class]]>
</mapping-rule-substitute>
</mapping-rule-replacement>
</mapping-rule>
In fact, one migration developer already wrote that rule andsubmitted it
for inclusion in the basic set. I will post another upgrade to thebasic
regular expression rule set, look for a "file uploaded" posting.Also,
please consider contributing any additional generic rules that youhave
written for inclusion in the basic set.
Please not, that in some cases (Utility classes in particular)
the rule
application may be more effective as TWO sequention rules ratherthan one
monolithic rule. Again using the example above, it will convert
CSpider.getDataObject("Foo");
To
getModel(FooModel.class);
Now that is the most effective conversion for that code if that
code is in
a page or data object class file. But if that code is in a Utilityclass you
really want:
>
RequestManager.getRequestContext().getModelManager().getModel(FooModel.class
So to go from
getModel(FooModel.class);
To
RequestManager.getRequestContext().getModelManager().getModel(FooModel.class
You would apply a second rule AND you would ONLY run this rule
against
your utility classes so that you would not otherwise affect yourViewBean
and Model classes which are completely fine with the simplegetModel call.
<mapping-rule>
<mapping-rule-primarymatch>
<![CDATA[getModel$]]>
</mapping-rule-primarymatch>
<mapping-rule-replacement>
<mapping-rule-match>
<![CDATA[getModel\(]]>
</mapping-rule-match>
<mapping-rule-substitute>
<![CDATA[RequestManager.getRequestContext().getModelManager().getModel(]]>
</mapping-rule-substitute>
</mapping-rule-replacement>
</mapping-rule>
A similer rule can be applied to getSession and other CSpider APIcalls.
For instance here is the rule for converting getSession calls toleverage
the RequestManager.
<mapping-rule>
<mapping-rule-primarymatch>
<![CDATA[getSession\($\.]]>
</mapping-rule-primarymatch>
<mapping-rule-replacement>
<mapping-rule-match>
<![CDATA[getSession\.]]>
</mapping-rule-match>
<mapping-rule-substitute>
<![CDATA[RequestManager.getSession().]]>
</mapping-rule-substitute>
</mapping-rule-replacement>
</mapping-rule>
----- Original Message -----
From: "Matthew Stevens" <matthew.stevens@e...>
Sent: Tuesday, August 07, 2001 12:56 PM
Subject: RE: [iPlanet-JATO] Use Of models in utility classes
Namburi,
I will post a document to the group site this evening which has
the
details
on various tactics of migrating these type of utilities.
Essentially,
you
either need to convert these utilities to Models themselves or
keep the
utilities as is and simply use the
RequestManager.getRequestContext.getModelManager().getModel()
to statically access Models.
For CSpSelect.executeImmediate() I have an example of customhelper
method
as a replacement whicch uses JDBC results instead of
CSpDBResult.
matt
-----Original Message-----
From: vnamboori@y... [mailto:<a href="/group/SunONE-JATO/post?protectID=081071113213093190112061186248100208071048">vnamboori@y...</a>]
Sent: Tuesday, August 07, 2001 3:24 PM
Subject: [iPlanet-JATO] Use Of models in utility classes
Hi All,
In the present ND project we have lots of utility classes.
These
classes in diffrent directory. Not part of nd pages.
In these classes we access the dataobjects and do themanipulations.
So we access dataobjects directly like
CSpider.getDataObject("do....");
and then execute it.
Since the migration tool does not do much of conversion forthese
utilities we have to do manually.
My question is Can we access the the models in the postmigration
sameway or do we need requestContext?
We have lots of utility classes which are DataObjectintensive. Can
someone suggest a better way to migrate this kind of code.
Thanks
Namburi
[email protected]
[email protected]
[Non-text portions of this message have been removed]
[email protected]
[email protected]

Namburi,
When you said you used the Reg Exp tool, did you use it only as
preconfigured by the iMT migrate application wizard?
Because the default configuration of the regular expression tool will only
target the files in your ND project directories. If you wish to target
classes outside of the normal directory scope, you have to either modify the
"Source Directory" property OR create another instance of the regular
expression tool. See the "Tool" menu in the iMT to create additional tool
instances which can each be configured to target different sets of files
using different sets of rules.
Usually, I utilize 3 different sets of rules files on a given migration:
spider2jato.xml
these are the generic conversion rules (but includes the optimized rules for
ViewBean and Model based code, i.e. these rules do not utilize the
RequestManager since it is not needed for code running inside the ViewBean
or Model classes)
I run these rules against all files.
See the file download section of this forum for periodic updates to these
rules.
nonProjectFileRules.xml
these include rules that add the necessary
RequestManager.getRequestContext(). etc prefixes to many of the common
calls.
I run these rules against user module and any other classes that do not are
not ModuleServlet, ContainerView, or Model classes.
appXRules.xml
these rules include application specific changes that I discover while
working on the project. A common thing here is changing import statements
(since the migration tool moves ND project code into different jato
packaging structure, you sometime need to adjust imports in non-project
classes that previously imported ND project specific packages)
So you see, you are not limited to one set of rules at all. Just be careful
to keep track of your backups (the regexp tool provides several options in
its Expert Properties related to back up strategies).
----- Original Message -----
From: <vnamboori@y...>
Sent: Wednesday, August 08, 2001 6:08 AM
Subject: [iPlanet-JATO] Re: Use Of models in utility classes - Pease don't
forget about the regular expression potential
Thanks Matt, Mike, Todd
This is a great input for our migration. Though we used the existing
Regular Expression Mapping tool, we did not change this to meet our
own needs as mentioned by Mike.
We would certainly incorporate this to ease our migration.
Namburi
--- In iPlanet-JATO@y..., "Todd Fast" <toddwork@c...> wrote:
All--
Great response. By the way, the Regular Expression Tool uses thePerl5 RE
syntax as implemented by Apache OROMatcher. If you're doing lotsof these
sorts of migration changes manually, you should definitely buy theO'Reilly
book "Mastering Regular Expressions" and generate some rules toautomate the
conversion. Although they are definitely confusing at first,regular
expressions are fairly easy to understand with some documentation,and are
superbly effective at tackling this kind of migration task.
Todd
----- Original Message -----
From: "Mike Frisino" <Michael.Frisino@S...>
Sent: Tuesday, August 07, 2001 5:20 PM
Subject: Re: [iPlanet-JATO] Use Of models in utility classes -Pease don't
forget about the regular expression potential
Also, (and Matt's document may mention this)
Please bear in mind that this statement is not totally correct:
Since the migration tool does not do much of conversion for
these
utilities we have to do manually.Remember, the iMT is a SUITE of tools. There is the extractiontool, and
the translation tool, and the regular expression tool, and severalother
smaller tools (like the jar and compilation tools). It is correctto state
that the extraction and translation tools only significantlyconvert the
primary ND project objects (the pages, the data objects, and theproject
classes). The extraction and translation tools do minimumtranslation of the
User Module objects (i.e. they repackage the user module classes inthe new
jato module packages). It is correct that for all other utilityclasses
which are not formally part of the ND project, the extraction and
translation tools do not perform any migration.
However, the regular expression tool can "migrate" any arbitrary
file
(utility classes etc) to the degree that the regular expressionrules
correlate to the code present in the arbitrary file. So first andforemost,
if you have alot of spider code in your non-project classes youshould
consider using the regular expression tool and if warranted adding
additional rules to reduce the amount of manual adjustments thatneed to be
made. I can stress this enough. We can even help you write theregular
expression rules if you simply identify the code pattern you wish to
convert. Just because there is not already a regular expressionrule to
match your need does not mean it can't be written. We have notnearly
exhausted the possibilities.
For example if you say, we need to convert
CSpider.getDataObject("X");
To
RequestManager.getRequestContext().getModelManager().getModel(XModel.class);
Maybe we or somebody else in the list can help write that regularexpression if it has not already been written. For instance in thelast
updated spider2jato.xml file there is already aCSpider.getCommonPage("X")
rule:

<mapping-rule>
<mapping-rule-primarymatch>
<![CDATA[CSpider[.\s]*getPage[\s]*\(\"([^"]*)\"]]>
</mapping-rule-primarymatch>
<mapping-rule-replacement>
<mapping-rule-match>
<![CDATA[CSpider[.\s]*getPage[\s]*\(\"([^"]*)\"]]>
</mapping-rule-match>
<mapping-rule-substitute>
<![CDATA[getViewBean($1ViewBean.class]]>
</mapping-rule-substitute>
</mapping-rule-replacement>
</mapping-rule>
Following this example a getDataObject to getModel would look
like this:
<mapping-rule>
<mapping-rule-primarymatch>
<![CDATA[CSpider[.\s]*getDataObject[\s]*\(\"([^"]*)\"]]>
</mapping-rule-primarymatch>
<mapping-rule-replacement>
<mapping-rule-match>
<![CDATA[CSpider[.\s]*getDataObject[\s]*\(\"([^"]*)\"]]>
</mapping-rule-match>
<mapping-rule-substitute>
<![CDATA[getModel($1Model.class]]>
</mapping-rule-substitute>
</mapping-rule-replacement>
</mapping-rule>
In fact, one migration developer already wrote that rule andsubmitted it
for inclusion in the basic set. I will post another upgrade to thebasic
regular expression rule set, look for a "file uploaded" posting.Also,
please consider contributing any additional generic rules that youhave
written for inclusion in the basic set.
Please not, that in some cases (Utility classes in particular)
the rule
application may be more effective as TWO sequention rules ratherthan one
monolithic rule. Again using the example above, it will convert
CSpider.getDataObject("Foo");
To
getModel(FooModel.class);
Now that is the most effective conversion for that code if that
code is in
a page or data object class file. But if that code is in a Utilityclass you
really want:
>
RequestManager.getRequestContext().getModelManager().getModel(FooModel.class
So to go from
getModel(FooModel.class);
To
RequestManager.getRequestContext().getModelManager().getModel(FooModel.class
You would apply a second rule AND you would ONLY run this rule
against
your utility classes so that you would not otherwise affect yourViewBean
and Model classes which are completely fine with the simplegetModel call.
<mapping-rule>
<mapping-rule-primarymatch>
<![CDATA[getModel$]]>
</mapping-rule-primarymatch>
<mapping-rule-replacement>
<mapping-rule-match>
<![CDATA[getModel\(]]>
</mapping-rule-match>
<mapping-rule-substitute>
<![CDATA[RequestManager.getRequestContext().getModelManager().getModel(]]>
</mapping-rule-substitute>
</mapping-rule-replacement>
</mapping-rule>
A similer rule can be applied to getSession and other CSpider APIcalls.
For instance here is the rule for converting getSession calls toleverage
the RequestManager.
<mapping-rule>
<mapping-rule-primarymatch>
<![CDATA[getSession\($\.]]>
</mapping-rule-primarymatch>
<mapping-rule-replacement>
<mapping-rule-match>
<![CDATA[getSession\.]]>
</mapping-rule-match>
<mapping-rule-substitute>
<![CDATA[RequestManager.getSession().]]>
</mapping-rule-substitute>
</mapping-rule-replacement>
</mapping-rule>
----- Original Message -----
From: "Matthew Stevens" <matthew.stevens@e...>
Sent: Tuesday, August 07, 2001 12:56 PM
Subject: RE: [iPlanet-JATO] Use Of models in utility classes
Namburi,
I will post a document to the group site this evening which has
the
details
on various tactics of migrating these type of utilities.
Essentially,
you
either need to convert these utilities to Models themselves or
keep the
utilities as is and simply use the
RequestManager.getRequestContext.getModelManager().getModel()
to statically access Models.
For CSpSelect.executeImmediate() I have an example of customhelper
method
as a replacement whicch uses JDBC results instead of
CSpDBResult.
matt
-----Original Message-----
From: vnamboori@y... [mailto:<a href="/group/SunONE-JATO/post?protectID=081071113213093190112061186248100208071048">vnamboori@y...</a>]
Sent: Tuesday, August 07, 2001 3:24 PM
Subject: [iPlanet-JATO] Use Of models in utility classes
Hi All,
In the present ND project we have lots of utility classes.
These
classes in diffrent directory. Not part of nd pages.
In these classes we access the dataobjects and do themanipulations.
So we access dataobjects directly like
CSpider.getDataObject("do....");
and then execute it.
Since the migration tool does not do much of conversion forthese
utilities we have to do manually.
My question is Can we access the the models in the postmigration
sameway or do we need requestContext?
We have lots of utility classes which are DataObjectintensive. Can
someone suggest a better way to migrate this kind of code.
Thanks
Namburi
[email protected]
[email protected]
[Non-text portions of this message have been removed]
[email protected]
[email protected]

Re: [iPlanet-JATO] Re: onSecurityCheckFailedEvent & & onSessionTimeoutEvent

My mistake. Thanks for the clarification, Craig.
Todd
----- Original Message -----
From: "Craig V. Conover" <craig.conover@s...>
Sent: Friday, January 04, 2002 11:14 AM
Subject: Re: [iPlanet-JATO] Re: onSecurityCheckFailedEvent & &
onSessionTimeoutEvent
Alex,
In addition to Todd saying that the ND security object "is nothing morethan a
sessionable object...", remember that the security object did nothing morethan
retrieve the user profile from some persistent store: a database or athird party
API. So the security object was just a very specialized model (a dataobject in ND
terms, of course), although it need not be a model, it could just be anarbitrary
Java class, whatever works best.
Once the security object was triggered to perform a user profile lookup,the
profile was stored in an instance of CSpUserProfile and kept in the user's
session. The project object was then the object that was responsible forchecking
the user profile for privileges, previous pages, and db logins and such.As Todd
explained, the ViewBean API now does the security check (as opposed toJATO's
module servlet, or ND's project object), so extending ViewBeanBase andoverriding
securityCheck is a convenient way to mimic ND's security hooks. You couldeven
override a method or event in the module servlet to do a lookup if youwant a
greater parallel to ND, but this is unneccessary. Either way, the securitycheck
is performed before the "page" is "loaded".
c
Todd Fast wrote:
Agreed. This is partly why we have never added such a feature to JATO
(though we've talked about it many many times), because it seemed too
prescriptive and possibly at odds with the other solutions people favor.
We're still on the fence. We want to add it, but feel it'll take a fair
bit
of design to do properly and extensibly.
However, realize that the ND security object is nothing more than a
sessionable object with slots for username, password, and priveleges.This
is almost trivially easy to replicate on your own, with a small additionof
code to automatically handle lifecycle and security checking. It wouldbe
extremely easy to create a subclass of ViewBeanBase that would overridethe
securityCheck() method to check the state of a sessioned "user profile"
object. Add to the ViewBean a declared set of "privelege" strings, andyou
can check the profile object against those required.
I feel I'm being unclear--do you see where I'm going?
Todd
----- Original Message -----
From: "njdoe123" <first.us@a...>
Sent: Friday, December 28, 2001 6:44 AM
Subject: [iPlanet-JATO] Re: onSecurityCheckFailedEvent & &
onSessionTimeoutEvent
Hi,
We used a lot of "security object" in netD projects. Each used
username, password and privilege for login. After migration,
we have to hand code all login codes manually. Session control
is pretty standard in j2ee, i'm wondering whether there is a
best practice example available for netD login feature.
Since security was one of the outstanding feature in netD, it will
be a great idea to have a stadard plugin to support this feature
after migration. I wish v1.2 could supply a direction, although
there are several login methods in j2ee.
Thanks,
Alex Lin
--- In iPlanet-JATO@y..., "Todd Fast" <todd.fast@s...> wrote:
Small correction: the name of the method in ViewBean is"securityCheck()",
not "onSecurityCheck()". The method would've been better named
"checkSecurity()", but too late now. <grin>
Todd
----- Original Message -----
From: "Craig V. Conover" <craig.conover@s...>
Sent: Monday, December 17, 2001 12:47 PM
Subject: Re: [iPlanet-JATO] onSecurityCheckFailedEvent & &
onSessionTimeoutEvent
The iMT has a ND to JATO/J2EE mapping document that covers ND
events and
common ND class/variable/method mapping.
To answer you two questions below:
onSessionTimoutEvent is onSessionTimeout in JATO and can beoverriden in
any class the subclasses JATO'scom.iplanet.jato.ApplicationServletBase.
Typically, this is done in you application servlet class which allof
your module servlets in the application will subclass.
onSecurityCheckFailedEvent is an ND specific event that istriggered
when a Security exception is thrown in ND. In JATO, a
SecurityCheckException is thrown when the default securitychecking in
JATO fails. JATO's default security is to make sure theRequestContext
object is not null. This is done in the ViewBean API. The
onSecurityCheck event in JATO allows you to hook into thisbehavior and
write your own security checking, or hook in a third party API.You can
call super so that you still get the RequextContext null check.
You should create a "non-visual" ViewBean (behavior only) thatoverrides
the onSecurityCheck event, and all other ViewBeans in yourapplication
extend it to inherit this security checking behavior.
You could also hook in the security in your application Servlet by
overriding one of the events in ApplicationServletBase, like
onBeforeRequest.
craig
njdoe123 wrote:
Hi,
We have the following two events (onSecurityCheckFailedEvent
& onSessionTimeoutEvent) across all ND projects. I guess
it's pretty common for netdynamics project.
How do you solve the corresponding issues in j2ee ?
Is there any example available ?
Thanks,
Alex
//[[SPIDER_EVENT<this_onSecurityCheckFailedEvent>
public int this_onSecurityCheckFailedEvent
(CSpProjectSecurityEvent event)
switch (event.getFailureType() )
case NEW_SECURITY_CHECK_PRIV_FAILURE_TYPE:
// do something
CSpPage loginPage1 = CSpider.getPage("PgLogin");
CSpString msg1 = new CSpString("Wrong District Code, UserID
or
Password. Try again.");
loginPage1.setDisplayFieldValue("StMsg1", msg1);
loginPage1.load (false);
break;
case SESSION_CONTINUITY_FAILURE_TYPE:
// do something else
CSpPage loginPage2 = CSpider.getPage("PgLogin");
CSpString msg2 = new CSpString("You must login first...");
loginPage2.setDisplayFieldValue("StMsg1", msg2);
loginPage2.load (false);
break;
return (STOP);
//]]SPIDER_EVENT<this_onSecurityCheckFailedEvent>
//[[SPIDER_EVENT<this_onSessionTimeoutEvent>
public int this_onSessionTimeoutEvent(CSpProjectSessionEventevent)
CSpString msg3 = new CSpString("You were gone too long - login
again");
CSpPage loginPage3 = CSpider.getPage("PgLogin");
loginPage3.setDisplayFieldValue("StMsg1", msg3);
// stop any further processing of this original user request
loginPage3.setDisplayFieldValue("District_ID", newCSpString(""));
loginPage3.setDisplayFieldValue("User_ID", new CSpString(""));
loginPage3.setDisplayFieldValue("Password", newCSpString(""));
loginPage3.load (false);
return (PROCEED);
//]]SPIDER_EVENT<this_onSessionTimeoutEvent>
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
Service.
For more information about JATO, including download information,
please
visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
For more information about JATO, including download information, pleasevisit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
For more information about JATO, including download information, pleasevisit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp

Thank you - Jin and Todd.
Will try that.
Atul
--- In iPlanet-JATO@y..., Byung Jin Chun <bchun@n...> wrote:
try using kregedit and modify the key for the jvm args, using the -x
parameters for the 1.2 runtime
Jin
-----Original Message-----
From: Todd Fast [mailto:<a href="/group/SunONE-JATO/post?protectID=101233080150035167169232031248066208071048">Todd.Fast@S...</a>]
Sent: Tuesday, February 19, 2002 8:40 PM
Subject: Re: [iPlanet-JATO] Re: OutOfMemoryError
Atul--
Out of curiosity - How do you modify the memory parameters for
the container's VM ?? I know I should try to do some research but
figured you may already have some insight and willingness to
share.
Please consider this as low priority.It differs by container; I don't remember details of any particular one.
>
Todd
For more information about JATO, including download information, please
visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
<http://developer.iplanet.com/tech/appserver/framework/index.jsp>
[Non-text portions of this message have been removed]

RE: [iPlanet-JATO] Re: Deployment problem

Chidu,
I think that you are mired in the very common confusion of the default
behavior of the ApplicationServletBase.parsePathInfo() which will determine
the controlling/handling ViewBean via a URL design pattern. Lets take a look
at the URL
/NASApp/MigtoolboxSampleAppWar/MigtoolboxSample/IndexPage.jsp
is decomposed as follows:
/NASApp -> well, this is long story but is absolutely necessary, welcome to
iAS
/MigtoolboxSampleAppWar -> is the web application name, taken as the name of
the WAR file when there is no EAR file (this allows the Servlet/JSP
container to deferences the web application root under
<ias>/APPS/modules/MigtoolboxSampleAppWar) I think this part of the URL is
called th Context Path
/MigtoolboxSample -> is the Servlet Path, and will either directly reference
or match a Servlet Mapping
for instance
<servlet-mapping>
<servlet-name>MigtoolboxSampleServlet</servlet-name>
<url-pattern>/MigtoolboxSample/*</url-pattern>
</servlet-mapping>
tells the Servlet Container that the Servlet Path
/MigtoolboxSample
maps to the Module Servlet MigtoolboxSampleServlet
This is how EVERY request makes its way to the "front controller" pattern in
JATO. It is fundamental to JATO Applicatioan that every request pass
through the ModuleServlet.
every else on the URL past the Servlet Path is the PATH INFO. Based on this
understanding, you will see why the
ApplicationServletBase.parsePathInfo()
is so important. In parsePathInfo() the PATH INFO is compared to the design
pattern
/VIEWBEANNAME*
to determine the handling ViewBean from the first String Token in the path
info. For instance, the starting URL of the Sample Application is
/NASApp/MigtoolboxSampleAppWar/MigtoolboxSample/IndexPage
The PATH INFO is [IndexPage]
and IndexPage[ViewBean] is the handling ViewBean. Therefore, any simiarl
URL like
/NASApp/MigtoolboxSampleAppWar/MigtoolboxSample/IndexPage.jsp
/NASApp/MigtoolboxSampleAppWar/MigtoolboxSample/IndexPage.matt
/NASApp/MigtoolboxSampleAppWar/MigtoolboxSample/IndexPage.mike
/NASApp/MigtoolboxSampleAppWar/MigtoolboxSample/IndexPage.chidu
/NASApp/MigtoolboxSampleAppWar/MigtoolboxSample/IndexPage.XXX
will all result in the same handling View Bean
IndexPageViewBean
It is very important to understand that you CANNOT hit the JATO JSPs
directly. You must hit the "front controller" ModuleServlet which will
always delegate control to the handling ViewBean (a la, the "service to
workers" pattern)
You can attempt to hit the JSP directly but you need the right J2EE URL
/NASApp/MigtoolboxSampleAppWar/MigtoolboxSampleApp/MigtoolboxSample/IndexPag
e.jsp
this URL will directly hit the JSP. However, you will recieve an error
because the JATO framework quickly determines that there is no
RequestContext in the HttpRequest attributes and assumes that the "front
controller" was bypassed. Try it. You will get ERROR.
Lets go back to what you are trying to do, place Models and Viewbeans in
separate directories. I recommend that you move the Models. Models are
ONLY referenced by TYPE via the ModelManager, the compiler will ensure that
your code is correct and matches the packages, file locations, import
statements, etc. ViewBeans, on the other hand are related to the
ModuleServlet their are contained in and are loaded via type names according
to a design pattern.
if you want to separate models and Viewbean then simply move the Model and
make sure everything compiles.
you cannot move the ViewBeans
if you do want to move the JSP peers of the Viewbeans, then you can put them
anywhere in the web application doc root. When you do, update the
DEFAULT_DISPLAY_URL as Mike suggested
matt
-----Original Message-----
From: Mike Frisino [mailto:<a href="/group/SunONE-JATO/post?protectID=174176219122158198138082063148231088239026066196217193234150166091061">Michael.Frisino@S...</a>]
Sent: Thursday, July 26, 2001 10:48 PM
Subject: Re: [iPlanet-JATO] Re: Deployment problem
Chidu,
Did you have it running fine in the original default configuration, before
you started changing things around? The URL should not access the .jsp
directly. The URL should look more like this
"/NASApp/MigtoolboxSampleAppWar/MigtoolboxSample/IndexPage", without the
.jsp.
Also, please read the "Migration Tech Notes" document that is
linked to the
main doc index page. There is some information in there related
to trying to
run the sample application under iAS (see Tech Note 4 in
particular, "Note
on running the iMT "MigtoolboxSample" in iPlanet Application Server )
----- Original Message -----
From: <<a href="/group/SunONE-JATO/post?protectID=219015020150194233215218164140244063078048234051197">chidusv@y...</a>>
Sent: Thursday, July 26, 2001 7:27 PM
Subject: [iPlanet-JATO] Re: Deployment problem
Hi Mike,
I tried changing the url in all the viewbeans to reflect the new sub-
directory for the viewbeans(I have placed the jsps and viewbeans in
a sub-directory under MigtoolboxSampleApp/MigtoolboxSample). But I'm
still not able to get access to the jsps. I basically see the
message "GX Error Socket Error Code missing!!" error on the browser
thrown by iPlanet, but the log doesn't tell me anything. Does the url
which I give to access the jsp change accordingly, i.e., should I
give something other
than /NASApp/MigtoolboxSampleAppWar/MigtoolboxSample/IndexPage.jsp.
If I try to use any other url other
than /NASApp/MigtoolboxSampleAppWar/MigtoolboxSample/IndexPage.jsp, I
see the FileNotFoundException in the log.
I guess I'm still missing something.
Thanks for your help.
--Chidu.
--- In <a href="/group/SunONE-JATO/post?protectID=210083235237078198050118178206047166136158139046209">iPlanet-JATO@y...</a>, "Mike Frisino" <<a href="/group/SunONE-JATO/post?protectID=174176219122158198138082063148231088239026066196217130152150">Michael.Frisino@S...</a>> wrote:
Chidu.
Did you also adjust the following member in each of the ViewBeans?
public static final String DEFAULT_DISPLAY_URL=
"/jatosample/module1/Index.jsp";
Try adjusting this to be consistent with your new hierarchy.
Also, if you still have problems, send us the error message thatyou recieve
when you try to access the page. That would help.
----- Original Message -----
From: <<a href="/group/SunONE-JATO/post?protectID=219015020150194233215218164036129208">chidusv@y...</a>>
Sent: Thursday, July 26, 2001 4:48 PM
Subject: [iPlanet-JATO] Deployment problem
Hi,
We have a requirement to seperate the models and viewbeans and
keep
them in seperate directories. Is it possible to seperate the
viewbeans and models not be in the same directory?
I tried seperating the two in the MigtoolboxSampleApp application
provided by JATO. I changed the package and import statements
accordingly in the viewbeans, jsps and the models. But when I
deployed the application, I'm not able to access the Index page or
any of the jsps. Does the ApplicationServletBase always look forthe
viewbean in the same path as that of the module servlet?
Any help will be appreciated.
Thanks,
Chidu.
<a href="/group/SunONE-JATO/post?protectID=210083235237078198050118178206047166215146166214017110250006230056039126077176105140127082088124241215002153">[email protected]</a>
<a href="/group/SunONE-JATO/post?protectID=210083235237078198050118178206047166215146166214017110250006230056039126077176105140127082088124241215002153">[email protected]</a>
<a href="/group/SunONE-JATO/post?protectID=210083235237078198050118178206047166215146166214017110250006230056039126077176105140127082088124241215002153">[email protected]</a>

Hi Mike,
I tried changing the url in all the viewbeans to reflect the new sub-
directory for the viewbeans(I have placed the jsps and viewbeans in
a sub-directory under MigtoolboxSampleApp/MigtoolboxSample). But I'm
still not able to get access to the jsps. I basically see the
message "GX Error Socket Error Code missing!!" error on the browser
thrown by iPlanet, but the log doesn't tell me anything. Does the url
which I give to access the jsp change accordingly, i.e., should I
give something other
than /NASApp/MigtoolboxSampleAppWar/MigtoolboxSample/IndexPage.jsp.
If I try to use any other url other
than /NASApp/MigtoolboxSampleAppWar/MigtoolboxSample/IndexPage.jsp, I
see the FileNotFoundException in the log.
I guess I'm still missing something.
Thanks for your help.
--Chidu.
--- In iPlanet-JATO@y..., "Mike Frisino" <Michael.Frisino@S...> wrote:
>
Chidu.
Did you also adjust the following member in each of the ViewBeans?
public static final String DEFAULT_DISPLAY_URL=
"/jatosample/module1/Index.jsp";
Try adjusting this to be consistent with your new hierarchy.
Also, if you still have problems, send us the error message that you recieve
when you try to access the page. That would help.
----- Original Message -----
From: <chidusv@y...>
Sent: Thursday, July 26, 2001 4:48 PM
Subject: [iPlanet-JATO] Deployment problem
Hi,
We have a requirement to seperate the models and viewbeans and
keep
them in seperate directories. Is it possible to seperate the
viewbeans and models not be in the same directory?
I tried seperating the two in the MigtoolboxSampleApp application
provided by JATO. I changed the package and import statements
accordingly in the viewbeans, jsps and the models. But when I
deployed the application, I'm not able to access the Index page or
any of the jsps. Does the ApplicationServletBase always look for the
viewbean in the same path as that of the module servlet?
Any help will be appreciated.
Thanks,
Chidu.
[email protected]

Re: [iPlanet-JATO] jato classes serializable

Unless Todd, Mike, or Matt have slick answer to make it work, my only
solution would be to switch from using the objects themselves and
reference by name instead. I don't know exactly what your Utility class
is doing or how the fields use the Utility class, so I can not be
specific in what you should do.
I fear that I may be taking on too much work by asking, but maybe you
could send me the Utility class (send to me directly as Yahoo Groups
doesnot allow attachments: craig.conover@s...).
I'll take a quick glance at it. Maybe I can make some suggestions to
minimize your migration efforts.
craig
Seetharam, Prashanth wrote:
In ND, we had a utility class written whose member variables were visual
objects. This utility object is used to display or not display its elements
depending on user action. The utility object was being put into session.
It could have been implemented in a different way, by storing visual object
names instead of objects themselves. But when we migrated, we tried to keep
re-coding to the minimum and ended up replacing ND visual objects
withcorresponding jato visual objects and ran into this problem.
Since all the jato visual objects extend from DisplayFieldBase which inturn
extends from ViewBase, i started looking at ViewBase and did not understand
why the variable was made transient. Hence the question.
Thanks,
Prashanth Seetharam
-----Original Message-----
From:     Craig V. Conover [SMTP:<a href="/group/SunONE-JATO/post?protectID=219212113009229091025149066024064239039098031198039130252055210">craig.conover@s...</a>]
Sent:     Tuesday, December 11, 2001 2:43 PM
Subject:     Re: [iPlanet-JATO] jato classes serializable
What is your requirement that these be serializable?
The views do not store any values, that is what the model is for, and
they are created lazily as needed.
Is there something you were doing in ND that required it. It is very
likely that you do not need to do it anymore with JATO.
If you are using JATO1.0, you are highly encouraged to start using JATO
1.2. If you are using the iMT, it has an upgrade tool for 1.x to 1.2.
http://developer.iplanet.com/tech/appserver/framework/index.jsp
I'll leave the transient parentViewBean to Todd or Mike to justify. But,
again, what is the need for it to be serialized?
c
Seetharam, Prashanth wrote:
I am using jato1.0 and found that jato classes (especially the visual
objects like StaticTextField) are not serializable.
Is this change made in jato1.1? It will be good to have this feature as
ND
visual objects were serializable.
Also in com.iplanet.jato.view.ViewBase.java, why has this variable been
made
transient?
     private transient ViewBean parentViewBean;
Thanks,
Prashanth Seetharam
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp

Unless Todd, Mike, or Matt have slick answer to make it work, my only
solution would be to switch from using the objects themselves and
reference by name instead. I don't know exactly what your Utility class
is doing or how the fields use the Utility class, so I can not be
specific in what you should do.
I fear that I may be taking on too much work by asking, but maybe you
could send me the Utility class (send to me directly as Yahoo Groups
doesnot allow attachments: craig.conover@s...).
I'll take a quick glance at it. Maybe I can make some suggestions to
minimize your migration efforts.
craig
Seetharam, Prashanth wrote:
In ND, we had a utility class written whose member variables were visual
objects. This utility object is used to display or not display its elements
depending on user action. The utility object was being put into session.
It could have been implemented in a different way, by storing visual object
names instead of objects themselves. But when we migrated, we tried to keep
re-coding to the minimum and ended up replacing ND visual objects
withcorresponding jato visual objects and ran into this problem.
Since all the jato visual objects extend from DisplayFieldBase which inturn
extends from ViewBase, i started looking at ViewBase and did not understand
why the variable was made transient. Hence the question.
Thanks,
Prashanth Seetharam
-----Original Message-----
From:     Craig V. Conover [SMTP:<a href="/group/SunONE-JATO/post?protectID=219212113009229091025149066024064239039098031198039130252055210">craig.conover@s...</a>]
Sent:     Tuesday, December 11, 2001 2:43 PM
Subject:     Re: [iPlanet-JATO] jato classes serializable
What is your requirement that these be serializable?
The views do not store any values, that is what the model is for, and
they are created lazily as needed.
Is there something you were doing in ND that required it. It is very
likely that you do not need to do it anymore with JATO.
If you are using JATO1.0, you are highly encouraged to start using JATO
1.2. If you are using the iMT, it has an upgrade tool for 1.x to 1.2.
http://developer.iplanet.com/tech/appserver/framework/index.jsp
I'll leave the transient parentViewBean to Todd or Mike to justify. But,
again, what is the need for it to be serialized?
c
Seetharam, Prashanth wrote:
I am using jato1.0 and found that jato classes (especially the visual
objects like StaticTextField) are not serializable.
Is this change made in jato1.1? It will be good to have this feature as
ND
visual objects were serializable.
Also in com.iplanet.jato.view.ViewBase.java, why has this variable been
made
transient?
     private transient ViewBean parentViewBean;
Thanks,
Prashanth Seetharam
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp

Re: [iPlanet-JATO] .select()

Prashanth,
I assume you are trying to set the default values of the selectables.
Matt,
Actually, I believe this is a view type behavior because it is manipulating the
html properties upon preparing the object for display, however, currently it
appears there is no method for this. For now, you could get the raw html (in
the selectable fields end<fieldName>Display event) and manipulate the html
there. This is not the preferred way obviously, but after combing the API, I
don't see a direct way of doing this.
I'm sure Todd will chime eventually to clear it all up.
craig
----- Original Message -----
From: Matthew Stevens
Sent: Friday, January 12, 2001 11:32 AM
Subject: RE: [iPlanet-JATO] .select()
Prashanth,
I am new to the team here at sun, but I am experienced in ND. The ND spider
framework was not a model/view methodology. That is, the behavior normally
found in a model and view and controller are in the CSpSelectableGroup
object and its derived classes. I would suspect, although I learning the
iMT and JATO framework right now, that the equivalent behavior in JATO of
the
select()
method would be found in the MODEL; the VIEW would not have equivalent
behavior (e.g. jato.view.html.SelectableGroup
I don't know if that helps, but I am sure that the guys will respond.
matt
-----Original Message-----
From: Seetharam, Prashanth
[mailto:<a href="/group/SunONE-JATO/post?protectID=197212113112042031172057046036229239177230204009251079181045006199220253099030239126041013098158154163014176224">prashanth.seetharam@b...</a>]
Sent: Friday, January 12, 2001 2:14 PM
Subject: [iPlanet-JATO] .select()
In ND, we used to have the following functions for a CSpSelectableGroup
object like
public void select(int selectableIndex) throws
java.lang.IndexOutOfBoundsException
public boolean select(CSpValue value)
and different other versions of select.
How do we achieve the same in jato ..basically ..selecting an element in a
SelectableGroup object.
Thanks,
Prashanth Seetharam
[email protected]
eGroups Sponsor
[email protected]
[Non-text portions of this message have been removed]

Craig,
I see your point. I would think that model holds the value and the view
displays it and may control the model too. I would think that the
setter/getter of what's selected is part of the model. I don't know and I
am sure that after I go to bed Todd will clear it up.
matt
-----Original Message-----
From: Craig V Conover [mailto:<a href="/group/SunONE-JATO/post?protectID=219212113009229091025149066024064239039098031198039130252055210">craig.conover@s...</a>]
Sent: Friday, January 12, 2001 3:03 PM
Subject: Re: [iPlanet-JATO] .select()
Prashanth,
I assume you are trying to set the default values of the selectables.
Matt,
Actually, I believe this is a view type behavior because it is
manipulating the html properties upon preparing the object for
display, however, currently it appears there is no method for
this. For now, you could get the raw html (in the selectable
fields end<fieldName>Display event) and manipulate the html
there. This is not the preferred way obviously, but after combing
the API, I don't see a direct way of doing this.
I'm sure Todd will chime eventually to clear it all up.
craig
----- Original Message -----
From: Matthew Stevens
Sent: Friday, January 12, 2001 11:32 AM
Subject: RE: [iPlanet-JATO] .select()
Prashanth,
I am new to the team here at sun, but I am experienced in ND.
The ND spider
framework was not a model/view methodology. That is, the
behavior normally
found in a model and view and controller are in the CSpSelectableGroup
object and its derived classes. I would suspect, although I
learning the
iMT and JATO framework right now, that the equivalent behavior
in JATO of
the
select()
method would be found in the MODEL; the VIEW would not have equivalent
behavior (e.g. jato.view.html.SelectableGroup
I don't know if that helps, but I am sure that the guys will respond.
matt
-----Original Message-----
From: Seetharam, Prashanth
[mailto:<a href="/group/SunONE-JATO/post?protectID=197212113112042031172057046036229239177230204009251079181045006199220253099030239126041013098158154163014176224">prashanth.seetharam@b...</a>]
Sent: Friday, January 12, 2001 2:14 PM
Subject: [iPlanet-JATO] .select()
In ND, we used to have the following functions for aCSpSelectableGroup
object like
public void select(int selectableIndex) throws
java.lang.IndexOutOfBoundsException
public boolean select(CSpValue value)
and different other versions of select.
How do we achieve the same in jato ..basically ..selecting anelement in a
SelectableGroup object.
Thanks,
Prashanth Seetharam
[email protected]
eGroups Sponsor
[email protected]
[Non-text portions of this message have been removed]
[email protected]

Re: [iPlanet-JATO] Re: CSpMultiSQL after migration

Alex,
I just switched over to Netscape Messenger from OutLook and I didn't
realize that emails were displayed in threaded hierarchies and therefore
did not see that you had already had responses to your post. Sorry for
the confusion in my previous response.
matt
njdoe123 wrote:
Hi,
I have tested another simple MultiSQL. The Update, Delete, Insert
are not funcitonal. I'm using only one single database table (no
join). It worked great in netD. The database is Oracle.
We're using migtoolbox-1.1.1 with Jato 1.1. Do we have to modify
the UpdataQueryModel.java file or other ? Or could i use jato 1.2
to replace 1.1 ?
The following is log from AppServer. Could i receive the migtool
1.2 beta ?
Thanks,
Alex Lin
<Dec 21, 2001 11:18:36 AM PST> <Error> <HTTP> <[WebAppServletContext
(1572805,Tes
t3AppWar,/Test3AppWar)] Root cause of ServletException
com.iplanet.jato.model.ModelControlException
java.sql.SQLException: ORA-00933: SQL command not properly ended
at oracle.jdbc.dbaccess.DBError.throwSqlException
(DBError.java:168)
at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543)
at oracle.jdbc.ttc7.TTC7Protocol.doOall7
(TTC7Protocol.java:1405)
at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch
(TTC7Protocol.java:822
at oracle.jdbc.driver.OracleStatement.executeNonQuery
(OracleStatement.ja
va:1446)
at oracle.jdbc.driver.OracleStatement.doExecuteOther
(OracleStatement.jav
a:1371)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout
(OracleStateme
nt.java:1900)
at oracle.jdbc.driver.OracleStatement.executeUpdate
(OracleStatement.java
:693)
at com.iplanet.jato.model.sql.QueryModelBase.executeUpdate
(QueryModelBas
e.java:1788)
at com.iplanet.jato.model.sql.QueryModelBase.update
(QueryModelBase.java:
420)
at
com.iplanet.jato.view.RequestHandlingViewBase.executeAutoUpdatingMode
l(RequestHandlingViewBase.java:1070)
at
com.iplanet.jato.view.RequestHandlingViewBase.executeAutoUpdatingMode
ls(RequestHandlingViewBase.java:938)
at
com.iplanet.jato.view.RequestHandlingViewBase.handleWebAction(Request
HandlingViewBase.java:821)
at Test3App.Test3.PgUpdateViewBean.handleUpdateRequest
(PgUpdateViewBean.
java:838)
at java.lang.reflect.Method.invoke(Native Method)
at com.iplanet.jato.view.RequestHandlingViewBase.handleRequest
(RequestHa
ndlingViewBase.java:341)
at
com.iplanet.jato.view.ViewBeanBase.invokeRequestHandlerInternal(ViewB
eanBase.java:481)
at com.iplanet.jato.view.ViewBeanBase.invokeRequestHandler
(ViewBeanBase.
java:431)
at com.iplanet.jato.ApplicationServletBase.dispatchRequest
(ApplicationSe
rvletBase.java:645)
at com.iplanet.jato.ApplicationServletBase.processRequest
(ApplicationSer
vletBase.java:431)
at com.iplanet.jato.ApplicationServletBase.doPost
(ApplicationServletBase
.java:296)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet
(ServletStubIm
pl.java:265)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet
(ServletStubIm
pl.java:200)
at
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppSe
rvletContext.java:2456)
at weblogic.servlet.internal.ServletRequestImpl.execute
(ServletRequestIm
pl.java:2039)
at weblogic.kernel.ExecuteThread.execute
(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run
(ExecuteThread.java:120)
--- In iPlanet-JATO@y..., "Matthew Stevens" <matthew.stevens@E...>
wrote:
EDITED
-----Original Message-----
From: Matthew Stevens [mailto:<a href="/group/SunONE-JATO/post?protectID=029166114165042198028082000056130080177026031196061130152150">matthew.stevens@e...</a>]
Sent: Thursday, December 20, 2001 4:32 PM
Alex,
If your implied question is, "Looks like the iMT did not migrate
this block
of code. What is my next step?" Then I have an answer for you. If
I
misinterpreted your email then please clarify.
The procedure for ND migration using the iMT (as outlined in the
documentation
under <iMT_install_dir>/docs) is that customized code originally
provided by
the ND developer is purposely commented out so that the file can
compile.
Our experience in migration efforts shows that it is preferrable to
the
migrator to be able to select which part of the application they
want to
work
on by uncommenting specific blocks of code - allowing for
incremental
edit/compile/test cycles. If we left all this arbitary code un-
commented,
then nothing would compile after migration and you would have a huge
roadblock for moving forward.
Judging from the "spider" APIs which are still seen in your code
block, you
must not have run the Regular Expression API mapping tool which
will take
care of many of this code. I believe that the API mapper will
migrate this
block of code almost 100% and you just need to uncomment it.
matt
-----Original Message-----
From: njdoe123 [mailto:<a href="/group/SunONE-JATO/post?protectID=230176091112175091130232203140129208071">first.us@a...</a>]
Sent: Thursday, December 20, 2001 4:04 PM
Subject: [iPlanet-JATO] Re: CSpMultiSQL after migration
Oops !
The following (very simple) customized code was not migrated.
In business logic - after update, goto another page.
My backend database is Oracle.
Thanks.
Alex Lin
-------------------------+
// The following code block was migrated from the Update_onWebEvent
method
// MigrationToDo : THIS CODE MUST BE MANUALLY ADJUSTED
int command = PROCEED;
CSpPage nextPage =(CSpPage) CSpider.getPage("PgDistrict");
executeAllUpdatingDataObjects();
return nextPage.load();
--- In iPlanet-JATO@y..., "Craig V. Conover" <craig.conover@s...>
wrote:
Alex,
CSpMultiSQL migrate just fine. You may have had to do something
extraordinary for your
particular database in your select statement.
Can we see the entire exception stack trace, and the code that is
executing the model?
Also, what database are you hitting?
c
njdoe123 wrote:
Hi,
It's a bit strange while doing CSpMultiSQL (select and update).
I have received the following error on the AppServer.
Web event invoked: Test3App.Test3.PgWebUserViewBean.Update
<Dec 19, 2001 2:20:05 PM PST> <Error> <HTTP>
<[WebAppServletContext(168087,Test3
AppWar,/Test3AppWar)] Root cause of ServletException
com.iplanet.jato.model.ModelControlException
java.sql.SQLException: ORA-00933: SQL command not properly ended
'SQL command not properly ended ?' - i haven't touched the sql
code,
it's just simple select and update to one table.
Could iMT do MultiSQL ? If not, what is the solution after
migration
Thanks,
Alex Lin
For more information about JATO, including download information,
please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
For more information about JATO, including download information,
please
visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
For more information about JATO, including download information,
please
visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
For more information about JATO, including download information, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp

Thank you - Jin and Todd.
Will try that.
Atul
--- In iPlanet-JATO@y..., Byung Jin Chun <bchun@n...> wrote:
try using kregedit and modify the key for the jvm args, using the -x
parameters for the 1.2 runtime
Jin
-----Original Message-----
From: Todd Fast [mailto:<a href="/group/SunONE-JATO/post?protectID=101233080150035167169232031248066208071048">Todd.Fast@S...</a>]
Sent: Tuesday, February 19, 2002 8:40 PM
Subject: Re: [iPlanet-JATO] Re: OutOfMemoryError
Atul--
Out of curiosity - How do you modify the memory parameters for
the container's VM ?? I know I should try to do some research but
figured you may already have some insight and willingness to
share.
Please consider this as low priority.It differs by container; I don't remember details of any particular one.
>
Todd
For more information about JATO, including download information, please
visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
<http://developer.iplanet.com/tech/appserver/framework/index.jsp>
[Non-text portions of this message have been removed]

Re: [iPlanet-JATO] sp3 jsp compiler problem

Weiguo,
First, Matt is correct, the regular expression tool is perfect for general text
substitution situations, and as a completely independent tool its use is not
restricted to migration situations (or file types for that matter).
Second, I sympathize with the unfortunate trouble you are experiencing due to
Jasper's (perhaps more strict) compilation, but in what way did the iMT
automated translation contribute to these inconsistencies that you cited?
1. Changed the case of the tag attribute to be the same as what's
defined in tld.
example: changed OnClick to onClick
The iMT does not generate any OnClick or onClick clauses per se. In a
translation situation, the only way "OnClick" would have been introduced was if
it had been part of the pre-existing project's "extraHTML" (which was written
by the original customer and just passed through unchanged by the iMT) or if it
was added manually by the post-migration developer.
2. Removed attributes which are not defined in tld.
example: escape attribute only defined in three tags
but in some pages, it's used although it's not defined as an
attribute
of certain tags. The jasper compiler doesn't like it.Can you give soem examples? Is there a definite pattern? Again, this might be
similar to the OnClick situation described above?
3. In an end tag, there can't be any space.
example: </content > doesn't work. </content> works.
Again, the content tag would never have been generated by the iMT. There was no
equivalent in the NetDynamics world, so any content tags in your code must have
been introduced by your developers manually. Its a shame that jasper is so
particular, but the iMT could not help you out here even if we wanted to. The
constants that are used by the iMT are defined in
com.iplanet.moko.jsp.convert.JspConversionConstants. From what I can see, the
only situation of a closing tag with any space in it is
public static final String CLOSE_EMPTY_ELEMENT = " />";
But that should not cause the type of problem you are referring to.
Mike
----- Original Message -----
From: Matthew Stevens
Sent: Thursday, September 06, 2001 10:16 AM
Subject: RE: [iPlanet-JATO] sp3 jsp compiler problem
Weiguo,
Others will chime in for sure...I would highly recommend the Regex Tool from
the iMT 1.1.1 for tackling this type of problem. Mike, Todd and myself have
posted to the group (even recently) on directions and advantages of creating
your own RULES (rules file) in XML for arbitary batch processing of source.
matt
-----Original Message-----
From: weiguo.wang@b...
[mailto:<a href="/group/SunONE-JATO/post?protectID=125056020108194190033029175101192165174144234026000079108238073194105057099246073154180137239239223019162">weiguo.wang@b...</a>]
Sent: Thursday, September 06, 2001 12:25 PM
Subject: [iPlanet-JATO] sp3 jsp compiler problem
Matt/Mike/Todd,
We are trying to migrate to sp3 right now, but have had a lot of
issues with the new jasper compiler.
The following workaround has been employed to solve the issues:
1. Changed the case of the tag attribute to be the same as what's
defined in tld.
example: changed OnClick to onClick
2. Removed attributes which are not defined in tld.
example: escape attribute only defined in three tags
but in some pages, it's used although it's not defined as an
attribute
of certain tags. The jasper compiler doesn't like it.
3. In an end tag, there can't be any space.
example: </content > doesn't work. </content> works.
As I see it, we have two options to go about solving this problem:
1. Write a script which will iterate through all the jsp files and
call jspc on them. Fix the errors manually when jspc fails. Jspc will
flag the line number where an error occurs.
2. Write a utility which scans the jsp files and fix the errors when
they are encountered. We should define what's an error and how to
correct it. It's best if we combine this with solution 1 since we
might miss an error condition.
Actually, there might be another option, which is seeking help from
you guys since you have better understanding of JATO and iAS. Can you
do anything to help us?
We would be happy to hear your thoughts.
At last, I would like to suggest modifying the moko tool so that
these rules are enforced and the generated JSPs work with the new
compiler. This is for the benefit of any new migration projects.
Thanks a lot.
Weiguo
[email protected]
Choose from 1000s of job listings!
[email protected]
[Non-text portions of this message have been removed]

Thanks a lot Matt and Mike for your prompt replies.
I agree completely that iMT doesn't introduce the inconsistencies.
About the three cases I mentioned, the third one happens only in
manually created JSPs. So it has nothing to do with iMT. The first
two are mainly due to the existing HTML code, as you rightly pointed
out.
The reason I made the suggestion is since we know that case 1 and 2
won't pass the japser compiler in sp3, we have to do something about
it. The best place to do this, in my mind, is iMT. Of course, there
might be some twists that make it impossible or difficult to do this
kind of case manipulation or attribute discard.
Weiguo
--- In iPlanet-JATO@y..., "Mike Frisino" <Michael.Frisino@S...> wrote:
Weiguo,
First, Matt is correct, the regular expression tool is perfect for general text substitution situations, and as a completely independent
tool its use is not restricted to migration situations (or file types
for that matter).
>
Second, I sympathize with the unfortunate trouble you are experiencing due to Jasper's (perhaps more strict) compilation, but
in what way did the iMT automated translation contribute to these
inconsistencies that you cited?
>
1. Changed the case of the tag attribute to be the same as what's
defined in tld.
example: changed OnClick to onClick
The iMT does not generate any OnClick or onClick clauses per se. In a translation situation, the only way "OnClick" would have been
introduced was if it had been part of the pre-existing
project's "extraHTML" (which was written by the original customer and
just passed through unchanged by the iMT) or if it was added manually
by the post-migration developer.
>
2. Removed attributes which are not defined in tld.
example: escape attribute only defined in three tags
but in some pages, it's used although it's not defined as an
attribute
of certain tags. The jasper compiler doesn't like it.Can you give soem examples? Is there a definite pattern? Again, this might be similar to the OnClick situation described above?
>
>
3. In an end tag, there can't be any space.
example: </content > doesn't work. </content> works.
Again, the content tag would never have been generated by the iMT. There was no equivalent in the NetDynamics world, so any content tags
in your code must have been introduced by your developers manually.
Its a shame that jasper is so particular, but the iMT could not help
you out here even if we wanted to. The constants that are used by the
iMT are defined in
com.iplanet.moko.jsp.convert.JspConversionConstants. From what I can
see, the only situation of a closing tag with any space in it is
public static final String CLOSE_EMPTY_ELEMENT = " />";
But that should not cause the type of problem you are referring to.
Mike
----- Original Message -----
From: Matthew Stevens
Sent: Thursday, September 06, 2001 10:16 AM
Subject: RE: [iPlanet-JATO] sp3 jsp compiler problem
Weiguo,
Others will chime in for sure...I would highly recommend the Regex Tool from
the iMT 1.1.1 for tackling this type of problem. Mike, Todd and myself have
posted to the group (even recently) on directions and advantages of creating
your own RULES (rules file) in XML for arbitary batch processing of source.
>
matt
-----Original Message-----
From: weiguo.wang@b...
[mailto:<a href="/group/SunONE-JATO/post?protectID=125056020108194190033029175101192165174048139046">weiguo.wang@b...</a>]
Sent: Thursday, September 06, 2001 12:25 PM
Subject: [iPlanet-JATO] sp3 jsp compiler problem
Matt/Mike/Todd,
We are trying to migrate to sp3 right now, but have had a lot of
issues with the new jasper compiler.
The following workaround has been employed to solve the issues:
1. Changed the case of the tag attribute to be the same as
what's
defined in tld.
example: changed OnClick to onClick
2. Removed attributes which are not defined in tld.
example: escape attribute only defined in three tags
but in some pages, it's used although it's not defined as an
attribute
of certain tags. The jasper compiler doesn't like it.
3. In an end tag, there can't be any space.
example: </content > doesn't work. </content> works.
As I see it, we have two options to go about solving this problem:
>>
1. Write a script which will iterate through all the jsp files and
call jspc on them. Fix the errors manually when jspc fails. Jspc will
flag the line number where an error occurs.
2. Write a utility which scans the jsp files and fix the errors when
they are encountered. We should define what's an error and how to
correct it. It's best if we combine this with solution 1 since we
might miss an error condition.
Actually, there might be another option, which is seeking help from
you guys since you have better understanding of JATO and iAS. Can you
do anything to help us?
We would be happy to hear your thoughts.
At last, I would like to suggest modifying the moko tool so that
these rules are enforced and the generated JSPs work with the new
compiler. This is for the benefit of any new migration projects.
Thanks a lot.
Weiguo
[email protected]
Choose from 1000s of job listings!
[email protected]
Service.
>
>
>
[Non-text portions of this message have been removed]

Error : com.iplanet.jato.model.ModelControlException: Location is beyond th

Hi..All,
I have a Page displayed with few values & one of them is of HREF type.The Model gets populated & I am able to view the data. When I click on the HREF value, I get an error :com.iplanet.jato.model.ModelControlException: Location is beyond the end of the current bean array (0 > -1)I tried setting the Bean Scope to "Any", "Request" , but it still gives me this error. The sys out in the constructor shows 0 for the size when the request comes in for the second time.
Here is the JSP :
package accruals.main;
import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
import com.iplanet.jato.*;
import com.iplanet.jato.command.*;
import com.iplanet.jato.model.*;
import com.iplanet.jato.view.*;
import com.iplanet.jato.view.event.*;
import javax.naming.*;
import javax.rmi.PortableRemoteObject;
import AccrualsEJB.*;
public class TaxPackUserAccessView extends BasicTiledView {
* Default constructor
public TaxPackUserAccessView(View parent, String name) {
super(parent,name);
// setMaxDisplayTiles(5);
System.out.println("The Model Name in the init before is : " +getPrimaryModel().getName());
try {
System.out.println("The model size in the init is : " + getPrimaryModel().getSize());
} catch (Exception e) {System.out.println("Error in init " + e);}
// Non-visual component initialization
private com.iplanet.jato.model.SimpleModelReference taxPackUserAccess;
* Creates the non-visual components
* <p><em>WARNING:</em> This code was automatically generated, do not edit!
private void initComponents(){
taxPackUserAccess = new com.iplanet.jato.model.SimpleModelReference();
{ // begin local variable scope
taxPackUserAccess.setModelClassName("accruals.main.TaxPackUserAccess");
} // end local variable scope
// Instance initializer - non-visual components
initComponents();
// Instance initializer - set properties
this.setPrimaryModelReference(taxPackUserAccess);
com.iplanet.jato.model.ModelReference[] autoRetrievingModelsVar =
new com.iplanet.jato.model.ModelReference[0];
this.setAutoRetrievingModels(autoRetrievingModelsVar);
this.setMaxDisplayTiles(100);
* Registers each child in this container.
* <p><em>WARNING:</em> This code was automatically generated, do not edit!
private void registerChildren() {
registerChild(CHILD_EMP_NO, com.iplanet.jato.view.BasicDisplayField.class);
registerChild(CHILD_NAME, com.iplanet.jato.view.BasicDisplayField.class);
registerChild(CHILD_ADMIN, com.iplanet.jato.view.BasicDisplayField.class);
registerChild(CHILD_SUPER_USER, com.iplanet.jato.view.BasicDisplayField.class);
registerChild(CHILD_EMP_NO_SUMMARY, com.iplanet.jato.view.BasicCommandField.class);
// Instance initializer - register children
registerChildren();
* Creates the named child.
* <p><em>WARNING:</em> This code was automatically generated, do not edit!
protected View createChildReserved(String name) {
if (name.equals(CHILD_EMP_NO)) {
com.iplanet.jato.view.BasicDisplayField child =
new com.iplanet.jato.view.BasicDisplayField(this, CHILD_EMP_NO);
child.setModelReference(taxPackUserAccess);
com.iplanet.jato.model.ModelFieldBinding modelFieldBindingVar =
new com.iplanet.jato.model.ModelFieldBinding();
{ // begin local variable scope
modelFieldBindingVar.setReadFieldName("empNo");
modelFieldBindingVar.setWriteFieldName("empNo");
} // end local variable scope
child.setModelFieldBinding(modelFieldBindingVar);
child.setValue( "");
return child;
else if (name.equals(CHILD_NAME)) {
com.iplanet.jato.view.BasicDisplayField child =
new com.iplanet.jato.view.BasicDisplayField(this, CHILD_NAME);
child.setModelReference(taxPackUserAccess);
com.iplanet.jato.model.ModelFieldBinding modelFieldBindingVar =
new com.iplanet.jato.model.ModelFieldBinding();
{ // begin local variable scope
modelFieldBindingVar.setReadFieldName("name");
modelFieldBindingVar.setWriteFieldName("name");
} // end local variable scope
child.setModelFieldBinding(modelFieldBindingVar);
child.setValue( "");
return child;
else if (name.equals(CHILD_ADMIN)) {
com.iplanet.jato.view.BasicDisplayField child =
new com.iplanet.jato.view.BasicDisplayField(this, CHILD_ADMIN);
child.setModelReference(taxPackUserAccess);
com.iplanet.jato.model.ModelFieldBinding modelFieldBindingVar =
new com.iplanet.jato.model.ModelFieldBinding();
{ // begin local variable scope
modelFieldBindingVar.setReadFieldName("admin");
modelFieldBindingVar.setWriteFieldName("admin");
} // end local variable scope
child.setModelFieldBinding(modelFieldBindingVar);
child.setValue( "1");
return child;
else if (name.equals(CHILD_SUPER_USER)) {
com.iplanet.jato.view.BasicDisplayField child =
new com.iplanet.jato.view.BasicDisplayField(this, CHILD_SUPER_USER);
child.setModelReference(taxPackUserAccess);
com.iplanet.jato.model.ModelFieldBinding modelFieldBindingVar =
new com.iplanet.jato.model.ModelFieldBinding();
{ // begin local variable scope
modelFieldBindingVar.setReadFieldName("superUser");
modelFieldBindingVar.setWriteFieldName("superUser");
} // end local variable scope
child.setModelFieldBinding(modelFieldBindingVar);
child.setValue( "1");
return child;
else if (name.equals(CHILD_EMP_NO_SUMMARY)) {
com.iplanet.jato.view.BasicCommandField child =
new com.iplanet.jato.view.BasicCommandField(this, CHILD_EMP_NO_SUMMARY);
child.setModelReference(taxPackUserAccess);
com.iplanet.jato.model.ModelFieldBinding modelFieldBindingVar =
new com.iplanet.jato.model.ModelFieldBinding();
{ // begin local variable scope
modelFieldBindingVar.setReadFieldName("empNo");
modelFieldBindingVar.setWriteFieldName("empNo");
} // end local variable scope
child.setModelFieldBinding(modelFieldBindingVar);
return child;
return super.createChildReserved(name);
/** Returns the <code>empNo</code> child View component */
public com.iplanet.jato.view.BasicDisplayField getEmpNoChild() {
return (com.iplanet.jato.view.BasicDisplayField)getChild(CHILD_EMP_NO);
/** Returns the <code>name</code> child View component */
public com.iplanet.jato.view.BasicDisplayField getNameChild() {
return (com.iplanet.jato.view.BasicDisplayField)getChild(CHILD_NAME);
/** Returns the <code>admin</code> child View component */
public com.iplanet.jato.view.BasicDisplayField getAdminChild() {
return (com.iplanet.jato.view.BasicDisplayField)getChild(CHILD_ADMIN);
/** Returns the <code>superUser</code> child View component */
public com.iplanet.jato.view.BasicDisplayField getSuperUserChild() {
return (com.iplanet.jato.view.BasicDisplayField)getChild(CHILD_SUPER_USER);
/** Returns the <code>empNoSummary</code> child View component */
public com.iplanet.jato.view.BasicCommandField getEmpNoSummaryChild() {
return (com.iplanet.jato.view.BasicCommandField)getChild(CHILD_EMP_NO_SUMMARY);
public static final String CHILD_EMP_NO = "empNo";
public static final String CHILD_NAME = "name";
public static final String CHILD_ADMIN = "admin";
public static final String CHILD_SUPER_USER = "superUser";
public static final String CHILD_EMP_NO_SUMMARY = "empNoSummary";
public void handleEmpNoSummaryRequest(RequestInvocationEvent event) throws Exception {
System.out.println("The Model Name is : " +getPrimaryModel().getName());
setPrimaryModel((DatasetModel)getDefaultModel());
System.out.println("In Because of the link :" +((TiledViewRequestInvocationEvent)event).getTileNumber());
System.out.println("The Model Name is : + " +getPrimaryModel().getName());
System.out.println("The model size is from the request : " + getPrimaryModel().getSize());
getPrimaryModel().setLocation(((TiledViewRequestInvocationEvent)event).getTileNumber());
System.out.println("the value of the clicked field was :" + getDisplayFieldStringValue(CHILD_EMP_NO));
System.out.println("From the value:"+ getEmpNoChild().getValue());
getParentViewBean().forwardTo(getRequestContext());
public void beginComponentDisplay(DisplayEvent event) throws ModelControlException {
TaxPackUserDATA tpackDATA =null;
AccrualsSessionHome myAccrualsSessionHome;
String userID;
Object result;
try {
System.out.println("Before the create");
Context c = new InitialContext();
System.out.println("after the intial context");
result = c.lookup("ejb/AccrualsSession");
System.out.println("The class name :" +result.getClass().getName());
System.out.println("after the lookup");
myAccrualsSessionHome = (AccrualsSessionHome)PortableRemoteObject.narrow(result,AccrualsSessionHome.class);
System.out.println("after narrow down");
AccrualsSession asb = myAccrualsSessionHome.create();
System.out.println("after the create");
tpackDATA = asb.validateUser("111351");
System.out.println("The user is " + tpackDATA.getEmpNo());
System.out.println("The Name id is " + tpackDATA.getName());
System.out.println("The admin is " + tpackDATA.getAdmin());
System.out.println("The superUser is " + tpackDATA.getSuperUser());
} catch (Exception e) {
System.out.println("Error during Validate User Login in AccrualsLoginServlet" + e);
System.out.println("Inside AccrualsLoginViewBean beginComponentDisplay");
BeanAdapterModel model = (TaxPackUserAccess) getRequestContext().getModelManager().getModel(TaxPackUserAccess.class);
System.out.println("After creating the model" + getPrimaryModel().getName());
getRequestContext().getRequest().setAttribute(model.getBeanScopeAttributeName(), tpackDATA);
System.out.println("Leaving AccrualsLoginViewBean beginComponentDisplay");
System.out.println("The model size is : " + model.getSize());
// getPrimaryModel().setSize(1);
// resetTileIndex();
// super.beginComponentDisplay(event);
}

You are using BeanAdapterModel. Unless you've elected to place your BeanAdapterModel instance in the session, it is request-scoped like all JATO objects. This means that on the second request, a new model is created, and unless you set the list of beans on the model, it has no beans on which to set the incoming data.
An easy place to set the list of beans is in the constructor of the model. If, however, the beans are in one of the J2EE scopes (either already, or because you elected to put them there sometime earlier in your request handling), then you can use the model's ability to look up the beans in that scope by adjusting the Bean Scope and Bean Scope Attribute properties.

Re: [iPlanet-JATO] Re: Retrieving all Values from a Tiled View

Todd,
Let me try to explain you this time. I have a text field in a TiledViewBean.
When I display the page, the text field
html tag is created with the name="PageDetail.rDetail[0].tbFieldName" say
five times/rows with same name.
The html tags look like this.
<input type=text name="PageDetail.rDetail[0].tbFieldName" value=""
maxlength=9 size=13>
<input type=text name="PageDetail.rDetail[0].tbFieldName" value=""
maxlength=9 size=13>
<input type=text name="PageDetail.rDetail[0].tbFieldName" value=""
maxlength=9 size=13>
When the form is submitted, I want to get the text field values using the
method getTbFieldName().getValues() which
returns an array object[]. This is in case where my TiledViewBean is not
bound and it is working fine.
Now in case when my TiledView is bound to a model, it creates the html tags
as follows.
<input type=text name="PageDetail.rDetail[0].tbFieldName" value=""
maxlength=9 size=13>
<input type=text name="PageDetail.rDetail[1].tbFieldName" value=""
maxlength=9 size=13>
<input type=text name="PageDetail.rDetail[2].tbFieldName" value=""
maxlength=9 size=13>
Now when I say getTbFieldName().getValues() it returns only the first
element values in the object[] and the rest of the
values are null.
May be we need to create a utility method do get these values from
requestContext.
raju.
----- Original Message -----
From: Todd Fast <toddwork@c...>
Sent: Saturday, July 07, 2001 3:52 AM
Subject: Re: [iPlanet-JATO] Re: Retrieving all Values from a Tiled View
Raju.--
I wanted to know how the getValues() method works the reason being,
when the tiled view is NOT bound to a model, it populates all the
fields with the same name as some thing likeI'm afraid I don't understand your point--can you please clarify? Do you
mean "value" instead of "name"?
What are you trying to do? What behavior are you expecting but notseeing?
>
Without further clarification, I can say that the setValues() methodsNEVER
populates data on multiple rows of a (dataset) model, nor does it affect
multiple fields on the same row. Perhaps what you are seeing is theeffect
of default values. Model that derive from DefaulModel have the ability to
carry forward the values set on the first row to other rows in lieu ofdata
in those other rows. This behavior is for pure convenience and can be
turned off, and it is turned off for the SQL-based models.
Todd
[email protected]

Hi,
I wanted to know how the getValues() method works the reason being,
when the tiled view is NOT bound to a model, it populates all the
fields with the same name as some thing like
PageDetail.rDetail[0].tbFieldValue
PageDetail.rDetail[0].tbFieldValue
in which case, the getValues() method works fine.
But in case where the tiled view is bound to a model, it populates
with different field names such as,
PageDetail.rDetail[0].tbFieldValue
PageDetail.rDetail[1].tbFieldValue
in this case, the getValues() doesn't work. Any soultion to this?
We are using Moko 1.1.1.
thanks in advance,
raju.
--- In iPlanet-JATO@y..., "Todd Fast" <toddwork@c...> wrote:
Does anyone know of is there a single method to get all values of a
display
field in a tiled view without having to iterate through all the
values ie
resetTileIndex() / nextTile() approach.
ie Something that returns an Object[] or Vector just like ND returned a
CspVector. I tried using the getValues() methods but that allways returns
a
single element array containing the first element.
(I think now, that method is used for multi selecteable ListBoxes)Actually, no. We can add this in the next patch, but for now, I'd recommend
creating a simple utility method to do the iteration on an arbitrary model
and build the list for you.
Todd

Re: [iPlanet-JATO] Retrieving all Values from a Tiled View

Does anyone know of is there a single method to get all values of adisplay
field in a tiled view without having to iterate through all the values ie
resetTileIndex() / nextTile() approach.
ie Something that returns an Object[] or Vector just like ND returned a
CspVector. I tried using the getValues() methods but that allways returnsa
single element array containing the first element.
(I think now, that method is used for multi selecteable ListBoxes)Actually, no. We can add this in the next patch, but for now, I'd recommend
creating a simple utility method to do the iteration on an arbitrary model
and build the list for you.
Todd

Hi,
I wanted to know how the getValues() method works the reason being,
when the tiled view is NOT bound to a model, it populates all the
fields with the same name as some thing like
PageDetail.rDetail[0].tbFieldValue
PageDetail.rDetail[0].tbFieldValue
in which case, the getValues() method works fine.
But in case where the tiled view is bound to a model, it populates
with different field names such as,
PageDetail.rDetail[0].tbFieldValue
PageDetail.rDetail[1].tbFieldValue
in this case, the getValues() doesn't work. Any soultion to this?
We are using Moko 1.1.1.
thanks in advance,
raju.
--- In iPlanet-JATO@y..., "Todd Fast" <toddwork@c...> wrote:
Does anyone know of is there a single method to get all values of a
display
field in a tiled view without having to iterate through all the
values ie
resetTileIndex() / nextTile() approach.
ie Something that returns an Object[] or Vector just like ND returned a
CspVector. I tried using the getValues() methods but that allways returns
a
single element array containing the first element.
(I think now, that method is used for multi selecteable ListBoxes)Actually, no. We can add this in the next patch, but for now, I'd recommend
creating a simple utility method to do the iteration on an arbitrary model
and build the list for you.
Todd

Re: [iPlanet-JATO] Sorting a resultset

Steve,
Todd will probably address this more, but to set the stage for the discussion,
I will chime in. As per your scenario "say a user wants to resort the results
by some other column" , I think there needs to be some clarification on the
life cycle of the model. You scenario implies that the user sees the data and
then submits a request to sort the data. This implies that the access to the
same data is spread across two HTTP requests.
Unless explicitly or implicitly stored in session, the Model is a per request
object. Therefore, under ordinary circumstances a new instance of Model is
constructed per request and populated as needed. This is done for scalability
reasons. Most applications would not scale properly if all model instances were
kept around in session per user. There is also the issue of data integrity, a
model stored in session may not reflect the current state of the RDBMS from
which the data was previously retrieved, perhaps minutes before. So, the
default action is to instantiate a new model and repopulate that model The
normal solution would be to apply the sort criteria to the data retrieval at
that point.
What I described above is the norm and the default.
If you have compelling reasons to prefer a single retrieval style, you have to
be prepared to store the Model data in session. There are several methods
within the ModelManager class which assist in this regard. You can see them
described in the java doc.
Also bear in mind that the SQLModelBase typically copies the data from the JDBC
result set into JATO specific local storage. This is done because the JDBC
result set is not as flexible as developer needs and requires the JDBC
connection to remain open while it is used.
I suspect that Todd will describe how you can manipulate the underlying JATO
specific local storage to change the order. I just wanted to make sure you
understood the life cycle issues involved and had justification for deviating
from the default.
Also, I'm still waiting for followup on the defaultCommandChild issue - we'd
like to fix it for JATO 1.2.1 if it is a problem and so far your case is the
only one we have heard of.
----- Original Message -----
From: stephen_winer
Sent: Wednesday, December 12, 2001 9:42 AM
Subject: [iPlanet-JATO] Sorting a resultset
If I want to sort a result set (Model) after the search has taken
place (say a user wants to resort the results by some other column),
can this be done without issuing another query? The reason I ask is
that the next() method in the ResultSetModelBase calls synchronizeRow
(), which resets the row, which sounds like a sort done outside of
the SQL would be reverted.
Steve
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
[Non-text portions of this message have been removed]

The hidden field was present in the page, but it looked like this:
<input type="hidden" name="jato.defaultCommand" value=""../search"">
Seems like there is a small bug in the code generating this tag.
FYI - I am using JATO1.2
What file displays this text? Maybe I can go in and fix it and rejar
it.
Steve
--- Mike Frisino wrote:
Steve,
Can you check the HTML source that shows up in the browser? Do you see an entry that looks like this at the bottom of the form in
question?
>
<input type="hidden" name="jato.defaultCommand" value="/search">
To answer your question - it should work as you described. Some of the JatoSample make use of the defaultCommandChild. Can you try
running the sample BasicSample->Field Types and let us know what you
see.
>
Failing this you can send me your jsp file , maybe there is some subtle issue there. michael.frisino@s...
>
>
----- Original Message -----
From: stephen_winer
Sent: Friday, December 07, 2001 8:05 AM
Subject: [iPlanet-JATO] Using the defaultCommandChild in a form
I am trying to set the defaultCommandChild in my jato:form tag to be
the searcg button. The search button definition is:
<jato:button name="search"/>.
The form tag definition is:
<jato:form name="PendingIA" defaultCommandChild="/search">
Clicking on the search button works fine, but hitting return in one
of the textFields (which submits the form) passes a value of "" to
the createChild method in my viewBean, which throws an error. Why
does this not just work as normal and trigger the handleSearchRequest
() method?
Steve
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
Service.
>
>
>
[Non-text portions of this message have been removed]

Re: [iPlanet-JATO] onBeforeRequest(); Finding requested view from requestContext

The problem is that you don't know what the target view is until it has
been forwarded to.
Think about it... the request handling view bean (or command object) has
the request handler that has the code that will ultimately forward to
another view bean. This is code that you have written. So, until that
forwardTo() is invoked, there is no notion of a "target page".
What you do know is which "page" (view bean) the request is coming from
(the handling view bean or command class). You can get this from the
HttpServletRequest. The attribute name is "viewBean".
So you can get the view bean name by doing the following in onBeforeRequest:
<HttpServletRequest>.getAttribute("viewBean");
But I suspect this is not going to solve your current issue.
You could add the target page name to the page session. If there is more
than one possible target page, it might get a little more involved.
Let me know if the use of page session needs further explanation.
c
nickmalthus wrote:
I am implementing a custom security model since the standard J2EE
security model does not allow me access to the users password, which I
need to log into a third party application. I have overriden the
onBeforeRequest() method to check to see if the user is logged in, and
if not, forward to the Login ViewBean. However, I need to determine
what page/viewbean the request is attempting to access so I can let it
pass through if it is accessing the Login viewbean and to forward to
the requested view once the user is logged in. What is the best way to
do this? I see no obvious uitility in the javadocs
TIA
For more information about JATO, including download information, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp

I guess what I am thinking about doing is capturing the requested URL,
i.e. /appname/modulename/RequestName. In the onBeforeRequest(). I
would then check to see if the user is logged in, and if not, set the
URL in the session(or page session of the Login bean) and forward to
the Login viewbean using the viewbean manager. Inside the login view
in the handleSubmit() method I would authenticate the user and then
get the URL out of the session (or pagesession). I would then
magically get the ViewBean/Command object for the URL or otherwise
"forward the request" as if the user had typed in
/appname/modulename/RequestName, which is the behavior I am trying to
acheive.
It turns out I cannot forward in the onBeforeRequest() as it will
output the viewbean and then continue to process the request which in
turn trys to do a RequestDispatcher().forward after data has been
written to the stream which does not bode well with the servlet
container. Thus, it appears I have no control of the request in the
onBeforeRequest() method. Is this correct?
In light of this new observation I am now going to create a base view
class that all views will extend from and override the
onSecurityCheck() method to forward to my login bean. If I can't find
any other way, I will get the URL from the page session and do a
response.sendRedirect() to the URL.
Thanks for the help!
--- In iPlanet-JATO@y..., "Craig V. Conover" <craig.conover@s...> wrote:
The problem is that you don't know what the target view is until it has
been forwarded to.
Think about it... the request handling view bean (or command object)has
the request handler that has the code that will ultimately forward to
another view bean. This is code that you have written. So, until that
forwardTo() is invoked, there is no notion of a "target page".
What you do know is which "page" (view bean) the request is coming from
(the handling view bean or command class). You can get this from the
HttpServletRequest. The attribute name is "viewBean".
So you can get the view bean name by doing the following inonBeforeRequest:
>
<HttpServletRequest>.getAttribute("viewBean");
But I suspect this is not going to solve your current issue.
You could add the target page name to the page session. If there ismore
than one possible target page, it might get a little more involved.
Let me know if the use of page session needs further explanation.
c

Re: [iPlanet-JATO] Re: onBeforeRequest(); Finding requested view from requestContext

If you want to stop a JATO request in its tracks, you have a little black
magic at your disposal: you can throw a CompleteRequestException. This
indicates to the JATO infrastructure that it should immeditately stop
handling the request, but not generate an error, as the develper has taken
full control. You can generally throw this error from anywhere, at any
point--it is a RuntimeException, and is "tunneled" through other exception
handlers where appropriate.
In your scenario, you want to check if the user is logged in, and if not,
save the target URL using the parsePathInfo() method. Then, forward to the
login page and then throw a CompleteRequestException.
Todd
----- Original Message -----
From: "nickmalthus" <nickmalthus@h...>
Sent: Monday, January 07, 2002 3:05 PM
Subject: [iPlanet-JATO] Re: onBeforeRequest(); Finding requested view from
requestContext
I guess what I am thinking about doing is capturing the requested URL,
i.e. /appname/modulename/RequestName. In the onBeforeRequest(). I
would then check to see if the user is logged in, and if not, set the
URL in the session(or page session of the Login bean) and forward to
the Login viewbean using the viewbean manager. Inside the login view
in the handleSubmit() method I would authenticate the user and then
get the URL out of the session (or pagesession). I would then
magically get the ViewBean/Command object for the URL or otherwise
"forward the request" as if the user had typed in
/appname/modulename/RequestName, which is the behavior I am trying to
acheive.
It turns out I cannot forward in the onBeforeRequest() as it will
output the viewbean and then continue to process the request which in
turn trys to do a RequestDispatcher().forward after data has been
written to the stream which does not bode well with the servlet
container. Thus, it appears I have no control of the request in the
onBeforeRequest() method. Is this correct?
In light of this new observation I am now going to create a base view
class that all views will extend from and override the
onSecurityCheck() method to forward to my login bean. If I can't find
any other way, I will get the URL from the page session and do a
response.sendRedirect() to the URL.
Thanks for the help!
--- In iPlanet-JATO@y..., "Craig V. Conover" <craig.conover@s...> wrote:
The problem is that you don't know what the target view is until it has
been forwarded to.
Think about it... the request handling view bean (or command object)has
the request handler that has the code that will ultimately forward to
another view bean. This is code that you have written. So, until that
forwardTo() is invoked, there is no notion of a "target page".
What you do know is which "page" (view bean) the request is coming from
(the handling view bean or command class). You can get this from the
HttpServletRequest. The attribute name is "viewBean".
So you can get the view bean name by doing the following inonBeforeRequest:
<HttpServletRequest>.getAttribute("viewBean");
But I suspect this is not going to solve your current issue.
You could add the target page name to the page session. If there ismore
than one possible target page, it might get a little more involved.
Let me know if the use of page session needs further explanation.
c
For more information about JATO, including download information, pleasevisit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp

If you want to stop a JATO request in its tracks, you have a little black
magic at your disposal: you can throw a CompleteRequestException. This
indicates to the JATO infrastructure that it should immeditately stop
handling the request, but not generate an error, as the develper has taken
full control. You can generally throw this error from anywhere, at any
point--it is a RuntimeException, and is "tunneled" through other exception
handlers where appropriate.
In your scenario, you want to check if the user is logged in, and if not,
save the target URL using the parsePathInfo() method. Then, forward to the
login page and then throw a CompleteRequestException.
Todd
----- Original Message -----
From: "nickmalthus" <nickmalthus@h...>
Sent: Monday, January 07, 2002 3:05 PM
Subject: [iPlanet-JATO] Re: onBeforeRequest(); Finding requested view from
requestContext
I guess what I am thinking about doing is capturing the requested URL,
i.e. /appname/modulename/RequestName. In the onBeforeRequest(). I
would then check to see if the user is logged in, and if not, set the
URL in the session(or page session of the Login bean) and forward to
the Login viewbean using the viewbean manager. Inside the login view
in the handleSubmit() method I would authenticate the user and then
get the URL out of the session (or pagesession). I would then
magically get the ViewBean/Command object for the URL or otherwise
"forward the request" as if the user had typed in
/appname/modulename/RequestName, which is the behavior I am trying to
acheive.
It turns out I cannot forward in the onBeforeRequest() as it will
output the viewbean and then continue to process the request which in
turn trys to do a RequestDispatcher().forward after data has been
written to the stream which does not bode well with the servlet
container. Thus, it appears I have no control of the request in the
onBeforeRequest() method. Is this correct?
In light of this new observation I am now going to create a base view
class that all views will extend from and override the
onSecurityCheck() method to forward to my login bean. If I can't find
any other way, I will get the URL from the page session and do a
response.sendRedirect() to the URL.
Thanks for the help!
--- In iPlanet-JATO@y..., "Craig V. Conover" <craig.conover@s...> wrote:
The problem is that you don't know what the target view is until it has
been forwarded to.
Think about it... the request handling view bean (or command object)has
the request handler that has the code that will ultimately forward to
another view bean. This is code that you have written. So, until that
forwardTo() is invoked, there is no notion of a "target page".
What you do know is which "page" (view bean) the request is coming from
(the handling view bean or command class). You can get this from the
HttpServletRequest. The attribute name is "viewBean".
So you can get the view bean name by doing the following inonBeforeRequest:
<HttpServletRequest>.getAttribute("viewBean");
But I suspect this is not going to solve your current issue.
You could add the target page name to the page session. If there ismore
than one possible target page, it might get a little more involved.
Let me know if the use of page session needs further explanation.
c
For more information about JATO, including download information, pleasevisit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp

RE: [iPlanet-JATO] EJB in iMT

Similar Messages

Maybe you are looking for