Re: [iPlanet-JATO] Re: Translation hangs tool (retitled Custom Superclasses and warning T008)

Sonal,
I believe that you are misinterpreting the documentation.
I understand that PgCommon has to extend ViewBeanBase. I tried to
make the following changes in PgCommon and compiled it. Then I ran
the extraction which threw up the following error:
I believe that you are confusing extraction issues with translation issues.
The warning message that indicates the need for a class mapping strategy to
address custom superclasses in the original project is a TRANSLATION time
warning.
T008 No mapping found for [<ndClassType>]
Falling back to [Object]. Please add entry for [<ndClassType>] to
class mapping file, restart the toolbox and re-run the translation.
As such, the remedy for this warning is detailed in the documentation under
the heading
Extraction/Translation Error & Warning Messages
3.3 Notes on MigrationClassMappings.properties
It sounds to me that you have misinterpreted the instructions and have
attempted to modify the original PgCommon declaration, and then re-extract.
This is incorrect. This implies that you see this as an extraction tool
situation, which it is not. This is a translation tool consideration, and as
such does not require any adjustment of the original NetDynamics' object. So
please, return to the original PgCommon declaration, and recompile. Then run
the extraction tool. Then run the translation tool, and make note of the
translation tool warnings and deal with them.
As indicated in the documentation (although perhaps not clearly enough), the
solution to warning T008 is not to make your original PgCommon extend
ViewBeanBase, but rather to adjust the MigrationClassMappings.properties so
that the TRANSLATION tool will take your class mappings into account when it
translates the ND objects into JATO objects.
Specifically, if you add the following entry into the
MigrationClassMappings.properties file:
PgCommon PgCommonViewBean
then the translation tool will cause all classes which previously extended
PgCommon to be translated into new classes which now extend
PgCommonViewBean.
Your final step is to adjust PgCommonViewBean's constructor. Note, we are
talking about PgCommonViewBean here (i.e. the output of the Translation
tool, not the original ND object).
Change it from this:
public PgCommonViewBean()
super(PAGE_NAME);
setDefaultDisplayURL(DEFAULT_DISPLAY_URL);
registerChildren();
initialize();
TO THIS
public PgCommonViewBean(String name)
// Adjust the constructor because this is a superclass
// of the other viewbeans. It is NOT a stand along page
// Therefore its constructor should be adjusted to pass the
// page name argument up to the ViewBeanBase class
super(name);
/* Delete the following lines, they are not needed if this is acting as a
superclass of other viewbeans.
setDefaultDisplayURL(DEFAULT_DISPLAY_URL);
registerChildren();
initialize();
----- Original Message -----
From: "Todd Fast" <toddwork@c...>
Sent: Wednesday, April 25, 2001 5:16 PM
Subject: Re: [iPlanet-JATO] Re: Translation hangs tool
Sonal--
Have you tried recompiling the entire application? It sounds as if theremay
be a problem with incompatible versions of PgCommon and PgReplaceCDSIDwhich
I assume extends it. Blow away all your project class files and recompile
in the ND Studio before trying again.
Also, make sure there are no .ser files hanging around in your project
directory.
Todd
----- Original Message -----
From: <ssingh@n...>
Sent: Wednesday, April 25, 2001 6:56 AM
Subject: [iPlanet-JATO] Re: Translation hangs tool
Todd/Charles,
Thans for all the help.
The client has a small application, in which all pages extend from
PgCommon. PgCommon extends CSpPage. I read through the "Notes on
MigrationClassMappings.properties" file in iMT1.1.1 documentation.
I understand that PgCommon has to extend ViewBeanBase. I tried to
make the following changes in PgCommon and compiled it. Then I ran
the extraction which threw up the following error:
java.lang.VerifyError: (class: prHRAdminDE/PgReplaceCDSID, method:
stLinkToHome_onBeforeDisplayEvent signature:
(Lspider/event/CSpDisplayEvent;)I) Incompatible object argument for
function call
at java.lang.ClassLoader.resolveClass0(Native Method)
at java.lang.ClassLoader.resolveClass(ClassLoader.java:545)
at spider.util.CSpClassLoader.loadClass(CSpClassLoader.java,
Compiled Code)
at spider.util.CSpClassLoader.loadClassWithPackage
(CSpClassLoader.java:291)
at spider.util.CSpClassLoader.loadClassWithPackage
(CSpClassLoader.java:217)
at spider.util.CSpClassName.instantiate(CSpClassName.java:180)
at spider.intrp.CSpIntrpModel.createModel
(CSpIntrpModel.java:945)
at spider.intrp.CSpIntrpModel.createNodeObject
(CSpIntrpModel.java:282)
at spider.intrp.CSpIntrpModel.open(CSpIntrpModel.java:500)
at spider.CSpProject.readPostV40ChildObjects(CSpProject.java,
Compiled Code)
at spider.CSpProject.readObject(CSpProject.java:806)
at spider.intrp.CSpIntrpModel.createNodeObject
(CSpIntrpModel.java:293)
at spider.intrp.CSpIntrpModel.open(CSpIntrpModel.java:500)
at spider.intrp.CSpIntrpModel.open(CSpIntrpModel.java:479)
at spider.CSpider.instantiateFirstProjectInstance
(CSpider.java:6404)
at spider.CSpider.createAndSetNewProjectInstance
(CSpider.java:6187)
at spider.CSpider.allocateProjectUserContext
(CSpider.java:5471)
at spider.CSpider.preloadProjects(CSpider.java, Compiled Code)
at spider.CSpider.initialize(CSpider.java:542)
at com.iplanet.moko.netdyn.extract.PseudoCP.createProjects
(PseudoCP.java:136)
at com.iplanet.moko.netdyn.extract.PseudoCP.initialize
(PseudoCP.java:106)
at com.iplanet.moko.netdyn.extract.PseudoCP.<init>
(PseudoCP.java, Compiled Code)
at com.iplanet.moko.netdyn.tools.ExtractTool.invoke
(ExtractTool.java, Compiled Code)
at com.iplanet.moko.tools.gui.ToolInvocationThread.run
(ToolInvocationThread.java, Compiled Code)
===================================
Any more documentation availbale on how to migrate a common base
page? I beleive that it would be a fairly common issue in NetD
migrations.
===================================
New PgCommon
public class PgCommon extends ViewBeanBase implements ViewBean
//]]SPIDER_CLASS END
//[[SPIDER_EVENTS BEGIN
public static boolean DEBUG = true;
//[[SPIDER_EVENT<this_onAfterInitEvent>
public PgCommon()
super("PgCommon");
public void this_onAfterInitEvent(CSpInitEvent event){
Properties props =
HRAdminProperties.getInstance();
DEBUG = (props.getProperty
("hronlineadmin.debug").equals("TRUE"))?true:false;
//CSpLog.setSendErrorsToHtml(false);
//return (PROCEED);
//]]SPIDER_EVENT<this_onAfterInitEvent>
//]]SPIDER_EVENTS END

Similar Messages

  • RE: [iPlanet-JATO] Hanging tool

    Todd,
    I don't really know what element it is hanging on.
    Do you mean to move the entire <Page> element to be the first <Page type>
    element. Should we move all extremely large pages to the top?
    Troy
    -----Original Message-----
    From: Todd Fast [mailto:<a href="/group/SunONE-JATO/post?protectID=101233080150035167169232031248066077000048234051197">Todd.Fast@S...</a>]
    Sent: Friday, February 16, 2001 3:57 PM
    Subject: Re: [iPlanet-JATO] Hanging tool
    Hi Troy--
    Mike will probably chime in on this too. There is a bug in the JavaSoft XML
    parser that causes this issue. The workaround is to move some of the
    elements around in your extracted XML file. For example, move the hanging
    <page> element B before <page> element A. In all cases, simply moving the
    problematic element around prevents the hang.
    Todd
    [email protected]
    [Non-text portions of this message have been removed]

    Todd,
    I don't really know what element it is hanging on.
    Do you mean to move the entire <Page> element to be the first <Page type>
    element. Should we move all extremely large pages to the top?
    Troy
    -----Original Message-----
    From: Todd Fast [mailto:<a href="/group/SunONE-JATO/post?protectID=101233080150035167169232031248066077000048234051197">Todd.Fast@S...</a>]
    Sent: Friday, February 16, 2001 3:57 PM
    Subject: Re: [iPlanet-JATO] Hanging tool
    Hi Troy--
    Mike will probably chime in on this too. There is a bug in the JavaSoft XML
    parser that causes this issue. The workaround is to move some of the
    elements around in your extracted XML file. For example, move the hanging
    <page> element B before <page> element A. In all cases, simply moving the
    problematic element around prevents the hang.
    Todd
    [email protected]
    [Non-text portions of this message have been removed]

  • 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:
    <!--getPage to getViewBean-->
    <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:
    <!--getPage to getViewBean-->
    <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] 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------------------------

    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------------------------

  • Re: [iPlanet-JATO] Double Trouble

    Looks like the attachment will not be inlined by egroup's mailer so here is
    the table i was trying to send before:
    Current Type mapping (appologies for lousy formatting)
    ND ColumnDataType DATA_FIELD_TYPE_MAP
    DATA_FIELD_SQL_TYPE_MAP
    NO_TYPE String
    java.sql.Types.VARCHAR
    CHAR_TYPE String
    java.sql.Types.CHAR
    UNSIGNED_CHAR_TYPE String
    java.sql.Types.CHAR
    TINY_TYPE Short
    java.sql.Types.SMALLINT
    UNSIGNED_TINY_TYPE Short
    java.sql.Types.SMALLINT
    SHORT_TYPE Short
    java.sql.Types.SMALLINT
    UNSIGNED_SHORT_TYPE Short
    java.sql.Types.SMALLINT
    INT_TYPE Integer
    java.sql.Types.INTEGER
    UNSIGNED_INT_TYPE Integer
    java.sql.Types.INTEGER
    LONG_TYPE Long
    java.sql.Types.BIGINT
    UNSIGNED_LONG_TYPE Long
    java.sql.Types.BIGINT
    FLOAT_TYPE Float
    java.sql.Types.FLOAT
    DOUBLE_TYPE Double
    java.sql.Types.DOUBLE
    DECIMAL_TYPE java.math.BigDecimal
    java.sql.Types.DECIMAL
    DATE_TYPE java.sql.Date
    java.sql.Types.DATE
    DATETIME_TYPE java.sql.Timestamp
    java.sql.Types.TIMESTAMP
    DURATION_TYPE DONT_KNOW_CLASS_TYPE
    DONT_KNOW_CLASS_TYPE
    STRING_TYPE String
    java.sql.Types.VARCHAR
    BLOB_TYPE Object
    java.sql.Types.BLOB
    UNQUOTED_STRING_TYPE DONT_KNOW_CLASS_TYPE DONT_KNOW_CLASS_TYPE
    BOOLEAN_TYPE Boolean
    java.sql.Types.BINARY
    USER_DEFINED_TYPE DONT_KNOW_CLASS_TYPE
    java.sql.Types.JAVA_OBJECT
    Translation Tool Type Mapping Structures
    The current code generation structures that are responsible for supporting
    these type mappings at translation times are as follows:
    CodeGeneration.DATA_FIELD_TYPE_MAP
    The map is constructed from two arrays:
    CodeGeneration. ND_DATA_FIELD_DATA_TYPES
    CodeGeneration. MIGRATION_MODEL_DATA_TYPES
    CodeGeneration. DATA_FIELD_SQL_TYPE_MAP
    The map is constructed from two arrays:
    CodeGeneration. ND_DATA_FIELD_DATA_TYPES
    CodeGeneration. MIGRATION_MODEL_DATA_TYPES
    JATO Type Values
    The following JATO field values or member types are generated at translation
    time based on the type mappings:
    Model Field typing
    Model.member field type - drawn from CodeGeneration .DATA_FIELD_TYPE_MAP
    Descriptor typing
    QueryFieldDescriptor.fieldClass
    - drawn from CodeGeneration .DATA_FIELD_TYPE_MAP
    StoredProcParameterDescriptor.fieldClass
    - drawn from CodeGeneration .DATA_FIELD_TYPE_MAP
    StoredProcParameterDescriptor.sqlType
    - drawn from CodeGeneration.DATA_FIELD_SQL_TYPE_MAP
    ----- Original Message -----
    From: Mike Frisino <Michael.Frisino@S...>
    Sent: Thursday, January 04, 2001 12:19 PM
    Subject: Re: [iPlanet-JATO] Double Trouble
    Thanks John,
    Can you provide some more information that would help resolve this issue.
    It could be that the mapping rules we use during the translation need tobe
    adjusted.
    Specifically, what were the following ND property values you had for the
    field in question:
    ND Datafield property "ColumnDataType"
    ND Datafield property "ColumnDataTypeText"
    ND Datafield property "NativeType"
    ND Datafield property "NativeTypeText"
    You see, during the translation we had to choose to map from the originalND
    type information to a corresponding java or java.sql type.
    We were not certain whether to favor ND's "ColumnDataType" or ND's
    "NativeType" value.
    We came up with rules based on mapping ND's ColumnDataType. Those rulesare
    detailed in the attachment.
    ----- Original Message -----
    From: <john.teceno@b...>
    Sent: Thursday, January 04, 2001 7:33 AM
    Subject: [iPlanet-JATO] Double Trouble
    Hey Guys,
    I've run across a problem retrieving Doubles back from an Oracle
    Database. The field is defined as a Number. When we converted the
    program from NetD, it was created with return values of Double. What
    is returned is not the correct value. For example, in the table the
    value is 123456, when I do a getInternalID(), it is returning 2.0. I
    am working on a work around, but I thought that I would post this
    anyway.
    John Teceno
    Back Bay Technologies
    [email protected]
    [Non-text portions of this message have been removed]
    [email protected]

    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]

  • RE: [iPlanet-JATO] Re: Use Of models in utility classes

    Hi all,
    if you add the following to your spider2jato.xml
    It will automatically map your CSpDataObject.executeImmediate to use
    ExecuteImmediateUtil.executeImmediateSelect with the arguments mapped as
    well.
    Kostas
    <mapping-rule>
    <mapping-rule-primarymatch>
    <![CDATA[CSpDataObject[.\s]*executeImmediate[\s]*\(([^,]*),([^)]*)\)]]>
    </mapping-rule-primarymatch>
    <mapping-rule-replacement>
    <mapping-rule-match>
    <![CDATA[CSpDataObject[.\s]*executeImmediate[\s]*\(([^,]*),([^)]*)\)]]>
    </mapping-rule-match>
    <mapping-rule-substitute>
    <![CDATA[ExecuteImmediateUtil.executeImmediateSelect($1,$2,
    getRequestContext())]]>
    </mapping-rule-substitute>
    </mapping-rule-replacement>
    </mapping-rule>
    -----Original Message-----
    From: Matthew Stevens
    Cc: vnamboori@y...
    Sent: 11/29/01 11:23 AM
    Subject: RE: [iPlanet-JATO] Re: Use Of models in utility classes
    Namburi,
    I have included an example in the file ExecuteImmediateUtil.java
    The Yahoo Group will not handle the attached file we will put it in the
    Files section shortly.
    matt
    -----Original Message-----
    From: vnamboori@y... [mailto:<a href="/group/SunONE-JATO/post?protectID=081071113213093190112061186248100253094145066046167121181">vnamboori@y...</a>]
    Sent: Thursday, November 29, 2001 12:29 PM
    Subject: [iPlanet-JATO] Re: Use Of models in utility classes
    Matt,
    For CSpSelect.executeImmediate() I have an example of custom helpermethod as a replacement which uses JDBC results instead of
    CSpDBResult.
    Can you send me this example.
    Thanks
    Namburi
    --- In iPlanet-JATO@y..., "Matthew Stevens" <matthew.stevens@E...>
    wrote:
    Namburi,
    I will post a document to the group site this evening which has thedetails
    on various tactics of migrating these type of utilities.Essentially, you
    either need to convert these utilities to Models themselves or keepthe
    utilities as is and simply use the
    RequestManager.getRequestContext.getModelManager().getModel()
    to statically access Models.
    For CSpSelect.executeImmediate() I have an example of custom helpermethod
    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 the
    manipulations.
    So we access dataobjects directly like
    CSpider.getDataObject("do....");
    and then execute it.
    Since the migration tool does not do much of conversion for these
    utilities we have to do manually.
    My question is Can we access the the models in the post migration
    sameway or do we need requestContext?
    We have lots of utility classes which are DataObject intensive.Can
    someone suggest a better way to migrate this kind of code.
    Thanks
    Namburi
    [email protected]
    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]
    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]

    Hi all,
    if you add the following to your spider2jato.xml
    It will automatically map your CSpDataObject.executeImmediate to use
    ExecuteImmediateUtil.executeImmediateSelect with the arguments mapped as
    well.
    Kostas
    <mapping-rule>
    <mapping-rule-primarymatch>
    <![CDATA[CSpDataObject[.\s]*executeImmediate[\s]*\(([^,]*),([^)]*)\)]]>
    </mapping-rule-primarymatch>
    <mapping-rule-replacement>
    <mapping-rule-match>
    <![CDATA[CSpDataObject[.\s]*executeImmediate[\s]*\(([^,]*),([^)]*)\)]]>
    </mapping-rule-match>
    <mapping-rule-substitute>
    <![CDATA[ExecuteImmediateUtil.executeImmediateSelect($1,$2,
    getRequestContext())]]>
    </mapping-rule-substitute>
    </mapping-rule-replacement>
    </mapping-rule>
    -----Original Message-----
    From: Matthew Stevens
    Cc: vnamboori@y...
    Sent: 11/29/01 11:23 AM
    Subject: RE: [iPlanet-JATO] Re: Use Of models in utility classes
    Namburi,
    I have included an example in the file ExecuteImmediateUtil.java
    The Yahoo Group will not handle the attached file we will put it in the
    Files section shortly.
    matt
    -----Original Message-----
    From: vnamboori@y... [mailto:<a href="/group/SunONE-JATO/post?protectID=081071113213093190112061186248100253094145066046167121181">vnamboori@y...</a>]
    Sent: Thursday, November 29, 2001 12:29 PM
    Subject: [iPlanet-JATO] Re: Use Of models in utility classes
    Matt,
    For CSpSelect.executeImmediate() I have an example of custom helpermethod as a replacement which uses JDBC results instead of
    CSpDBResult.
    Can you send me this example.
    Thanks
    Namburi
    --- In iPlanet-JATO@y..., "Matthew Stevens" <matthew.stevens@E...>
    wrote:
    Namburi,
    I will post a document to the group site this evening which has thedetails
    on various tactics of migrating these type of utilities.Essentially, you
    either need to convert these utilities to Models themselves or keepthe
    utilities as is and simply use the
    RequestManager.getRequestContext.getModelManager().getModel()
    to statically access Models.
    For CSpSelect.executeImmediate() I have an example of custom helpermethod
    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 the
    manipulations.
    So we access dataobjects directly like
    CSpider.getDataObject("do....");
    and then execute it.
    Since the migration tool does not do much of conversion for these
    utilities we have to do manually.
    My question is Can we access the the models in the post migration
    sameway or do we need requestContext?
    We have lots of utility classes which are DataObject intensive.Can
    someone suggest a better way to migrate this kind of code.
    Thanks
    Namburi
    [email protected]
    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]
    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]

  • Re: [iPlanet-JATO] Use Of models in utility classes

    Hi Matt,
    Sounds like some of the stuff we need to migrate has a lot in common with
    Namburi's project.
    I would be very keen to get hold of a copy of the 'tactic' document you
    mention below, as well as the sample code you mention to replace CspDBResult
    stuff with JDBC results.
    Thanks in advance,
    Phil
    ----- Original Message -----
    From: Matthew Stevens <matthew.stevens@E...>
    Sent: Wednesday, August 08, 2001 7:56 AM
    Subject: RE: [iPlanet-JATO] Use Of models in utility classes
    Namburi,
    I will post a document to the group site this evening which has thedetails
    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 custom helper 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=081071113213093190112061186248100253094145066046167121181">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 the manipulations.
    So we access dataobjects directly like
    CSpider.getDataObject("do....");
    and then execute it.
    Since the migration tool does not do much of conversion for these
    utilities we have to do manually.
    My question is Can we access the the models in the post migration
    sameway or do we need requestContext?
    We have lots of utility classes which are DataObject intensive. Can
    someone suggest a better way to migrate this kind of code.
    Thanks
    Namburi
    [email protected]
    [email protected]

    Hi Matt,
    Sounds like some of the stuff we need to migrate has a lot in common with
    Namburi's project.
    I would be very keen to get hold of a copy of the 'tactic' document you
    mention below, as well as the sample code you mention to replace CspDBResult
    stuff with JDBC results.
    Thanks in advance,
    Phil
    ----- Original Message -----
    From: Matthew Stevens <matthew.stevens@E...>
    Sent: Wednesday, August 08, 2001 7:56 AM
    Subject: RE: [iPlanet-JATO] Use Of models in utility classes
    Namburi,
    I will post a document to the group site this evening which has thedetails
    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 custom helper 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=081071113213093190112061186248100253094145066046167121181">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 the manipulations.
    So we access dataobjects directly like
    CSpider.getDataObject("do....");
    and then execute it.
    Since the migration tool does not do much of conversion for these
    utilities we have to do manually.
    My question is Can we access the the models in the post migration
    sameway or do we need requestContext?
    We have lots of utility classes which are DataObject intensive. Can
    someone suggest a better way to migrate this kind of code.
    Thanks
    Namburi
    [email protected]
    [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] Experiencing problem while executing model.

    Hi Todd,
    Thanks a lot for your input!
    In the case , I found that "TO_CHAR(PLAN_DT, 'MM/DD/YYYY')" is alaised as a
    column name in the resultset. So I am using this as a column in Jato
    Descriptor for Plan_Dt. Now it is working fine.
    Thanks and Regards,
    Santa.
    ----- Original Message -----
    From: Todd Fast <toddwork@c...>
    Sent: Thursday, July 26, 2001 9:50 AM
    Subject: Re: [iPlanet-JATO] Experiencing problem while executing model.
    Santa--
    I am experiencing a problem while executing a bounded model. I am usingQueryModelBase. Whenever the following query gets executed inonBeforeModel
    execute of TiledView, it throws an exception describing "PLAN_DT not found
    in ResultSet". If you execute this query on the SQL prompt then we getrows
    of data. Please could you tell us how the mapping between model and
    resultset works ? And what changes do we have to make to execute thisquery.
    >>
    SELECT PART_NM,NEWTXTDOLL
    TO_CHAR(PLAN_DT, 'MM/DD/YYYY'),
    FROM cpsselect
    WHERE CHG_DT >= TO_DATE('2001-06-17', 'YYYY-MM-DD')The mapping of result set to model is done via JDBC, using the columnnames
    you provide in your model's column descriptors. It sounds as if you are
    providing the column name "PLAN_DT" in a descriptor, and when the model
    tries to look up that column in the result set, there is no such columnand
    the operation fails.
    In order to debug this, you should try running your query with a JDBC
    connection, not SQL*Plus or your command-line SQL tool. What you need to
    find out is how the expresion "TO_CHAR(PLAN_DT, 'MM/DD/YYYY')" is aliasedas
    a column name in the resut set. The easiest way to do this is to write a
    simple class that does nothing but use your JDBC driver to connect the
    database and execute this query. After execution, use theResultSetMetaData
    information to find out the column names for the result set. Then, use
    these column names in your JATO column descriptors.
    Another Problem:We are not getting the values for NEWTXTDOLL column whenwe try to display it in a Tiled View.
    I'm sorry, this isn't enough information for me to offer any suggestions.
    Using the technique above, determine which columns are coming back in the
    result set, and make sure your display fields in the TiledView are boundto
    those column names. The problem could be something as simple as a typo in
    the field's bound name, or something more complex like the column in the
    result set being named something you don't expect.
    Another approach might be to alias the columns yourself using the "AS
    <alias>" expression, and assign them names that you choose instead ofusing
    the names assigned by the database or JDBC driver.
    Todd
    [email protected]
    The Information contained and transmitted by this E-MAIL is proprietary to
    Wipro Limited and is intended for use only by the individual or entity to
    which
    it is addressed, and may contain information that is privileged, confidential
    or
    exempt from disclosure under applicable law. If this is a forwarded message,
    the content of this E-MAIL may not have been sent with the authority of the
    Company. If you are not the intended recipient, an agent of the intended
    recipient or a person responsible for delivering the information to the named
    recipient, you are notified that any use, distribution, transmission,
    printing,
    copying or dissemination of this information in any way or in any manner is
    strictly prohibited. If you have received this communication in error, please
    delete this mail & notify us immediately at mailadmin@w...
    [Non-text portions of this message have been removed]

    Hi Todd,
    Thanks a lot for your input!
    In the case , I found that "TO_CHAR(PLAN_DT, 'MM/DD/YYYY')" is alaised as a
    column name in the resultset. So I am using this as a column in Jato
    Descriptor for Plan_Dt. Now it is working fine.
    Thanks and Regards,
    Santa.
    ----- Original Message -----
    From: Todd Fast <toddwork@c...>
    Sent: Thursday, July 26, 2001 9:50 AM
    Subject: Re: [iPlanet-JATO] Experiencing problem while executing model.
    Santa--
    I am experiencing a problem while executing a bounded model. I am usingQueryModelBase. Whenever the following query gets executed inonBeforeModel
    execute of TiledView, it throws an exception describing "PLAN_DT not found
    in ResultSet". If you execute this query on the SQL prompt then we getrows
    of data. Please could you tell us how the mapping between model and
    resultset works ? And what changes do we have to make to execute thisquery.
    >>
    SELECT PART_NM,NEWTXTDOLL
    TO_CHAR(PLAN_DT, 'MM/DD/YYYY'),
    FROM cpsselect
    WHERE CHG_DT >= TO_DATE('2001-06-17', 'YYYY-MM-DD')The mapping of result set to model is done via JDBC, using the columnnames
    you provide in your model's column descriptors. It sounds as if you are
    providing the column name "PLAN_DT" in a descriptor, and when the model
    tries to look up that column in the result set, there is no such columnand
    the operation fails.
    In order to debug this, you should try running your query with a JDBC
    connection, not SQL*Plus or your command-line SQL tool. What you need to
    find out is how the expresion "TO_CHAR(PLAN_DT, 'MM/DD/YYYY')" is aliasedas
    a column name in the resut set. The easiest way to do this is to write a
    simple class that does nothing but use your JDBC driver to connect the
    database and execute this query. After execution, use theResultSetMetaData
    information to find out the column names for the result set. Then, use
    these column names in your JATO column descriptors.
    Another Problem:We are not getting the values for NEWTXTDOLL column whenwe try to display it in a Tiled View.
    I'm sorry, this isn't enough information for me to offer any suggestions.
    Using the technique above, determine which columns are coming back in the
    result set, and make sure your display fields in the TiledView are boundto
    those column names. The problem could be something as simple as a typo in
    the field's bound name, or something more complex like the column in the
    result set being named something you don't expect.
    Another approach might be to alias the columns yourself using the "AS
    <alias>" expression, and assign them names that you choose instead ofusing
    the names assigned by the database or JDBC driver.
    Todd
    [email protected]
    The Information contained and transmitted by this E-MAIL is proprietary to
    Wipro Limited and is intended for use only by the individual or entity to
    which
    it is addressed, and may contain information that is privileged, confidential
    or
    exempt from disclosure under applicable law. If this is a forwarded message,
    the content of this E-MAIL may not have been sent with the authority of the
    Company. If you are not the intended recipient, an agent of the intended
    recipient or a person responsible for delivering the information to the named
    recipient, you are notified that any use, distribution, transmission,
    printing,
    copying or dissemination of this information in any way or in any manner is
    strictly prohibited. If you have received this communication in error, please
    delete this mail & notify us immediately at mailadmin@w...
    [Non-text portions of this message have been removed]

  • 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] Data model(Dataobject in Nd5)

    Sn,
    Computed columns need special attention.
    The migration tool creates a QueryFieldSchema for each Model (DataObject).
    The schema is populated with entries for each of the "data fields" needed by
    that query. For example:
    FIELD_SCHEMA.addFieldDescriptor(
    new QueryFieldDescriptor(
    FIELD_NDNWORDERS_ORDERID,
    COLUMN_NDNWORDERS_ORDERID,
    QUALIFIED_COLUMN_NDNWORDERS_ORDERID,
    Integer.class,
    false,
    false,
    QueryFieldDescriptor.APPLICATION_INSERT_VALUE_SOURCE,
    QueryFieldDescriptor.ON_EMPTY_VALUE_EXCLUDE,
    The query field descriptor describes the "metadata" for a given field:
    QueryFieldDescriptor(java.lang.String logicalName, java.lang.String
    columnName, java.lang.String qualifiedColumnName, java.lang.Class
    fieldClass, boolean isKey, boolean isComputedField, int insertValueSource,
    java.lang.String insertFormula, int onEmptyValuePolicy, java.lang.String
    emptyFormula)
    There is also a SQL Template generated for select statements:
    static final String SELECT_SQL_TEMPLATE="SELECT ALL ndnwOrders.OrderID,
    ndnwOrders.CustomerID, ndnwOrders.EmployeeID, ndnwOrders.OrderDate,
    ndnwOrders.RequiredDate, ndnwOrders.ShippedDate, ndnwOrders.ShipVia,
    ndnwOrders.Freight, ndnwOrders.ShipName, ndnwOrders.ShipAddress,
    ndnwOrders.ShipCity, ndnwOrders.ShipRegion, ndnwOrders.ShipPostalCode,
    ndnwOrders.ShipCountry FROM ndnwOrders __WHERE__ ";
    public
    So for computed columns you need to do two things:
    1. You need to adjust the SELECT_SQL_TEMPLATE to reflect your computed
    column instead of the "simplistic" column name that appears there by
    default.
    2. You have to "alias" that column and provide the value of the alias in the
    columnName position of the QueryFieldDescriptor. This is needed so that the
    model will be able to dereference the computed column in the result set.
    ----- Original Message -----
    From: "SNR R" <snr@s...>
    Sent: Thursday, July 12, 2001 8:30 AM
    Subject: [iPlanet-JATO] Data model(Dataobject in Nd5)
    Hi
    We are migrating ND5 application into iplanet.When we are excuting
    data model it is giving invalid column name error but when we check
    data
    model sql statement which is working fine at sqlplus but this data model
    has got computed column.
    could you please tell me how to resolve this problem.
    Thanks
    Sn
    ----- Original Message -----
    From: "Todd Fast" <toddwork@c...>
    Date: Monday, July 9, 2001 10:42 pm
    Subject: Re: [iPlanet-JATO] COULD YOU PLS HELP ME TO FIX REPEATED OBJECT
    ISSUE.
    This code should generally be in the TiledView (it may appear in
    both the
    ViewBean and the TiledView after migration).
    CSpRepeated repeated =(CSpRepeated) event.getSource();// Assuming the code is in the TiledView
    TiledView repeated=this;
    CSpStaticText stFieldName =(CSpStaticText)
    repeated.getDisplayField("stFieldName");StaticTextField stFieldName=
    (StaticTextField)getDisplayField("stFieldName");
    - or -
    StaticTextField stFieldName=getStFieldName();
    int index = event.getRowIndex();In what event do you want to obtain the index? For the most part,
    you can
    just call TiledView.getTileIndex(). If this is a request event
    handlingmethod, the row index is part of the event signature.
    IMPORTANT: If the original code cached references to display
    fields as page
    instance variables for use in the class's events, you should NOT
    do the same
    in JATO. This was an ND pattern that is unnecessary and
    inefficient in
    JATO. Instead, you should just use the generated accessors or the
    getDisplayField()/getChild() methods to obtain a reference to a
    displayfield as needed. Mike Frisino has elaborated this point in
    the past; please
    refer to his emails.
    Todd
    [email protected]
    [email protected]

    Sn,
    Computed columns need special attention.
    The migration tool creates a QueryFieldSchema for each Model (DataObject).
    The schema is populated with entries for each of the "data fields" needed by
    that query. For example:
    FIELD_SCHEMA.addFieldDescriptor(
    new QueryFieldDescriptor(
    FIELD_NDNWORDERS_ORDERID,
    COLUMN_NDNWORDERS_ORDERID,
    QUALIFIED_COLUMN_NDNWORDERS_ORDERID,
    Integer.class,
    false,
    false,
    QueryFieldDescriptor.APPLICATION_INSERT_VALUE_SOURCE,
    QueryFieldDescriptor.ON_EMPTY_VALUE_EXCLUDE,
    The query field descriptor describes the "metadata" for a given field:
    QueryFieldDescriptor(java.lang.String logicalName, java.lang.String
    columnName, java.lang.String qualifiedColumnName, java.lang.Class
    fieldClass, boolean isKey, boolean isComputedField, int insertValueSource,
    java.lang.String insertFormula, int onEmptyValuePolicy, java.lang.String
    emptyFormula)
    There is also a SQL Template generated for select statements:
    static final String SELECT_SQL_TEMPLATE="SELECT ALL ndnwOrders.OrderID,
    ndnwOrders.CustomerID, ndnwOrders.EmployeeID, ndnwOrders.OrderDate,
    ndnwOrders.RequiredDate, ndnwOrders.ShippedDate, ndnwOrders.ShipVia,
    ndnwOrders.Freight, ndnwOrders.ShipName, ndnwOrders.ShipAddress,
    ndnwOrders.ShipCity, ndnwOrders.ShipRegion, ndnwOrders.ShipPostalCode,
    ndnwOrders.ShipCountry FROM ndnwOrders __WHERE__ ";
    public
    So for computed columns you need to do two things:
    1. You need to adjust the SELECT_SQL_TEMPLATE to reflect your computed
    column instead of the "simplistic" column name that appears there by
    default.
    2. You have to "alias" that column and provide the value of the alias in the
    columnName position of the QueryFieldDescriptor. This is needed so that the
    model will be able to dereference the computed column in the result set.
    ----- Original Message -----
    From: "SNR R" <snr@s...>
    Sent: Thursday, July 12, 2001 8:30 AM
    Subject: [iPlanet-JATO] Data model(Dataobject in Nd5)
    Hi
    We are migrating ND5 application into iplanet.When we are excuting
    data model it is giving invalid column name error but when we check
    data
    model sql statement which is working fine at sqlplus but this data model
    has got computed column.
    could you please tell me how to resolve this problem.
    Thanks
    Sn
    ----- Original Message -----
    From: "Todd Fast" <toddwork@c...>
    Date: Monday, July 9, 2001 10:42 pm
    Subject: Re: [iPlanet-JATO] COULD YOU PLS HELP ME TO FIX REPEATED OBJECT
    ISSUE.
    This code should generally be in the TiledView (it may appear in
    both the
    ViewBean and the TiledView after migration).
    CSpRepeated repeated =(CSpRepeated) event.getSource();// Assuming the code is in the TiledView
    TiledView repeated=this;
    CSpStaticText stFieldName =(CSpStaticText)
    repeated.getDisplayField("stFieldName");StaticTextField stFieldName=
    (StaticTextField)getDisplayField("stFieldName");
    - or -
    StaticTextField stFieldName=getStFieldName();
    int index = event.getRowIndex();In what event do you want to obtain the index? For the most part,
    you can
    just call TiledView.getTileIndex(). If this is a request event
    handlingmethod, the row index is part of the event signature.
    IMPORTANT: If the original code cached references to display
    fields as page
    instance variables for use in the class's events, you should NOT
    do the same
    in JATO. This was an ND pattern that is unnecessary and
    inefficient in
    JATO. Instead, you should just use the generated accessors or the
    getDisplayField()/getChild() methods to obtain a reference to a
    displayfield as needed. Mike Frisino has elaborated this point in
    the past; please
    refer to his emails.
    Todd
    [email protected]
    [email protected]

  • 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: 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

Maybe you are looking for

  • Would you choose neoOffice over openOffice?

    Hello all, I'm very new to Apple. I've purchase my first iMac last September and this is my first post. I'm interested in installing either of these products. Office 2011 for Mac is out of the question as I don't do enough work at home to warrant pur

  • HT1454 how do I print off my text messages to include date and time received I have an iphone 3G

    Hi   I have an iphone 3G and need to know how to print off some of my text messages including the date and time.   Does anyone know how I do this?

  • Join Button Grayed Out

    My iPad connects with no problem at home on my Time Capsule and Airport Extreme Routers. At my office, I can't even find out if it will connect or not, because when I select the network to join it, as soon as I type in a password, the JOIN button gra

  • Validation error using flat files..VLD-2407

    Trying to build a simple flat file mapping to test out file locations and permissions at a new client and getting the following error: VLD-2407: SQL*Loader map must have a source file. OWB 10.2.0.3. I've added a filename for everything i could find i

  • New laptop suggestions

    I'm looking to replace an older laptop to use editing and restoring photos in Photoshop, but all the ones I've seen at Frys and Best Buy have  highly reflective screens. Any suggestions for finding a laptop with more of a monitor-type screen without