Is it bug on JDev 10.1.3.1?

I tried to define a region using <af:regionDef> tag and registered that region in region-metadata.xml under WEB-INF directory in JDev 10.1.3 and it works fine.
When I created region-metadata.xml in WEB-INF directory in 10.1.3, I am able to see this file under ‘Resources’ directory as well.
But when I do the same thing with JDev 10.1.3.1, it is not working at all and I am not able to see region-metadata.xml under ‘Resources’ directory when I created this file under WEB-INF directory.
1. Why doesn’t it work on JDev 10.1.3.1?
2. Why doesn’t region-metadata.xml appear under ‘Resources’ directory on JDev 10.1.3.1 as it does on JDev 10.1.3?
Thank you.
Message was edited by:
V.Piraba
null

It's probably a bug. I recommend you to use 10.1.3.0 if you depend on regions. But if you wannt to stick with 10.1.3.1, as temporary solutions, you can remove <regionDef tags in your region file and things should work ok. I hope this helps.

Similar Messages

Minor display bug in JDev 11g "View Annotation" with Subversion

Hi all,
A very minor visual display issue with the "View Annotations" feature of JDev 11g when using a Subversion repository. To reproduce, simply follow these steps:
1). Open up any source file and right-click in the editor; select Versioning -> View Annotation. The annotations will be shown, and if you right-click again, you will see a check-mark next to the "View Annotation" menu item.
2). Open another source file. Annotations are not shown. Right-click in the editor; you will see that "View Annotation" menu item displays a check-mark (even though annotations are not shown). Select Versioning -> View Annotation. Annotations are now shown, but you will see the check-mark is no longer displayed.
To summarize my analysis; it appears that "View Annotation" was intended to be a global setting (as indicated by the check-mark), but is actually implemented on a file-by-file basis. Obviously a very minor display bug not affecting functionality, but a bug nonetheless.
John

John,
I filed a bug
thanks
Frank

[Bug] Compiler bug in JDev 10.1.3.0.4 (SU5)

Hello,
I would like to report a bug with Java 5 compiler in JDev 10.1.3.0.4 (SU5) build JDEV_ADF_10.1.3_NT_030125.0900.3673 regarding covariant return types.
As of Java 5, it's now possible to override a method with a different return type as long as the new return type is a subclass of the overridden method's return type. JDeveloper compiler will manage that correctly (no compilation error), but will result in a java.lang.AbstractMethodError if the overriding definition come from an interface.
So the reproduction case is :
public interface Interface1 {
public Object myMethod();
public interface Interface2 extends Interface1 {
public String myMethod();
public abstract class AbstractInterface2 implements Interface2 {
public class MyClass extends AbstractInterface2 {
public String myMethod() {
return "Hello"!;
public static void main(String... args) {
Interface1 myObject = new MyClass();
myObject.myMethod();
}I did not test with other JDev version.
Regards,
Simon Lessard

quick workaround is to set project output directory to the WEB-INF/classes directory and compile the jsp from jdeveloper, oc4j then updates the loaded class file without re-compiling the jsp.
This works fine, but if I let OC4J try to compile the JSP problem still occurs, anyone have any ideas why either of these problems occur?

Bug in JDev 11g 11.1.1.0.2

In the context of the JavaBean XML Model "Overview" editor i JDev 11g 11.1.1.0.2:
When I add a validator and specify an appropriate text resource for the error message, JDev deletes my carefully authored description comment from the property resource bundle.

Hi, I am using Oracle supplied HR schema, table EMPLOYEES. I created EO on EMPLOYEES table. All the attributes show correctly as Persistent first.
Under Default Value section, I selected Radio Button "SQL" and entered valid Sql statement, Hit save button. I moved to next attribute, then I see. The previous attribute for which I entered Sql statement as default value, turned to Transient. But this is a Persistent attribute. It is not allowing me to change it back to Persistent.
Hope the above steps will help to reproduce the bug in your system.

View Link Bug! - JDEV Developers please read.

This has to be a bug. When I am done with my project for the day I check in the files into PVCS. After check in the files are deleted off my local drive. When I recheck out my project and do a rebuild on the project, I get several View link XML files that say that they are not correct. However when I pull them up in the editor and relink them, there is NO CHANGE to the XML file that stores the DEF. Below is a sample of one of the files. If I go into this view link with the visual editor and reselect the linking nodes, all is fine in JDEV.
Is this a bug that is being worked on for the next version?
SAMPLE
<?xml version='1.0' encoding='windows-1252' ?>
<!DOCTYPE ViewLink SYSTEM "jbo_03_01.dtd">
<ViewLink Name="RequestCauseLookupVL">
<DesignTime>
<Attr Name="_isCodegen" Value="true"/>
<Attr Name="_version" Value="10.1.3.36.73"/>
</DesignTime>
<ViewLinkDefEnd Name="RequestVO" Cardinality="1"
Owner="dataAccess.Request.RequestView" Source="true">
<AttrArray Name="Attributes">
<Item Value="dataAccess.Request.RequestView.CauseCd"/>
</AttrArray>
<DesignTime>
<Attr Name="_finderName" Value="RequestVO"/>
<Attr Name="_accessor" Value="true"/>
<Attr Name="_minCardinality" Value="1"/>
<Attr Name="_isUpdateable" Value="true"/>
<Attr Name="_entityAccessor" Value="true"/>
</DesignTime>
</ViewLinkDefEnd>
<ViewLinkDefEnd Name="ReqCause_LOV" Cardinality="1"
Owner="dataAccess.lov.ReqCause_LOV">
<AttrArray Name="Attributes">
<Item Value="dataAccess.lov.ReqCause_LOV.LookupId"/>
</AttrArray>
<DesignTime>
<Attr Name="_finderName" Value="ReqCause_LOV"/>
<Attr Name="_accessor" Value="true"/>
<Attr Name="_isUpdateable" Value="true"/>
<Attr Name="_entityAccessor" Value="true"/>
</DesignTime>
</ViewLinkDefEnd>
</ViewLink>

Hi Steve,
JDev appears to be updating the viewlink files. I have not edited any of them and they all have the timestamp of when i closed JDev last Friday:
-rw-rw-rw-   1 user     group        1236 Sep 1 16:45 ApprovalDetailsFkLink.xml
-rw-rw-rw-   1 user     group        1224 Sep 1 16:45 InvestigatorsFkLink.xml
-rw-rw-rw-   1 user     group        1260 Sep 1 16:45 MulticentreProjectsFkLink.xml
-rw-rw-rw-   1 user     group        1258 Sep 1 16:45 PrjWorklistItemsFkLink.xml
-rw-rw-rw-   1 user     group        1200 Sep 1 16:45 FieldBasedFKLink.xml
-rw-rw-rw-   1 user     group        1195 Sep 1 16:45 GmAnimalsFKLink.xml
-rw-rw-rw-   1 user     group        1225 Sep 1 16:45 HarmfulFKLink.xml
-rw-rw-rw-   1 user     group        1032 Sep 1 16:45 ObservationFKLink.xml
-rw-rw-rw-   1 user     group        1226 Sep 1 16:45 OtherInvestigatorsFKLink.xml
-rw-rw-rw-   1 user     group        1196 Sep 1 16:45 OtherPartiesFKLink.xml
-rw-rw-rw-   1 user     group        1028 Sep 1 16:45 PermitsFKLink.xml
-rw-rw-rw-   1 user     group        1206 Sep 1 16:45 ProjectPartiesFKLink.xml
-rw-rw-rw-   1 user     group        1042 Sep 1 16:45 RespInvestigatorsFkLink.xml
-rw-rw-rw-   1 user     group        1012 Sep 1 16:45 SurgeryFKLink.xml
-rw-rw-rw-   1 user     group        1190 Sep 1 16:45 TeachingFKLink.xmlthe CVS looks like this (August 24 was when i deleted them all from CVS and re-added them):
-r--r--r--    1 banstey dba          1347 Aug 24 09:51 ProjectPartiesFKLink.xml,v
-r--r--r--    1 banstey dba          1172 Aug 24 09:51 PermitsFKLink.xml,v
-r--r--r--    1 banstey dba          1337 Aug 24 09:51 OtherPartiesFKLink.xml,v
-r--r--r--    1 banstey dba          1367 Aug 24 09:51 OtherInvestigatorsFKLink.xml,v
-r--r--r--    1 banstey dba          1176 Aug 24 09:51 ObservationFKLink.xml,v
-r--r--r--    1 banstey dba          1399 Aug 24 09:51 PrjWorklistItemsFkLink.xml,v
-r--r--r--    1 banstey dba          1401 Aug 24 09:51 MulticentreProjectsFkLink.xml,v
-r--r--r--    1 banstey dba          1365 Aug 24 09:51 InvestigatorsFkLink.xml,v
-r--r--r--    1 banstey dba          1377 Aug 24 09:51 ApprovalDetailsFkLink.xml,v
-r--r--r--    1 banstey dba          1325 Aug 24 09:51 AnimalFKLink.xml,v
-r--r--r--    1 banstey dba          1331 Aug 24 09:51 TeachingFKLink.xml,v
-r--r--r--    1 banstey dba          1186 Aug 24 09:51 RespInvestigatorsFkLink.xml,v
-r--r--r--    1 banstey dba          1341 Aug 30 11:37 AnimalCareFKLink.xml,v
-r--r--r--    1 banstey dba          1341 Aug 30 11:38 FieldBasedFKLink.xml,vTimestamps of my associations are all over the place, which is consistent with the creation process.
Will do an unchanged commit and post the results.
regards,
Brenden

Bug in JDev 9.0.3.3: Adding new attributes

for me, it's seems to be a bug when:
- you have an existing view object with attributes of two EOs
- add new attributes from the EOs to the view object (in our case the column names are identical, JDev names them to TCN and TCN1 in the select-statement of the query)
- update of the query of the view object doesn't properly work as well as attribute mapping shows that my new attributes are transient
- removing all attributes from the view object and reassigning them again leads to a strange attribute mapping, i.e. now I have to set them again by manual.
Does anyone have the same experience with attribute removal and addtion of view objects?
Regards,
Stefan

Stefan,
I tried to reproduce it with my 9.0.3.3 (Build 1205) installation but wasn't successful. Here's what I did:
1. Create 2 entities
2. Create one VO based on the two
3. Run it
4. Edit the VO and add an attribute from the second entity having the same name
5. Run it
There must be something that you do differently from what I describe. Can you try to find ou what it is?
Frank

Bug in JDev 9.0.3.3 when using derived views

Hi,
I observed in JDev 9.0.3.3 the following behavior when
using derived views:
-I'm creating the view V1 based on the entity E1, add to it a couple of fields from E1 without generating Java files and close the wizard
-now I'm trying to create another view V1Ext that extends V1; when I try to add to V1Ext new fields from E1, the corresponding wizard button is disabled!!
Regards,
Dan

If you whant to add additional attributes from E1 you must now the "magic clue" to tell Jdeveloper to make E1 editable. As far as I know this is not a bug, but a "feature" of JDeveloper:
Do the following:
In the ViewObject Wizard go to the Entities page and mark the Entity E1 on the left and also mark Entity E1 on the right. Now you will realize that the Button ">" will be enabled. If you click on it you will be asked if you "want to update Entity E1 with E1..." (don't know the actual message, sorry). Press "OK" and you will be able to edit attributes of E1.
It's magic, isn't it?

Bug in JDev 9.0.3.3 when removing joined entities from a view

Hi,
I observed in JDev 9.0.3.3 the following behavior for views containing several joined entities:
     -I'm creating the view V1 based on the entity E1 and generate the row implementation java file with accessors (close wizard)
     -I'm joining a second entity E2 and add a couple of attributes from it (close wizard)
     -I'm removing the joined entity E2 (close wizard)
     -now look in the ViewRowImpl file: the accessors for the attributes from E2 are gone, but the accessor to E2, getE2(), is still there!
Regards,
Dan

Yes you are right. I've discoverd this bug too. Unfortunately this bug has some ugly effects when running the code, so this is not a litte quirk but I real bug! It is necessary fix the xml-files by hand after removing a joined entity from a view (At least I didn't find another way to fix this).

Bad bug crashes JDev 10.1.3 consistently during XML editing

This bug is very easy to reproduce (which I've done on Max OS X and Windows XP):
In JDev, create a new XML document.
Enter the following under the auto-generated <?xml line:
<!DOCTYPE beans PUBLIC "-
After typing the "-" the IDE will get cranky and hang itself forever.
For the curious, this doctype relates to the Spring framework...

Hi Robert,
Thanks for posting this. It's a known bug in the preview release (I coincidentally ran into this problem a number of weeks ago while also using Spring and reported it). The bug has been fixed in our internal development builds and therefore will be resolved in 10.1.3 production.
In the meantime, you can avoid the problem by pasting the whole doctype declaration into the code editor rather than typing it manually.
Thanks,
Brian

JDev903 custom tag (bug?)-JDev Team please respond

JDeveloper is continually hanging while working with custom tags. For example, I will select Add Tag and nothing will happen and JDeveloper stops responding. If I go to End Task, I am told that JDeveloper is waiting for a response, but by then JDev is just a gray window. This behavior becomes more frequent after a change, i.e. change a tag name, try to delete a tag or library. In fact, I have had to completely start over in the creation of a tag library when I notice a necessary change within a tag due to the hanging and disappearance of menu items. Please see previous post, Re: 10.1.3.1 xpath-functions.xml
Please look into this issue. Our team feels that custom tags could be a valuable tool, but we are RAPID and we don't have time to constantly shut-down and restart our IDE.
Thanks,
Deb

David,
One thing to try would be JPublisher from the command line. If your problem persists with JPublisher from the command line, then the bug needs to be filed against that product. If not, then the problem is with us.
In either case, please post your code so we can try to reproduce the error.
The JPublisher command line facility is documented in the JPublisher User's Guide, available from the Oracle8i 8.1.6 documentation pages on OTN.
Thanks!

Bug? JDev Doesn't Remove From CVS

Has anyone had any problems removing from cvs? I'll remove a view object from cvs, and then erase from disk. I then go out and check the file system where the cvs repository resides and these files still exist. When I do a full checkout into a new workspace these files show up in the project again. Is this a bug?
-Brian

hi,
i am having the same problem when removing a file via cvs. i did removing as follows:
removing the file via 'Versioning - Remove...'.
the messages log shows the proper cvs command 'cvs remove -lf filename'
the 'uncommitted files' view shows the file with status 'scheduled for removal' but the file is not selectable and all commit buttons remain disabled.
after pressing 'save all' the file disapears from the uncommitted files view.
now the project file appears in the uncommitted files view with status modified and the 'commit all' button is enabled (but in the Versioning menu the 'commit...' entry is still disabled).
pressing 'commit all' now does not remove the file from the cvs repository.
after updating the project from cvs shows the previously removed file again with status 'scheduled for removal'
jdev version: 9.0.5.2
os: Windows XP sp1
cvs client: cvsnt 2.0.41a
i have tested the removal via cvs command line and it worked as expected.
i hope this description can help to reproduce the problem.
regards
robert

Bug in JDev 11g: clicking "Run" button won't run active file

Hi everybody.
If you start a new Application in Oracle JDeveloper 11g and start creating Java classes, at some point you're bound to create a main() function in one of them to ensure everything is working correctly, even if that class is not your application entry point.
The problem is that, once you run it the first time, JDev 11g will always attempt to run that original class instead of the file you're currently working on.
More info:
- This only happens with the "Run" and "Debug" toolbar buttons and menu items, the keyboard shortcuts (Ctrl-F11 and such) work as expected.
- The checkbox labeled "Attempt to Run Active File Before Default" in the Launch Settings is selected (The "Default Run Target" textbox is empty).
I downloaded the JDev 11g version that came WITHOUT a JDK and I'm running Java version 1.6.0_07 on Windows XP.
Thanks in advance for any help.

More info on the subject:
Oracle JDev 11g seems to be unable to detect that there is an active file at all! This is evidenced by the fact that all of the External Tools are inactive at all times.
Is it JDev's fault, or is it the installed JDK's?

Bug? Jdev 10g 10.1.2 and UI Editor

I stumbled upon this while making a form for my application, but it is easily recreateable with a simple JFrame. I'll explain the steps to get there, and then what's wrong.
Make a new JFrame class. Using the UI editor, add a JPanel to the Frame. Make the JPanel big enough to add something to it. Change the Panel's layout to XYLayout. Add any component. Notice how when you click and drag the outline of the component appears where the component will be upon release.
Now add a TitledBorder to this panel. Now click and drag the component. The outline now appears roughly 10-15 pixels above the mouse cursor. Upon release, the component appears where the cursor is, not where the outline was.
This makes it very difficult to design with the XYLayout. The only workaround I've come up with is to leave the titling until the components are placed, and then add the border.
Message was edited by:
spaist

It is a bug. I have logged bug #4529733 to track the issue.

(Bug?) JDev 9.0.3 / UI Debugger, no representation of JDialog within UI Tre

Hello,
When you run a project using the UI Debugger, the opened window's components are represented within a UI Tree.
If you run a JFrame you can see its components within the UI Tree. Also the components of JFrames that are opened through the original JFrame are represented within the UI Tree after applying a snapshot.
But if you open a JDialog through the original JFrame, the JDlg's components can't be seen within the UI Tree!
My questions concering this problem are:
- Is there a reason why JDlg's components aren't represented?
- Is this perhaps a known bug?
- Are there special ways to treat a JDialog when run by UI Debugger to make its components being represented?
Best regards, Raffael Vogler

Nobody able to answer my questions?
Unbelievable!
I am sure, that YOU know the answer or that you know somebody who knows at least somebody who knows the answer or could at least give me a hint!
Best regards, Raffael Vogler

BUG in JDev 9033? Also see thread: BC4JContext in Servlets

When I was trying to enter the properties for the Action element in struts config file, I could not do so using the Struts Configuration Editor dialog box...and I think that was why the properties got skipped.
Here is the problem (I am using JDeveloper v9033):
1] Right click struts-config and choose Edit Struts-Config.
2] Click on Action Mappings element in the list box
3] Select one of the Action Mappings (or enter a new one)
4] Click on the properties tab. At this point if click on Add a new row is added. The property column contains a drop down list box and won't let me enter values such as "application", "viewobject", "releasemode"...All I see in the list are "applicationConfig", "attribute", "forward", "include", etc...
To get around this problem I entered the 3 elements that I mentioned bypassing the Config Editor dialog box.
Is this a bug? or do I need to use it in a different fashion????

The source was removed from the released product when the datatags were deprecated in the 10.1.3 release, but are still available as part of the complete ADF source code bundle you can request through Worldwide Support on Metalink.
That said, I just diff-ed the source of that class from the 10.1.2.2 release with the ones from the 10.1.3.0 and 10.1.3.1 release and the source is identical, so you can use the version from 10.1.2 that you have if that is the quickest path to the finish line for you.

Is it bug on JDev 10.1.3.1?

Similar Messages

Maybe you are looking for