[jira] Created: (TRINIDAD-1710) ResourceServlet.java._setHeaders() can call response.setContentType() with a null contentType resulting in an NPE on Websphere.
ResourceServlet.java._setHeaders() can call response.setContentType() with a null contentType resulting in an NPE on Websphere. --- Key: TRINIDAD-1710 URL: https://issues.apache.org/jira/browse/TRINIDAD-1710 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.12-core Reporter: Gary Kind This is a backport of JIRA Issue TRINIDAD-1629. This is needed in 1.2.12.1-branch as soon as possible -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1710) ResourceServlet.java._setHeaders() can call response.setContentType() with a null contentType resulting in an NPE on Websphere.
[ https://issues.apache.org/jira/browse/TRINIDAD-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Kind updated TRINIDAD-1710: Status: Patch Available (was: Open) ResourceServlet.java._setHeaders() can call response.setContentType() with a null contentType resulting in an NPE on Websphere. --- Key: TRINIDAD-1710 URL: https://issues.apache.org/jira/browse/TRINIDAD-1710 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.12-core Reporter: Gary Kind Attachments: ResourceServlet.patch Original Estimate: 24h Remaining Estimate: 24h This is a backport of JIRA Issue TRINIDAD-1629. This is needed in 1.2.12.1-branch as soon as possible -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1629) ResourceServlet.java._setHeaders() can call response.setContentType() with a null contentType resulting in an NPE on Websphere.
ResourceServlet.java._setHeaders() can call response.setContentType() with a null contentType resulting in an NPE on Websphere. --- Key: TRINIDAD-1629 URL: https://issues.apache.org/jira/browse/TRINIDAD-1629 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.12-core Reporter: Gary Kind If a Server, in this case Websphere, tries to load a resource with an unknown file extension, e.g. file.cur where .cur is the extension, ResourceServlet._setHeaders() will call response.setContentType() with a null contentType. This results an NPE showing up in the Websphere systemOut.log file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1590) maven-jdev-plugin: added ability to set JVM Java Options. Default is -ea to enable assertions
maven-jdev-plugin: added ability to set JVM Java Options. Default is -ea to
enable assertions
---
Key: TRINIDAD-1590
URL: https://issues.apache.org/jira/browse/TRINIDAD-1590
Project: MyFaces Trinidad
Issue Type: New Feature
Affects Versions: 1.2.10-plugins
Reporter: Gary Kind
In Jdeveloper under Project Properties - Run/Debug/Profile, edit a selected
profile and you will see a Java Options input text field to the right of the
selected JVM. An attribute has been added to the maven-jdev-plugin to set
these Java Options. Here is a sample of how it would be set in a maven pom.xml
file:
plugin
groupIdorg.apache.myfaces.trinidadbuild/groupId
artifactIdmaven-jdev-plugin/artifactId
configuration
javaOptions-ea/javaOptions
projectHasTests${jdev.project.has.tests}/projectHasTests
testSourceRoots
file${project.basedir}/src/test/file
/testSourceRoots
/configuration
/plugin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1590) maven-jdev-plugin: added ability to set JVM Java Options. Default is -ea to enable assertions
[
https://issues.apache.org/jira/browse/TRINIDAD-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Kind updated TRINIDAD-1590:
Status: Patch Available (was: Open)
maven-jdev-plugin: added ability to set JVM Java Options. Default is -ea to
enable assertions
---
Key: TRINIDAD-1590
URL: https://issues.apache.org/jira/browse/TRINIDAD-1590
Project: MyFaces Trinidad
Issue Type: New Feature
Affects Versions: 1.2.10-plugins
Reporter: Gary Kind
In Jdeveloper under Project Properties - Run/Debug/Profile, edit a selected
profile and you will see a Java Options input text field to the right of the
selected JVM. An attribute has been added to the maven-jdev-plugin to set
these Java Options. Here is a sample of how it would be set in a maven
pom.xml file:
plugin
groupIdorg.apache.myfaces.trinidadbuild/groupId
artifactIdmaven-jdev-plugin/artifactId
configuration
javaOptions-ea/javaOptions
projectHasTests${jdev.project.has.tests}/projectHasTests
testSourceRoots
file${project.basedir}/src/test/file
/testSourceRoots
/configuration
/plugin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1477) XMLMenuModel GroupNode Functionality Broken
[ https://issues.apache.org/jira/browse/TRINIDAD-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Kind updated TRINIDAD-1477: Status: Patch Available (was: Open) XMLMenuModel GroupNode Functionality Broken --- Key: TRINIDAD-1477 URL: https://issues.apache.org/jira/browse/TRINIDAD-1477 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.11-core Reporter: Gary Kind Attachments: patch.txt Recent changes to the XMLMenuModel to allow multiple root menus on the same page broke the GroupNode Functionality and internal IdNodeMap that is used as part of the GroupNode functionality.This patch corrects the problem and restores the GroupNode Functionallity. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1477) XMLMenuModel GroupNode Functionality Broken
XMLMenuModel GroupNode Functionality Broken --- Key: TRINIDAD-1477 URL: https://issues.apache.org/jira/browse/TRINIDAD-1477 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.11-core Reporter: Gary Kind Attachments: patch.txt Recent changes to the XMLMenuModel to allow multiple root menus on the same page broke the GroupNode Functionality and internal IdNodeMap that is used as part of the GroupNode functionality.This patch corrects the problem and restores the GroupNode Functionallity. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1411) maven-jdev-plugin has been updated for JDeveloper 11.1.1.1.0
[ https://issues.apache.org/jira/browse/TRINIDAD-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Kind updated TRINIDAD-1411: Status: Patch Available (was: Open) maven-jdev-plugin has been updated for JDeveloper 11.1.1.1.0 Key: TRINIDAD-1411 URL: https://issues.apache.org/jira/browse/TRINIDAD-1411 Project: MyFaces Trinidad Issue Type: Improvement Components: Plugins Affects Versions: 1.2.9-plugins Reporter: Gary Kind I have updated the maven-jdev-plugin so that it works correctly for JDeveloper 11.1.1.1.0 -- that is, it generates .jws and .jpr files that do not have to be migrated by JDeveloper before being used by JDeveloper. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1411) maven-jdev-plugin has been updated for JDeveloper 11.1.1.1.0
maven-jdev-plugin has been updated for JDeveloper 11.1.1.1.0 Key: TRINIDAD-1411 URL: https://issues.apache.org/jira/browse/TRINIDAD-1411 Project: MyFaces Trinidad Issue Type: Improvement Components: Plugins Affects Versions: 1.2.9-plugins Reporter: Gary Kind I have updated the maven-jdev-plugin so that it works correctly for JDeveloper 11.1.1.1.0 -- that is, it generates .jws and .jpr files that do not have to be migrated by JDeveloper before being used by JDeveloper. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1186) xml schema files (xsd) are added for the XMLMenuModel
xml schema files (xsd) are added for the XMLMenuModel - Key: TRINIDAD-1186 URL: https://issues.apache.org/jira/browse/TRINIDAD-1186 Project: MyFaces Trinidad Issue Type: Improvement Components: Facelets Affects Versions: 1.2.9-core Reporter: Gary Kind Attachments: xmlmenumodel_xsd_trinidad_1.2.9.1.patch The xsd files for the XMLMenuModel were never included in Trinidad. They are in the provided patch file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1183) Allows any node in the whole menu tree to be obtained through its id, unique or not.
Allows any node in the whole menu tree to be obtained through its id, unique or not. -- Key: TRINIDAD-1183 URL: https://issues.apache.org/jira/browse/TRINIDAD-1183 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.9-core Reporter: Gary Kind The XMLMenuModel has 1 root model and (possibly) numerous child menu models incorporated into the root menu tree through shared nodes. If development is done in separate locations, it is possible for nodes of different menu models to be given the same value for the id attributes. Prior to this enhancement, a developer could call API model.getNode(id) and be returned the first node in the tree with a matching id. However, it would not be guaranteed to be the correct node because of the possibility of duplicate ids. The onus was put on the application developer to make sure that all id's were unique. A design-time ide could enforce this, but the runtime did not. With this new enhancement, a node has access to its model's (unique) internal id which is appended (internally) to the node's id to form a unique id for the root model's node hashmap. Now when model.getNode(id) is called the model's id is obtained and appended to the id arg, and the node is retrieved from the root model's node hashmap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1134) XmlMenuModel: action is interpreted as ValueExpression
[
https://issues.apache.org/jira/browse/TRINIDAD-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607730#action_12607730
]
Gary Kind commented on TRINIDAD-1134:
-
The action attribute, as per the spec, is supposed to contain an navigation
case outcome. Therefore, whatever you put in as its value should evaluate to
an outcome. Workaround would be to have your bean return a navigation outcome
string.
XmlMenuModel: action is interpreted as ValueExpression
--
Key: TRINIDAD-1134
URL: https://issues.apache.org/jira/browse/TRINIDAD-1134
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Stephen Friedrich
An action set on an ItemNode is evaluated as a value expression.
Workround is to have a getter instead of an action-method-signature in the
backing bean:
public String getDoIt()
for an itemNode like this:
itemNode id=companies action=#{_companyList.doIt}
label=#{Output.COMPANIES} ...
See
http://www.nabble.com/-Trinidad--Bug-in-XMLMenuModel---ItemNode---tt12376683.html#a12376683
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1127) XMLMenu / CommandNavigationItem
[
https://issues.apache.org/jira/browse/TRINIDAD-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606090#action_12606090
]
Gary Kind commented on TRINIDAD-1127:
-
Jim, the destination is to be used to navigate directly to a page so no POST is
done. The 'action' attribute navigates to the page specified in the
navigation-case in your faces-config.xml file whose outcome matches the value
of the 'action' attribute.
Since both action and destination are used for navigation, you can only do one
OR the other. We have chosen 'destination' to take precedence over 'action',
so action must be ignored. This is not a bug.
XMLMenu / CommandNavigationItem
---
Key: TRINIDAD-1127
URL: https://issues.apache.org/jira/browse/TRINIDAD-1127
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.0.8-core
Environment: Win XP/ Jboss 4.0.4
Reporter: Jim Dolinski
I am using the new XML menu model, it is much simpler and easier to use,
thanks.
I am having problems when using both an action and destination property on
the commandNavigationItem component. When both are used any actions fail to
fire. I looked at the generated html and the href appears to be empty when
the destination is included?
a href= name=form:page:3:cmdNavItem id=form:page:3:cmdNavItem
If I remove the destination property I recieve:
a href=#
onclick=submitForm('form',0,{source:'form:page:3:cmdNavItem'});return
false; name=form:page:3:cmdNavItem id=form:page:3:cmdNavItem
According to the documentation, If both attributes are set on an itemNode,
the destination attribute takes precedence and a GET is done.
Any help is appreciated,
Jim Dolinski
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-956) In order to be extended correctly XMLMenuModel needs to provide API to its viewIdFocusPathMap.
In order to be extended correctly XMLMenuModel needs to provide API to its viewIdFocusPathMap. -- Key: TRINIDAD-956 URL: https://issues.apache.org/jira/browse/TRINIDAD-956 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.6-core Reporter: Gary Kind Fix For: 1.2.7-core The XMLMenuModel keeps a map of of its focus paths to each node inside of a map called viewIdFocusPathMap. Users wanting to extend the the XMLMenuModel will need an api to this Map so that, especially if they want to obtain focus path maps to duplicate pages/nodes within the tree that can be reached through multiple paths. The current XMLMenuModel does not provide this. This is a very simple fix but necessary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-954) Added changes to all the Trinidad components, converters, and validators to take advantage of the abiltity to put code usage examples in the tagdocs
[ https://issues.apache.org/jira/browse/TRINIDAD-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569370#action_12569370 ] Gary Kind commented on TRINIDAD-954: Yes that is fine. FYI, the changes to the .xml files will still compile and cause no problems, even if they go in before a new plugin release. The current plugins do not handle the example code that is in the .xml files now, so my changes will cause no problems. Added changes to all the Trinidad components, converters, and validators to take advantage of the abiltity to put code usage examples in the tagdocs Key: TRINIDAD-954 URL: https://issues.apache.org/jira/browse/TRINIDAD-954 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.6-core Reporter: Gary Kind Priority: Minor Attachments: trinidad-build.patch To go with TRINIDAD-953, this issue includes changes to all the Trinidad components, converters, and validators to take advantage of the abiltity to put code usage examples in the tagdocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-954) Added changes to all the Trinidad components, converters, and validators to take advantage of the abiltity to put code usage examples in the tagdocs
Added changes to all the Trinidad components, converters, and validators to take advantage of the abiltity to put code usage examples in the tagdocs Key: TRINIDAD-954 URL: https://issues.apache.org/jira/browse/TRINIDAD-954 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.6-core Reporter: Gary Kind Priority: Minor To go with TRINIDAD-953, this issue includes changes to all the Trinidad components, converters, and validators to take advantage of the abiltity to put code usage examples in the tagdocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-953) Support for Code Examples in Trinidad Components, Validators, and Converters tagdocs
Support for Code Examples in Trinidad Components, Validators, and Converters tagdocs Key: TRINIDAD-953 URL: https://issues.apache.org/jira/browse/TRINIDAD-953 Project: MyFaces Trinidad Issue Type: New Feature Reporter: Gary Kind Attachments: trinidad-maven.patch Tag docs generated by the maven-faces-plugin and maven-tagdoc-plugin did not include the ability to easily have code usage examples. With the changes I have made this is now easily done. For example (pardon the pun), in a component xml file: faces-config component ... component-extension mfp:long-description ... /mfp:long-description mfp:example mfp:source-descriptionThis example shows how to use /mfp:source-description mfp:source-code ![CDATA[ tr:form tr:inputText id=test label=myLabel/ ... /tr:form ]] /mfp:source-code /mfp:example -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-919) maven-jdev-plugin does not evaluate !DOCTYPE tag correctly for taglib (.tld) files
maven-jdev-plugin does not evaluate !DOCTYPE tag correctly for taglib (.tld) files Key: TRINIDAD-919 URL: https://issues.apache.org/jira/browse/TRINIDAD-919 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gary Kind Some .tld files contain a !DOCTYPE tag for taglibs at the top of the file. The com.sun.org.apache.xerces parser attempts to connect to the systemid in the DOCTYPE tag, which is: !DOCTYPE taglib PUBLIC -//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd; The connection attempt fails and thus the NoRouteToHostException. After a lot of searching on the Web, I found a valid workaround for this problem. It appears that a lot of people are using this same workaround because they too are getting exceptions caused by the parser not being able to connect to the URL of the DOCTYPE tag. And yes I have called factory.setValidating(false). That prevents validation, but it does not prevent the parser from trying to connect. There does not seem to be any other way around this problem AND it works great. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-907) Current maven-jdev-plugin does not handle nested maven projects whose packaging is pom
Current maven-jdev-plugin does not handle nested maven projects whose packaging is pom Key: TRINIDAD-907 URL: https://issues.apache.org/jira/browse/TRINIDAD-907 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gary Kind So if a root project whose packaging is pom has a child project whose packaging is also pom the resulting root JDeveloper workspace file, e.g. trinidad.jws, is incorrect. References to this child project refer to it as a JDeveloper project, e.g. trinidad-example.jpr, instead of a JDeveloper workspace file, i.e. trinidad-example.jws, as it should be. This patch addresses and fixes this problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-893) Added 3 new parameters to the maven-jdev-plugin.
Added 3 new parameters to the maven-jdev-plugin. Key: TRINIDAD-893 URL: https://issues.apache.org/jira/browse/TRINIDAD-893 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Gary Kind Attachments: maven-jdev-plugin2.patch 1. Added 3 new parameters the jdev:jdev goal: * compiler: so that the default compiler (which is Ojc) can be changed to Javac * makeProject: so that the Make Project checkbox can be checked and a project will compile before run. The default is false. * runTarget: set the default run target so it does not have to be manually. This is particularly useful for adf-richclient-test 2. Changed it so that libraries specified in a pom file will be added to the default libraries, JSP Runtime JSF 1.2. In the current version, if you wanted to add libraries in your pom file, you would have to also include these default libraries in your list. I did not like this, so I changed it. 3. As part of my project to fully document our plugins, I went through all of the parameters and documented them so that meaningful plugin documentation is generated for the maven-jdev-plugin. I ran 'mvn site:site' on trinidad-maven/trunk so see what kind of documentation would get generated. The maven-jdev-plugin now looks great and one can actually get some useful information out of it.I also went on the internet and was able to find the current documentation at. This documentation gets generated regularly, so as soon as my new code gets rolled into open-source (Matthias), the documentation for the maven-jdev-plugin will get updated and be meaningful. 4. Removed method replaceDemoConfiguration() which is a hack. It currently does nothing that is not already done and should have been removed in the last version of the maven-jdev-plugin. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-871) Without this new project.xml, the maven-jdev-plugin requires project migration on each usage.
Without this new project.xml, the maven-jdev-plugin requires project migration on each usage. - Key: TRINIDAD-871 URL: https://issues.apache.org/jira/browse/TRINIDAD-871 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.5-plugins Reporter: Gary Kind Attachments: jdev-plugin.patch JDev had a bug where 2 of the installed components version breadcrumbs changed on each new build of JDev. This made it impossible for the maven-jdev-plugin's project.xml file, used to create a .jpr (jdev project) file, to be used in JDev without migration to the present version. In a large workspace with multiple projects, this is very time-consuming. The major goal of the maven-jdev-plugin is to avoid this time-consuming migration. JDev has now fixed this problem and the attached patch file corrects the maven-jdev-plugin's project.xml file so that the migration does not occur. This patch is really a MUST in the next version of the maven-jdev-plugin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-851) JDev Plugin - configure the release
[
https://issues.apache.org/jira/browse/TRINIDAD-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549460
]
Gary Kind commented on TRINIDAD-851:
Actually Aino, you must using and looking at the old version of
JDeveloperMojo.java. The current version that was just put into 1.2.5 has this
code:
/**
* @parameter expression=${jdev.release} default-value=10.1.3.0.4
*/
private String release;
The patch you added in this issue is:
/**
* @parameter expression=10.1.3.0.4
* @required
- * @readonly
*/
private String release;
indicating you are looking at the old version of the JDev Plugin. That is also
why the jdev.release property is not working for you. You should probably
close this issue since the current plugin already does what you want.
JDev Plugin - configure the release
---
Key: TRINIDAD-851
URL: https://issues.apache.org/jira/browse/TRINIDAD-851
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Plugins
Affects Versions: 1.2.6-plugins
Reporter: Aino Andriessen
Priority: Minor
Attachments: JDeveloperMojo.patch
Be able to configure which JDeveloper version the project files are generated
for. Especially meaningful with the upcoming 11g release.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-177) JDev plugin - compiler configuration
[ https://issues.apache.org/jira/browse/TRINIDAD-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549488 ] Gary Kind commented on TRINIDAD-177: I strongly disagree with this. You are breaking desired behavior in the JDev plugin instead of having the business components wizards fix their extension to JDev to remove .java and remove the reverse filter. This is just wrong. Unfortunately, for the business components wizards, you may have to do manual changes before compiling. JDev plugin - compiler configuration Key: TRINIDAD-177 URL: https://issues.apache.org/jira/browse/TRINIDAD-177 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Affects Versions: 1.0.1-incubating-plugins-SNAPSHOT Environment: Windows XP, JDeveloper 10.1.3.1 (.0.3984) Reporter: Aino Andriessen Assignee: Matthias Weßendorf Fix For: 1.2.5-plugins Attachments: project.xml.10.1.3.0.4.patch The compiler configuration of the plugin conflicts with the business components wizard. The jdev plugin configures a reverse filter on the 'Copy File Types to Output Directory' and only adds .java on this list. However, when you create a new business component (actually only the first in a project), a bunch of extensions are added to this list that now contains the following entries: .java;.xml;.jpx;.xcfg;.xml;.xml;.xml;.xml;.xml;.xml;.xml When you try to test the model application an exception is raised (I am sorry for the french text) that it cannot find the Model.jpx file: JBO-30003: Le pool d'applications (.10F6E9C218F) n'a pas réussi à extraire (check out) un module d'application en raison de l'exception suivante : oracle.jbo.JboException: JBO-29000: JBO-29000: JBO-25222: Impossible de créer le module dapplication. ... javax.naming.NamingException [Root exception is oracle.jbo.NoXMLFileException: JBO-26001: Fichier XML introuvable pour le conteneur /Model.jpx] This is as expected, because that file is not copied to the classpath (due to the Reverse Filter), but highly unwanted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-846) JDev plugin - compiler configuration 11g
[ https://issues.apache.org/jira/browse/TRINIDAD-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549484 ] Gary Kind commented on TRINIDAD-846: I strongly disagree with this. First off, I am looking at the 10.1.3.0.4 JDev plugin's project.xml file and the reverse filter is still there. Second, the reverse filter totally makes sense. It is saying copy everything over to the output directory except the .java files. Since the .java files are already in a source area, why copy them over to the same place your class files are? I agree that this may be desirable in some cases, but those are the exceptions rather than the rule. The default options are in place for what is done most of the time. And thirdly, if the ADF BC Wizards don't recognize the reverse filter, then that is a bug in the ADF BC Wizards, not in the JDev Plugin. We do not want to workaround a bug in some other component by removing a desired behavior in the JDev plugin. I am sorry but we cannot implement this change. JDev plugin - compiler configuration 11g - Key: TRINIDAD-846 URL: https://issues.apache.org/jira/browse/TRINIDAD-846 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Affects Versions: 1.2.5-plugins Reporter: Aino Andriessen Priority: Minor Attachments: project.xml.11.1.1.0.0.patch The compiler configuration in the 11g 'template' project.xml file should not contains a so called reversed filter, because the JDeveloper ADF BC wizards do not take the reverse filter into account. This has been fixed (patched) on the 10.1.3.0.4 project file, but not yet on the 11g version. The same patch cannot be spplied because the jpr structure has been changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-846) JDev plugin - compiler configuration 11g
[ https://issues.apache.org/jira/browse/TRINIDAD-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549543 ] Gary Kind commented on TRINIDAD-846: Another question. the JDev Plugin is only intended to be used for maven projects to create JDev Workspace and projects. Are the ADF BC Wizards in maven? I don't understand how you would be using the JDev plugin on ADF BC Wizards? It is not an Open-source project, I don't believe. JDev plugin - compiler configuration 11g - Key: TRINIDAD-846 URL: https://issues.apache.org/jira/browse/TRINIDAD-846 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Affects Versions: 1.2.5-plugins Reporter: Aino Andriessen Priority: Minor Attachments: project.xml.11.1.1.0.0.patch The compiler configuration in the 11g 'template' project.xml file should not contains a so called reversed filter, because the JDeveloper ADF BC wizards do not take the reverse filter into account. This has been fixed (patched) on the 10.1.3.0.4 project file, but not yet on the 11g version. The same patch cannot be spplied because the jpr structure has been changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-855) ClassLoaderResourceLoader.findResource can create a path with double forward slash //
ClassLoaderResourceLoader.findResource can create a path with double forward slash // --- Key: TRINIDAD-855 URL: https://issues.apache.org/jira/browse/TRINIDAD-855 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gary Kind Priority: Trivial Attachments: trunk.patch private method _getResourcePrefix() takes a String representing the root package of the resource and replaces all '.' with '/'. If the rootPackage String ends with a dot, e.g. root., _getResourcePrefix will return root/ which becomes the private String _resourcePrefix. The method findResource() does not check for this ending forward slash and simply prepends it to the path. In fact, if path does not start with a '/', a '/' is prepended before _resourcePrefix is prepended. Either way, the resulting path can contain 2 forward slashes in a row. While this does not result in any problems, the patch corrects this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-851) JDev Plugin - configure the release
[ https://issues.apache.org/jira/browse/TRINIDAD-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548825 ] Gary Kind commented on TRINIDAD-851: The plugin's release can already be set by using the jdev.release property. In a pom file it would look like: properties jdev.release11.1.1.0.0/jdev.release /properties JDev Plugin - configure the release --- Key: TRINIDAD-851 URL: https://issues.apache.org/jira/browse/TRINIDAD-851 Project: MyFaces Trinidad Issue Type: Improvement Components: Plugins Affects Versions: 1.2.6-plugins Reporter: Aino Andriessen Priority: Minor Attachments: JDeveloperMojo.patch Be able to configure which JDeveloper version the project files are generated for. Especially meaningful with the upcoming 11g release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-846) JDev plugin - compiler configuration 11g
[ https://issues.apache.org/jira/browse/TRINIDAD-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548818 ] Gary Kind commented on TRINIDAD-846: When you create a .jpr file, can it be loaded into JDev without migration? That is the goal. JDev plugin - compiler configuration 11g - Key: TRINIDAD-846 URL: https://issues.apache.org/jira/browse/TRINIDAD-846 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Affects Versions: 1.2.5-plugins Reporter: Aino Andriessen Priority: Minor Attachments: project.xml.11.1.1.0.0.patch The compiler configuration in the 11g 'template' project.xml file should not contains a so called reversed filter, because the JDeveloper ADF BC wizards do not take the reverse filter into account. This has been fixed (patched) on the 10.1.3.0.4 project file, but not yet on the 11g version. The same patch cannot be spplied because the jpr structure has been changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-843) Jdev plugin - Nullpointer exception
[
https://issues.apache.org/jira/browse/TRINIDAD-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546481
]
Gary Kind commented on TRINIDAD-843:
The local tag libraries, if any should be located in your maven project's
${basedir}/src/main/webapp/WEB-INF, not WEB-INF/lib.
${basedir}/src/main/webapp/WEB-INF is the maven standard generic location for
its webapp projects. That being said I do have a bug in the TRINIDAD-808 that
needs to be fixed.
Jdev plugin - Nullpointer exception
---
Key: TRINIDAD-843
URL: https://issues.apache.org/jira/browse/TRINIDAD-843
Project: MyFaces Trinidad
Issue Type: Bug
Components: Plugins
Affects Versions: 1.2.5-plugins, 1.2.4.1-plugins
Environment: Windows
Reporter: Aino Andriessen
When running the jdev plugin, a nullpointer occurs with the (new) code for
handling taglibs. The WEB-INF\lib directory of my projects are empty or are
not present at all.
Stacktrace :
[INFO]
[INFO] Building Default ADF Faces application : jdevplugin
[INFO]task-segment: [jdev:jdev]
[INFO]
[INFO] Preparing jdev:jdev
[INFO] No goals needed for project - skipping
[INFO] [jdev:jdev]
[INFO] Generating JDeveloper 10.1.3.0.4 workspace: jdevplugin
[INFO]
[INFO] Building The generated jdevplugin model project
[INFO]task-segment: [jdev:jdev]
[INFO]
[INFO] Preparing jdev:jdev
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [jdev:jdev]
[INFO] Generating JDeveloper 10.1.3.0.4 Project jdevplugin-model
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.replaceLocalTagLibraries(JDeveloperMojo.java:904)
at
org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.replaceTagLibraries(JDeveloperMojo.java:1113)
at
org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.generateProject(JDeveloperMojo.java:398)
at
org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.generateProject(JDeveloperMojo.java:315)
at
org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.execute(JDeveloperMojo.java:227)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
[INFO] Total time: 3 seconds
[INFO] Finished at: Wed Nov 28 22:02:12 CET 2007
[INFO] Final Memory: 3M/7M
[INFO]
D:\tmp\test_projects\jdevplugin
--
This message is automatically generated by JIRA.
-
You can reply to this email to
[jira] Created: (TRINIDAD-808) After loading a JDeveloper workspace/project created by maven-jdev-plugin, manual steps are no longer required.
After loading a JDeveloper workspace/project created by maven-jdev-plugin, manual steps are no longer required. --- Key: TRINIDAD-808 URL: https://issues.apache.org/jira/browse/TRINIDAD-808 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Gary Kind Fix For: 1.2.4-plugins The maven-jdev-plugin creates JDeveloper workspace and projects from maven projects. The goal is to be able to load them directly into JDeveloper and run. In the past, time-consuming manual steps were required after loading them into JDeveloper. With these changes in maven-jdev-plugin, these manual steps are no longer required. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-758) failure in parsing of sub menu models (sharedNodes) results in root menu tree not being created. Bad sub menu models should just be skipped.
[ https://issues.apache.org/jira/browse/TRINIDAD-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533196 ] Gary Kind commented on TRINIDAD-758: After code review by Jeanne Waldman, I have attached 2 new patch files that should be used. failure in parsing of sub menu models (sharedNodes) results in root menu tree not being created. Bad sub menu models should just be skipped. - Key: TRINIDAD-758 URL: https://issues.apache.org/jira/browse/TRINIDAD-758 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gary Kind Attachments: 122Branch.patch, 122Branch1.patch, trunk.patch If there is any kind of parsing error in a sub menu model's xml metadata OR the sub menu model creation returns a null XMLMenuModel, the creation of the root menu tree will break and not be created. This should not happen. The offending sub menu model should be skipped and the root menu tree should go on and be created without the offending sub menu model. I have put code especially in MenuContentHandlerImpl.startElement, where a submenu model is created upon encountering a sharedNode in the xml metadata, that handles a null XMLMenuModel or a sub menu model that had a parsing exception. In either case, an exception is thrown but the root menu tree goes on being created. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-758) failure in parsing of sub menu models (sharedNodes) results in root menu tree not being created. Bad sub menu models should just be skipped.
[ https://issues.apache.org/jira/browse/TRINIDAD-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533221 ] Gary Kind commented on TRINIDAD-758: Fixed one, minor compile issue. Attached 2 new patch files. failure in parsing of sub menu models (sharedNodes) results in root menu tree not being created. Bad sub menu models should just be skipped. - Key: TRINIDAD-758 URL: https://issues.apache.org/jira/browse/TRINIDAD-758 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gary Kind Attachments: 122Branch.patch, 122Branch1.patch, trunk.patch, trunk1.patch If there is any kind of parsing error in a sub menu model's xml metadata OR the sub menu model creation returns a null XMLMenuModel, the creation of the root menu tree will break and not be created. This should not happen. The offending sub menu model should be skipped and the root menu tree should go on and be created without the offending sub menu model. I have put code especially in MenuContentHandlerImpl.startElement, where a submenu model is created upon encountering a sharedNode in the xml metadata, that handles a null XMLMenuModel or a sub menu model that had a parsing exception. In either case, an exception is thrown but the root menu tree goes on being created. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-758) failure in parsing of sub menu models (sharedNodes) results in root menu tree not being created. Bad sub menu models should just be skipped.
failure in parsing of sub menu models (sharedNodes) results in root menu tree not being created. Bad sub menu models should just be skipped. - Key: TRINIDAD-758 URL: https://issues.apache.org/jira/browse/TRINIDAD-758 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gary Kind If there is any kind of parsing error in a sub menu model's xml metadata OR the sub menu model creation returns a null XMLMenuModel, the creation of the root menu tree will break and not be created. This should not happen. The offending sub menu model should be skipped and the root menu tree should go on and be created without the offending sub menu model. I have put code especially in MenuContentHandlerImpl.startElement, where a submenu model is created upon encountering a sharedNode in the xml metadata, that handles a null XMLMenuModel or a sub menu model that had a parsing exception. In either case, an exception is thrown but the root menu tree goes on being created. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-734) EL expression used for node labels gets evaluated only once
EL expression used for node labels gets evaluated only once --- Key: TRINIDAD-734 URL: https://issues.apache.org/jira/browse/TRINIDAD-734 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gary Kind The first time the actionListener calls the getLabel() method for a menu node, if the stored label is an EL expression, it gets evaluated correctly and the returned String is set on the label. However, before this fix, the evaluated String was set as the label for the menu item node. This means that the next time the getLabel() method is called, the EL expression is not again evaluated as it should. The String from the first time it was evaluated is returned instead. This is incorrect as it prevents an EL expression from changing the label dynamically. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-718) MenuNode.getLabel() does not handle complex EL expressions correctly
MenuNode.getLabel() does not handle complex EL expressions correctly Key: TRINIDAD-718 URL: https://issues.apache.org/jira/browse/TRINIDAD-718 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gary Kind Private method _evalElStr(), which is called from MenuNode.getLabel(), in the case of a Resource Bundle EL expression, is used to insert a Unique Id in the EL expression to indentify the correct Resoure Bundle. If the EL expression is not a Resource Bundle, the EL String is just passed on to be evaluated. In the latter case, _bundleKey is null which seems to give the replaceFirst method of java.lang.String problems. This results in an NPE, where the documentation says it should result in a PatternSyntaxException. Checking for a null _bundleKey solves the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-718) MenuNode.getLabel() does not handle complex EL expressions correctly
[ https://issues.apache.org/jira/browse/TRINIDAD-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Kind updated TRINIDAD-718: --- Status: Patch Available (was: Open) MenuNode.getLabel() does not handle complex EL expressions correctly Key: TRINIDAD-718 URL: https://issues.apache.org/jira/browse/TRINIDAD-718 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gary Kind Private method _evalElStr(), which is called from MenuNode.getLabel(), in the case of a Resource Bundle EL expression, is used to insert a Unique Id in the EL expression to indentify the correct Resoure Bundle. If the EL expression is not a Resource Bundle, the EL String is just passed on to be evaluated. In the latter case, _bundleKey is null which seems to give the replaceFirst method of java.lang.String problems. This results in an NPE, where the documentation says it should result in a PatternSyntaxException. Checking for a null _bundleKey solves the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-101) Menu Model is not created if its tree is empty
Menu Model is not created if its tree is empty -- Key: TRINIDAD-101 URL: https://issues.apache.org/jira/browse/TRINIDAD-101 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gary Kind Attachments: trunk.patch If the menu metadata used to create a menu model's tree has no nodes (i.e. only menu.../menu), the menu model is not created and an exception to be thrown. However, if the any methods in the model methods are called subsequently, an NPE is the result and shown in the browser. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-101) Menu Model is not created if its tree is empty
[ https://issues.apache.org/jira/browse/TRINIDAD-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Kind updated TRINIDAD-101: --- Status: Patch Available (was: Open) Menu Model is not created if its tree is empty -- Key: TRINIDAD-101 URL: https://issues.apache.org/jira/browse/TRINIDAD-101 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gary Kind Attachments: trunk.patch If the menu metadata used to create a menu model's tree has no nodes (i.e. only menu.../menu), the menu model is not created and an exception to be thrown. However, if the any methods in the model methods are called subsequently, an NPE is the result and shown in the browser. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-102) Attempt to get the value of a custom property from a node that has no custom properties causes NPE
Attempt to get the value of a custom property from a node that has no custom properties causes NPE -- Key: TRINIDAD-102 URL: https://issues.apache.org/jira/browse/TRINIDAD-102 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gary Kind Attachments: trunk.patch If XMLMenuModel.getCustomProperty() is called, the code gets a map from the node that contains its custom properties. If the node has no custom properties, the map returned is null. That case is not checked for, assuming the map to be valid and non-empty, causing an NPE. The attached patch file fixes this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-102) Attempt to get the value of a custom property from a node that has no custom properties causes NPE
[ https://issues.apache.org/jira/browse/TRINIDAD-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Kind updated TRINIDAD-102: --- Status: Patch Available (was: Open) Attempt to get the value of a custom property from a node that has no custom properties causes NPE -- Key: TRINIDAD-102 URL: https://issues.apache.org/jira/browse/TRINIDAD-102 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gary Kind Attachments: trunk.patch If XMLMenuModel.getCustomProperty() is called, the code gets a map from the node that contains its custom properties. If the node has no custom properties, the map returned is null. That case is not checked for, assuming the map to be valid and non-empty, causing an NPE. The attached patch file fixes this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-48) Created property that allows RenderKitTestCase to return a testCaseCount that only includes the actual test cases.
Created property that allows RenderKitTestCase to return a testCaseCount that only includes the actual test cases. -- Key: TRINIDAD-48 URL: https://issues.apache.org/jira/browse/TRINIDAD-48 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Gary Kind Current RenderKitTestCase.getTestCaseCount() returns a test case count that includes all the subtests in each test case. It is desirable to be able to have it return only the actual junit test cases. A new boolean system property is now in effect, trinidad.renderkit.junittests, that, when set to true, causes RenderKitTestCase.getTestCaseCount() to return only the actual junit test cases. The default value for this property is false, meaning that the current behavior is the default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
