Bug report (easy to fix)

The following exception was printed on screen, but not
thrown to program. So, the program does not know
what happed:
java.lang.IllegalStateException: Monitorable component can not be registered because admin service
as not been initialized.
at com.iplanet.ias.admin.monitor.MonitoringHelper.registerORBMonitoringMBean(Unknown Source
at com.iplanet.ias.admin.monitor.MonitoringHelper.registerSystemORBMonitoringMBean(Unknown
ource)
at com.sun.enterprise.util.ORBManager.initializeORBMonitoring(Unknown Source)
at com.sun.enterprise.util.ORBManager.init(Unknown Source)
at com.sun.enterprise.naming.SerialInitContextFactory.<init>(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java
39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorI
pl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:296)
at java.lang.Class.newInstance(Class.java:249)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:649)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243)
at javax.naming.InitialContext.init(InitialContext.java:219)
at javax.naming.InitialContext.<init>(InitialContext.java:175)
at com.acelet.s.i.if(Unknown Source)
at com.acelet.s.i.a(Unknown Source)
at com.acelet.s.ap.run(Unknown Source)
at java.lang.Thread.run(Thread.java:536)

Hi Judy,
I send a simple test program to [email protected] You can
reproduce this bug from that program.
NOTE: this bug report is for the way you handle the exception. The resean I sent test program to [email protected] was to find the root of the problem.
It would be appreciated if both of the problems be fixed.

Similar Messages

Reader stops working when newest GTK2.0 installed - bug report and proposed fix

Adobe Reader 7.0.9 (Linux i386) stopped working when I installed a batch of updates on Xubuntu Feisty Fawn (7.04). The updates included GTK 2.0, version 2.10.11. The symptom was that upon startup, Reader ended up in a seemingly infinite loop, printing out "expr: syntax error" (when started from terminal emulator). A few debug "echo"'s revealed that the loop concerned function get_gtk_file_ver().
The bug itself is on line 418. The original line is as follows:
echo $mfile| sed 's/libgtk-x11-$[0-9]*$.0.so.0.$[0-9]$00.$[0-9]*$\|$.*$/\1\2\3/g'
- note that there is no '*' in the middle number-matching regexp, so the full expression matches only strings in which the "middle" group is 100, 200, ..., 900.
At this point in the execution, $mfile contains the name of the gtk library .so, in this case, libgtk-x11-2.0.so.0.1000.11. In prior versions (e.g. 2.8.20, which is the current version in Ubuntu Dapper Drake LTS), the minor version had only one digit, and the regexp matched. When the minor version got incremented to two digits, the regexp no longer match because of the missing '*'! As an additional bonus, somehow this leads to the infinite loop (which is *not* good).
A working fix is to add the missing '*' into the regexp. I'd say that a lot of Linux users will be tripping on this issue soon, at least those who keep current on security updates.
I found no sensible way to contact the developers, i.e. a way that wouldn't have to pass a gazillion of customer-service and tech support people, who are most likely just as unaware of the issue as the users...
I hope this issue will be fixed ASAP - after all, it's only one added character, and that'll save a lot of users a lot of hassle.
(and btw, to have the intended effect, the dots in the sed expression should all be escaped with a backslash - now e.g. "libgtk-x11-2.0.sog0.1000.11" matches the sed regexp as well as "libgtk-x11-2.0.so.0.1000.11", but this probably isn't too critical...)

The solutions provided here work, but by accident. The script compares 2104 (2.10.4) to 240 (2.4.0) and sees that it's greater. Adobe will have problems in future releases if the minimum GTK release is, say, 2.10.4 and the user has 2.4.0.
I've crafted a more elegant solution, shown here in "patch" format. I think the reformatting and tab elimination done by HTML will preclude you from pasting this into a file and running "patch", but it's pretty easy to read and is short...
--- /usr/local/Adobe/Acrobat7.0/bin/acroread~ 2007-01-05 14:56:39.000000000 -0500
+++ /usr/local/Adobe/Acrobat7.0/bin/acroread 2007-08-03 09:33:08.000000000 -0400
@@ -409,13 +409,13 @@ get_gtk_file_ver()
fi
mfile=`basename $ifile`
- echo $mfile | grep -q "libgtk-x11-$[0-9]*$.0.so.0.$[0-9]*$.$[0-9]*$" 2>/dev/null
+ echo $mfile | grep -q "libgtk-x11-$[0-9]*$\.0\.so\.0\.$[0-9]*$\.$[0-9]*$" 2>/dev/null
if [ $? -ne 0 ]; then
return 1
fi
- echo $mfile| sed 's/libgtk-x11-$[0-9]*$.0.so.0.$[0-9]$00.$[0-9]*$\|$.*$/\1\2\3/g'
+ echo $mfile| sed 's/libgtk-x11-$[0-9]*$\.0\.so\.0\.$[0-9]*$00\.$[0-9]*$/\1.\2.\3/'
return 0
fi
@@ -455,16 +455,25 @@ check_gtk_ver_and_set_lib_path()
continue
fi
- len_version=`expr length $version`
- base_version=`expr substr "${base_version}0000000000" 1 $len_version`
- len_base_version=`expr length $base_version`
- while [ $len_version -gt $len_base_version ]; do
- base_version=`expr substr "${base_version}0000000000" 1 $len_version`
- len_base_version=`expr length $base_version`
+ ok=true
+
+ while [ -n "$base_version" ]
+ do
+ base_subversion=`echo $base_version | sed 's/\..*$//'`
+ subversion=`echo $version | sed 's/\..*$//'`
+ if [ $subversion -lt $base_subversion ]
+ then
+ ok=
+ break
+ elif [ $subversion -gt $base_subversion ]
+ then
+ break
+ fi
+ base_version=`echo $base_version | sed 's/^[0-9]*\.*//'`
+ version=`echo $version | sed 's/^[0-9]*\.*//'`
done
- if [ $version -ge $base_version ]; then
+ if [ -n "$ok" ]; then
export LD_LIBRARY_PATH="$idir":"$LD_LIBRARY_PATH"
IFS="$OLD_IFS"
OLD_IFS=""
@@ -640,7 +649,7 @@ fi
# Check the version of gtk and update the LD_LIBRARY_PATH if required.
if [ "`uname -s`" = "Linux" ]; then
- MIN_GTK_VERSION="240"
+ MIN_GTK_VERSION="2.4.0"
check_gtk_ver_and_set_lib_path "$MIN_GTK_VERSION" ### returns 0 if found gtk >= 2.4
fi

How about fixing the bug report submission page ?

I've been trying for I think the 11 time to submit a bugreport to bugreport.sun.com and each time,
the submission FAIL. And of course you loose everything you entered in the page.
Email to the address specified when it fail also FAIL.
rejected by the server for the recipient domain sun.comby userp1020.oracle.com. [156.151.31.79].
The error that the other server returned was:
550 5.1.1 <[email protected]>... User unknown
Please Fix, a bug report page that can't even submit simple text its ridiculous.
This is not the first time I have difficulties getting your site to work.

You're complaining to the wrong people.
Re: bug database does not work?
OTN forum admin are not responsible for the java bug reporting. They cannot fix what isn't theirs.
Locking this thread

Bootcamp Version 3.1 --List of bug reports for the Development Team to fix.

Please create a list of bug fixes for the Development Team to address in the next version of Bootcamp (e.g., 3.2). This thread assumes that all users are presently running Bootcamp 3.1:
1. Sound should not be muted every time a user reboots a newer MacBook laptop using Windows 7 Ultimate, 64-bit. My sound is always muted when I load Windows 7 Ultimate, and I have to manually turn it on each time.
2. Left and right clicks on the trackpad should work out of the box using Windows 7 Ultimate, 64-bit. My left click operates a little less than 50 percent of the time -- i.e., I click it and nothing happens. I had to switch to "tap to click" as a workaround, however, I prefer the good old solid left click.
Please step right up and add to the bug report list so that the developers have a checklist of issues that need to be fixed. When the bug report list has grown to a respectable size, I'll send an official letter to the C.E.O. to facilitate the bug reports reaching the development team.
Message was edited by: lawlist

lawlist wrote:
Please create a list of bug fixes for the Development Team to address in the next version of Bootcamp (e.g., 3.2). This thread assumes that all users are presently running Bootcamp 3.1:
1. Sound should not be muted every time a user reboots a newer MacBook laptop using Windows 7 Ultimate, 64-bit. My sound is always muted when I load Windows 7 Ultimate, and I have to manually turn it on each time.
2. Left and right clicks on the trackpad should work out of the box using Windows 7 Ultimate, 64-bit. My left click operates a little less than 50 percent of the time -- i.e., I click it and nothing happens. I had to switch to "tap to click" as a workaround, however, I prefer the good old solid left click.
Please step right up and add to the bug report list so that the developers have a checklist of issues that need to be fixed. When the bug report list has grown to a respectable size, I'll send an official letter to the C.E.O. to facilitate the bug reports reaching the development team.
Message was edited by: lawlist
FWIW, I don't have the symptoms you describe. So I think before you call a symptom a "bug" I think you should confirm that it is indeed a "bug" and not a configuration, software, or hardware issue caused by something such as incorrect installation, incorrect setup, or any other third party or user caused action.
Also, FWIW, I don't think this forum is intended to be used as a survey for gathering "bugs". Apple has an official feedback page where they gather user experiences such as yours. I think if you post your "bugs" there they will get faster attention than posting them here in this user-to-user help forum.

[Bug Report] Rhythmbox missing depedency for "tdb"

Here's the bug report:
https://bugs.archlinux.org/task/29310
Just tryed to install Rhythmbox and had to track down that depedency. Just figured I'd post it here to try to give it some more attention. Seems like a pretty easy fix that could save some users some frustration. Go give it a vote on the bug report so the developers will see this.

For Oracle TopLink customers can report bugs using a support request on metalink.oracle.com.
For TopLink Essentials customer can directly file bugs in the GlassFish system.
Doug

Bug reporting?

A couple of times Lenovo have asked for suggestions etc via System Update. This has been a great way of reporting bugs (there are a few) and make Lenovo aware of the problems users have. I have found no other way to report bugs, from small/minor problems to crash-prone problems. There was a way of contacting Lenovo in "non-technical" issues via the web site, but they usually wouldn't accept bug reports but only responded "this is a technical issue, you must open a support ticket." The problem, of course, is that you want to report a bug in the software - not ask for support (and even less pay for it).
Even this forum does not have a dedicated topic for bugs and problems with the software. So how am I to let Lenovo know something isn't working right? I've found quite a few problems since I bought my X61 in October 2007, some of which have been fixed but others have not. An example: just a minute ago, I noticed that the Power Manager battery taskbar icon was green and "half full" while my battery LED was flashing in orange - upon reconnecting the AC the Power Manager battery taskbar icon showed "4%". An obvious bug, but how do I notify Lenovo???
I have also tried telling Lenovo that the splash screen for System Update on my Win Vista Business X61 is way too annoying: it shows for a long time (15-20 seconds?) and is "always on top" - so I cannot do anything when waiting for SU to load. It doesn't have to be this way; splash screens are usually shown for a time period specified in the source code. So it should be easy to change this.
These are just two examples of bugs and annoyances that I would like to tell Lenovo about. Does anyone know how to contact Lenovo with bugs? I don't want to call customer support and spend precious time waiting for assistance - I just want to help Lenovo identify bugs in a fast and secure way.
Thanks,
Per Bylund

As this topic area is for Symbian devices, I assume you are talking about Symbian bugs. Today, I don't think Nokia is interested in knowing any bug of died OS - Symbian.
bbao
* If this post helped you, please click the white Kudo star.
* If this post has solved your issue, please click Accept as Solution.

Solaris8 and 9 (possibly 7) /dev/poll driver bug report.

Hello,
I'd like to report a bug in the solaris 8 and 9 /dev/poll driver (poll(7d)).
As i do not have a support account with sun or anything like that, there
seems to be no other way to do that here (which is of course a very sad
thing).
Bug details:
The /dev/poll device provides an ioctl-request (DP_ISPOLLED) for checking
if a particular filedescriptor is currently in the set of monitored
filedescriptors for that particular /dev/poll fd set (open /dev/poll fd).
A quote from the documentation of the poll(7d) manual page taken from
Solaris9:
"DP_ISPOLLED ioctl allows you to query if a file descriptor is already in
the monitored set represented by fd. The fd field of the pollfd structure
indicates the file descriptor of interest. The DP_ISPOLLED ioctl returns 1
if the file descriptor is in the set. The events field contains the
currently polled events. The revents field contains 0. The ioctl returns 0
if the file descriptor is not in the set. The pollfd structure pointed by
pfd is not modified. The ioctl returns a -1 if the call fails."
It says that when you query for an filedescriptor which is currently being
monitored in the set, that it would return 1, and change the events field of
the pollfd structure to the events it's currently monitoring that fd for.
The revents field would be set to zero.
However the only thing which actually happens here, is that FD_ISPOLLED
returns 1 when the fd is in the set and 0 if not. When the fd is in the
set, when FD_ISPOLLED returns 1, the events field remains unmodified, but
the revents field gets changed.
A small sample code to illustrate:
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/devpoll.h>
main() {
struct pollfd a;
int dp_fd = open("/dev/poll", O_WRONLY);
a.fd = 0; /* stdin */
a.events = POLLIN; /* we monitor for readability, POLLIN=1 */
a.revents = 0;
write(dp_fd, &a, sizeof(a));
a.fd = 0;
a.events = 34; /* filled in with bogus number to show malfunctioning */
a.revents = 0;
printf("DP_ISPOLLED returns: %d\n", ioctl(dp_fd, DP_ISPOLLED, &a));
printf("a.fd=%d, a.events=%hd, a.revents=%hd\n", a.fd, a.events,
a.revents);
According to the documentation of /dev/poll and namely DP_ISPOLLED this
program is supposed to print the following:
DP_ISPOLLED returns: 1
a.fd=0, a.events=1, a.revents=0
However it prints the following:
DP_ISPOLLED returns: 1
a.fd=0, a.events=34, a.revents=1
You can take any number instead of '34' and it will simply remain untouched
after the DP_ISPOLLED ioctl-request.
I hope it's clear now that the solaris8 and solaris9 (and probably solaris7
with /dev/poll patch too) DP_ISPOLLED implementation is broken.
This bug is also easily illustrated by looking at the solaris8 kernel sourcecode:
<snippet osnet_volume/usr/src/uts/common/io/devpoll.c:dpioctl()>
case DP_ISPOLLED:
pollfd_t pollfd;
polldat_t *pdp;
if (pollfd.fd < 0) {
mutex_exit(&pcp->pc_lock);
break;
pdp = pcache_lookup_fd(pcp, pollfd.fd);
if ((pdp != NULL) && (pdp->pd_fd == pollfd.fd) &&
(pdp->pd_fp != NULL)) {
pollfd.revents = pdp->pd_events;
if (copyout(&pollfd, (caddr_t)arg,
sizeof(pollfd_t))) {
mutex_exit(&pcp->pc_lock);
DP_REFRELE(dpep);
return (set_errno(EFAULT));
*rvalp = 1;
</snippet>
its' clearly visible that the code writes the current monitored events to
the revents field:
'pollfd.revents = pdp->pd_events;'
and that it doesnt set revents to zero.
It's funny to see that this has been like this since Solaris8 (possibly 7). That means nobody ever used DP_ISPOLLED that way or people were simply to lazy to file a bug report.
Another funny thing related to this. is that Hewlett-Packard did seem to know about this. Since HP-UX11i version 1.6 they also support /dev/poll. From their manual page i ll quote some sentences from their WARNING session:
"The ioctl(DP_ISPOLLED) system call also returns its result in the revents member of the pollfd structure, in order to be compatible with the implementation of the /dev/poll driver by some other vendors."
Hopefully this will get fixed.
I also like to reexpress my very negative feelings towards the fact that you're not able to file bug reports when you do not have a support contract. Ridiculous.
Thanks,
bighawk

Have I mentioned how much i love my playbook now Great job on os 2.0

Bug Report: The keyboard focus doesn't automatical...

Bug Report: When a conversation window opens, the focus doesn't automatically land in the chat entry text field.
Since the new interface for Skype was introduced officially in Skype 7.0, there is a bug with the system/keyboard focus for a new conversation window. When Skype is in "Split Window View" and each new conversation automatically pops up in a separate window, the system/keyboard focus doesn't land in the chat entry edit field. Instead, the user has to press Shift+TAB a couple of times, to move it there and reply to the chat message received. This especially problematic for screen reader users, who rely on keyboard navigation. This mainly occurs when a new conversation is started with an incoming message, but it sometimes occurs when moving the focus out of that conversation window and later back in it again (while it is still opened).
Steps to reproduce it:
1. From "View" menu, activate the "Split Window View", if it is not already enabled.
2. From Tools -> Options -> IM & SMS -> IM settings, enable "Open a new window when I receive a new message in Split Window View", if it is not already enabled.
3. From Tools -> Options -> Advanced, activate "Enable accessible mode", if it is not already enabled.
4. Activate the "Save" button, to save the changes.
5. Close all windows, related to Skype. You may keep only the main window opened.
6. Tell someone to send you a chat message. When the message arrives, Move the system focus to the conversation window in question, preferably with Alt+TAB. The system/keyboard will not land in the chat entry edit field as it did in Skype 6.21 and earlier and as it should by default, but in some unknown place in the window.
7. Move the system/keyboard focus in the chat entry edit field and keep it there.
8. Switch to another window, preferably from another application.
9. With Alt+TAB, switch back to the window of the opened Skype conversation. There is a chance that the system/keyboard focus will not land in the chat entry edit field as it did in Skype 6.21 and earlier and as it should do by default, but again in some unknown place in the conversation window. But that is harder to reproduce.
Test environment:
- Operating system: Windows 8.1 Pro N, 64-bit, in Bulgarian with all locale settings set to "Bulgarian".
- Skype version: 7.0.0.102 for Desktop.

This is a known problem, but Skype have not given us an estimated time for a fix.
Traditionally, Skype updates have been roughly monthly, so we are due a new version sometime soon. Many of us here are hoping that is has a bunch of fixes for the UI, the focus problem being one of them.
Sean Ellis - uses Skype chat for serious work
Click here to read my blog post on Skype 7 and basic principles of GUI design

Bug report: vpn (ipsec) interface number in snmp always change

Hi,
this is a bug report for RV082 hardware version 3 and 4, firmware version 1.x, 2.x and 4.x (all latest versions). I hope someone from cisco/belkin reads it.
Summary:
The snmp interface number of a VPN Tunnel change when the VPN tunnel disconnect and then re-connects.
What should happend:
The VPN Tunnel number 1, should always have the same snmp interface number. In RV082 v4, this number should always be 10. For example, the LAN, WAN1 and WAN2 always have the same snmp interface number.
What is the problem:
The VPN Tunnel number 1 change the snmp interface number, from 10, to 11, to 12, etc.
How to reproduce:
create a VPN Tunnel using 2 RV082 or 1 RV082 and 1 RV042. Once the VPN Tunnel is connected write down the snmp interface number. A few days later, disconnect the cable of block internet access. Then restore the internet conection and write down the snmp interface number, you should note that the snmp interface number have changed.
Tools used:
PRTG Network Monitor
Please take a look at the attached image, note all the "ppp" interfaces, theres only 1 VPN Tunnel (gateway-to-gateway) defined.

Hi Tom,
many thanks for your reply.
I see that I have to call Tech-support, in order to report a very technical situation, explaining them this is a bug report and I want them to make a better product.
Since I won't pay a dime for this problem to be fixed, I can only see pain in this path(calling to speak with a tech support representative).
I also readed that Belkin has bought Linksys, so I don't know if the RV082 will remain with Cisco or will go with Belkin.
So, my only hope is to document this bug, that is pressent inall firmware version and hardware version of the RV082 as of today.
many thanks for your help,
regards,
Oliver

Bug report: A keyboard layout is incorrect on the remote with Japanese keyboard

This is a bug report for Microst Remote Desktop
===================================================
## Summary
A keyboard layout is incorrect on the remote with Japanese keyboard
## Version Information, I tested
* Client
   * Case 1
       * MacBook Pro with JIS106 Keyboard
       * Mac OS X Lion 10.7.5
       * Microsoft Remote Desktop 8.0.24308
   * Case 2
       * MacBook Pro with JIS106 Keyboard
       * Mac OS X Mavericks 10.9.1
       * Microsoft Remote Desktop 8.0.24308
* Remote
   * Case 1
       * Windows 7 Professional Japanese
   * Case 2
       * Windows Server 2008R2 Datacenter Japanese
   * Case 3
       * Windows Server 2012R2 Datacenter Japanese
## Detail of bug
When login from Mac OS X with Microsoft Remote Desktop, the keyboard layout is always incorrect on the remote.
The client machine have a built-in keyboard of JIS 106 layout,
and the primary language is set to Japanese.
But on the remote, the keyboard layout is US 101.
So a input of Shift+2 does not result " but @.
I've seen the above behavior on the 3 remote enviornments described the above.
This bug did not occcur with Microsoft Remote Desktop Connection Client for Mac 2.1.1, even if the system language is English and keyboard layout is Japanese.
## Captures
I've took some of screen captures.
I'm sorry for the capture includes Japanese words, so I added description in English.
Capture 1:
Mac OS X Keyboard Setting
Capture 2:
Windows Server 2012R2 Screen Keyboard
Capture 3:
Windows Server 2012R2 Screen Keyboard, with a additional registry key configured.

This bug also affects the Canadian English settings. If the client is set to Canadian English with a US keyboard the remote server is setup using a Canadian French keyboard. Using the language selection in the toolbar you can temporarily correct
the problem but the keyboard resets to french at the most inopportune times. The was a problem in the earlier RDP client and was fixed so it's sad to see it reoccur in the new client.
Lawrence

Bug report on Japanese Ruby

Just a bug report on some ruby word options on Japanese script
「泳」for 「泳ぐ」never accept any ruby.
「三味線」should be reas as 「しゃみせん」and suggested option actually includs the correct reading. However, the actual ruby you will get is 「ざみせん」.
Hope they are fixed in the next update.

For Apple to see your report, you should use
http://www.apple.com/feedback

Bug report: ignore not working

Bug report: ignore in the forum here not working
I set some SPAM users to 'ignore' - still can see their SPAM.
Please fix it.

The "Ignore a community user" feature will only block private messages received from other community users. See also the community help here: http://community.skype.com/t5/help/faqpage/faq-category-id/pm#pm
Is that what you are referring to or do you expect this also to hide public messages posted by these users (which is not what it is currently designed to do).
If you should spot content on the community that is violating our Community Guidelines please use the "Report inappropriate content" link from the "Post Options" menu next to the message. These abuse reports will then be reviewed by our moderation team.
Follow the latest Skype Community News
↓ Did my reply answer your question? Accept it as a solution to help others, Thanks. ↓

Bug report: Screen times out when other side is no...

Bug report: Screen times out when other side is not sharing video. The phone locks and of course the other party cannot see anything. Please fix.
Using WP 8.1.1 Developers Preview.

Hi and welcome to the Skype Community,
Can you please share which platform and which device you are on?
Also are you referring about a one-way video call here where only you are sending video, but the other party doesn't send their video back?
Follow the latest Skype Community News
↓ Did my reply answer your question? Accept it as a solution to help others, Thanks. ↓

Bug report, Beta 2.12 Standard Edition

Bug report: redundant, confusing, and apparently erroneous calls to
jdoPreClear
and jdoPostLoad. Note in output the null name in the third iteration.
Hi,
A lot of information being sent. Sorry, but I think you'll find it
helpful. I expected the exact same sequence of calls to jdoPreClear
and jdoPostLoad on the 2nd and third iteration. In fact, since,
retain values is true, and no changes are being made, I expected that
jdoPreClear and jdoPostLoad would not be called at all on the 2nd and
3rd iteration.
David Ezzio
Using 2.12 Beta, standard edition
Business method uses one PM. Configured to datastore transaction,
retainValues == true, non-TR == false, and non-TW == false.
The business methods open a transaction and leave it open.
The client calls commitTransaction() to close the open
transaction.
Two persistent objects, Widget and Box. Each implement
InstanceCallbacks and put out a message in jdoPreClear ("will be
made hollow") and in jdoPostLoad ("has been made persistent-clean").
The Widget has a reference to its Box. The number in parenthesis
is the sequence number obtained from the object ID.
Business methods implementation:
public ArrayList getWidgetsByName(String name)
Transaction trans = pm.currentTransaction();
if (!trans.isActive())
trans.begin();
Collection c = (Collection) widgetsByOneName.execute(name);
ArrayList aList = new ArrayList(c);
widgetsByOneName.close(c);
return aList;
public void commitTransaction()
Transaction trans = pm.currentTransaction();
if (trans.isActive())
trans.commit();
Output: from three loops that:
call findWidgetsByName("Maxi-Widget")
list the widgets returned
call commitTransaction()
finding Maxi-Widgets ...
Widget Maxi-Widget (650) has been made persistent-clean
Box Large (652) has been made persistent-clean
Widget Maxi-Widget (650): Box Large (652) at location Top Shelf
Widget Maxi-Widget (709) has been made persistent-clean
Box Large (710) has been made persistent-clean
Widget Maxi-Widget (709): Box Large (710) at location Middle Shelf
Widget Maxi-Widget (708) has been made persistent-clean
Box Large (713) has been made persistent-clean
Widget Maxi-Widget (708): Box Large (713) at location Top Shelf
Widget Maxi-Widget (700) has been made persistent-clean
Box Large (717) has been made persistent-clean
Widget Maxi-Widget (700): Box Large (717) at location Top Shelf
Widget Maxi-Widget (707) has been made persistent-clean
Box Large (716) has been made persistent-clean
Widget Maxi-Widget (707): Box Large (716) at location Top Shelf
Finding them again
finding Maxi-Widgets ...
Widget Maxi-Widget (650) will be made hollow
Widget Maxi-Widget (650): Box Large (652) at location Top Shelf
Widget Maxi-Widget (709) will be made hollow
Widget Maxi-Widget (709): Box Large (710) at location Middle Shelf
Widget Maxi-Widget (708) will be made hollow
Widget Maxi-Widget (708): Box Large (713) at location Top Shelf
Widget Maxi-Widget (700) will be made hollow
Widget Maxi-Widget (700): Box Large (717) at location Top Shelf
Widget Maxi-Widget (707) will be made hollow
Widget Maxi-Widget (707): Box Large (716) at location Top Shelf
Finding them yet again
finding Maxi-Widgets ...
Widget null (650) will be made hollow
Widget Maxi-Widget (650) has been made persistent-clean
Widget Maxi-Widget (650): Box Large (652) at location Top Shelf
Widget null (709) will be made hollow
Widget Maxi-Widget (709) has been made persistent-clean
Widget Maxi-Widget (709): Box Large (710) at location Middle Shelf
Widget null (708) will be made hollow
Widget Maxi-Widget (708) has been made persistent-clean
Widget Maxi-Widget (708): Box Large (713) at location Top Shelf
Widget null (700) will be made hollow
Widget Maxi-Widget (700) has been made persistent-clean
Widget Maxi-Widget (700): Box Large (717) at location Top Shelf
Widget null (707) will be made hollow
Widget Maxi-Widget (707) has been made persistent-clean
Widget Maxi-Widget (707): Box Large (716) at location Top Shelf
-- All done!

Due to better understanding on my part, and the fixes in Beta 2.2, the
issues raised in this thread are put to rest.
Abe White wrote:
>
We'll investigate further. Stay tuned...
"David Ezzio" <[email protected]> wrote in message
news:[email protected]..
Abe,
Actually, it doesn't make sense. The first iteration shows
jdoPostLoad is called just prior to using the fields of Widget and Box.
After the commit, the instances are not cleared. So far, so good.
In the second iteration, we see that jdoPreClear is called, but
jdoPostLoad is not called. Yet the values are there for use during the
call to Widget.toString() and Box.toString() within the iteration. How
did that happen?
On the third iteration, now the value of name is null, but last we
looked it was available in the second iteration. Other than that, I
agree that the third iteration looks ok, since it is being cleared and
loaded prior to use. But in the jdoPreClear, the values should be there
since the values were used in the previous iteration and are not cleared
at transaction commit due to retainValues == true.
David
Abe White wrote:
David --
I believe the behavior you are seeing to be correct. Section 5.6.1 of
the
JDO spec outlines the behavior of persistent-nontransactional instancesused
with data store transactions. As you can see, persistentnon-transactional
instances are cleared when they enter a transaction; thus the calls to
jdoPreClear. When the default fetch group is loaded again (like whenyou
access the name of the widget) a call to jdoPostLoad is made.
You are seeing the name of one instance as 'null' in the third iterationof
your loop because the instance has been cleared in the second iteration,and
the jdoPreClear method is not modified by the enhancer (see section10.3).
Make sense?

BUG REPORT FIRMWARE 5.1.7 PLEASE FORWARD TO SUPERVISOR....

BUG REPORT FIRMWARE 5.1.7 PLEASE FORWARD TO SUPERVISOR.
The spa-3102 has the following two bugs.
When the unit sends a hook-flash to the fxo port it:
a) does not send the hook flash to the fxo port for PSTN Hook Flash Len: Instead it uses a very short pulse of about 100ms or 1/10 of a second. It should honor the PSTN Hook Flash Len configurable parameter of .2 – 1.5 seconds.
b) Does not change the line voltage from –7 (off-hook) to –48(on-hook) during a flash-hook to the fxo port. Instead it varies the voltage only by about 2.5 volts.
This was reported as early as June 07 to linksys support. It is reported they agreed and would fix in the next firmware release. There is info that firmware 5.2 being released and is this fix in 5.2 and how can I get it.

Although the problem is still not solved, at least I now know WHY the problem is happening... and Apple's Firmware Update is NOT to blame!
Through a series of coincidences, I was actually lucky enough to get in touch with the engineers in Apple's Airport firmware division, and they were helping me to nail down this problem.
Turns out that Apple takes great PRIDE in the fact that they are one of the VERY FEW manufacturers who make routers that behave properly in this regards: they SPECIFICALLY test for their Airport Extreme routers to allow you to connect to servers behind the NAT by way of the public WAN IP address of the NAT box. This is the way that apparently the NAT/DHCP specification is SUPPOSED TO WORK! You're SUPPOSED to be able to connect this way, if you so desire.
So what was causing the problem on my network, then?
Something I hadn't thought about... the Vonage Linksys RTP300 router that we're using for our Vonage VoIP service. Turns out that this router does NOT support clients behind the NAT connecting to servers behind the NAT by way of the public WAN IP address.
Linksys is to blame, not Apple!
And apparently, this feature may have actually been working in an earlier
firmware update, but apparently, Vonage AUTOMATICALLY pushes firmware
updates to RTP300's, apparently without user notification:
<http://www.vonage.com/help.php?article=1066&category=90&nav=5>
And a forum thread on vonage-forums.com seems to indicate that the 1.00.60 firmware in the RTP300 started getting pushed to customer units on or before 1/26/06, making it less than a month after Apple shipped the 5.7 firmware update for AirPort Extreme Base Stations:
<http://www.vonage-forum.com/ftopic10915.html>. So if the problem cropped up then, it's possible that I accidentally attributed it to Apple when really the RTP300 got a firmware update around then too which may have broken this feature (assuming it was working before then).
Power Mac G4 QuickSilver Dual 800 MHz Mac OS X (10.4.4)

Bug report (easy to fix)

Similar Messages

Maybe you are looking for