[GLASSFISH-20560] upgrade doesn't handle JDBCRealm and PamRealm package change Created: 20/May/13  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 4.0_b89_RC5
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: carlavmott
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In GlassFish 4.0, the Java packages for the JDBCRealm and PamRealm classes changed from:

com.sun.enterprise.security.auth.realm...

to:

com.sun.enterprise.security.ee.auth.realm...

The upgrade code doesn't handle this change.






[GLASSFISH-18100] Incorrect version printed when invoking "asupgrade -V" Created: 30/Dec/11  Updated: 19/Jan/12  Resolved: 18/Jan/12

Status: Closed
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 3.1.2_b16
Fix Version/s: 3.1.2_b18

Type: Bug Priority: Major
Reporter: Alex Pineda Assignee: carlavmott
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GF3.1.2 build16 installed on a Solaris Sparc 10 system.


Attachments: File 18100.diff    
Tags: 3_1_2-approved

 Description   

Using the latest build and upon running the following command

  • machine$ asupgrade -V
    Upgrade Tool for Oracle GlassFish Server 3.1.1

The incorrect version is displayed. It needs to be updated to version 3.1.2



 Comments   
Comment by Bobby Bissett [ 30/Dec/11 ]

Adding diff to fix the issue.

Comment by Bobby Bissett [ 30/Dec/11 ]

Hi Shreedhar,

Can you find someone to handle this one? I've attached a diff that fixes the issue, so it should be quick.

Cheers,
Bobby

Comment by carlavmott [ 11/Jan/12 ]
  • What is the impact on the customer of the bug?
    The is a regression. The customer gets the wrong version number which looks unprofessional.

How likely is it that a customer will see the bug and how serious is the bug?
It's a regression. The customer would see it on an upgrade.

  • What is the cost/risk of fixing the bug?
    Very simple fix. Just need to add a Constant to one file and then use that new Constant in another.

How risky is the fix? How much work is the fix? Is the fix complicated?
Very simple fix. Will take on the order of minutes to code.

  • Is there an impact on documentation or message strings?
    None.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Quicklook should be enough
  • Which is the targeted build of 3.1.2 for this fix?
    next build
Comment by carlavmott [ 11/Jan/12 ]

Made the changes in the diff file. Ran the quicklook tests and all passed. Also ran the command that showed the problem and it was corrected. Waiting for ok to check in code.

asupgrade -V
Upgrade Tool for GlassFish Server Open Source Edition 3.1.2

Comment by carlavmott [ 18/Jan/12 ]

got approval from Joe and commited fix.

Revision: 52060

Comment by Alex Pineda [ 19/Jan/12 ]

Verified fix in build 18. Version is correct.





[GLASSFISH-16702] need to bump version number in upgrade tool to 3.1.1 Created: 23/May/11  Updated: 23/May/11  Resolved: 23/May/11

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b06

Type: Bug Priority: Major
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all environment


Attachments: File upgrade.diff    
Issue Links:
Dependency
blocks GLASSFISH-16700 Could not upgrade from ogs-3.1-window... Closed
Tags: 3_1_1-approved, 3_1_1-upgrade

 Description   

The upgrade tool still thinks it's running in 3.1. I need to add version 3.1.1 to it. The change is in the code to use the new version along with edits in the built-in help.



 Comments   
Comment by Bobby Bissett [ 23/May/11 ]

This is fixed in revision 47021. I think that will be b07 but am checking.





[GLASSFISH-16700] Could not upgrade from ogs-3.1-windows-ml.exe to ogs-3.1.1-b05-windows-ml.exe in Windows 7 x86 Created: 23/May/11  Updated: 22/Jul/11  Resolved: 24/May/11

Status: Closed
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 3.1.1_b05
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sunny-gui Assignee: Bobby Bissett
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Windows 7 x86
Bundle: from ogs-3.1-windows-ml.exe to ogs-3.1.1-b05-windows-ml.exe
Locale: ja, en


Attachments: XML File domain.xml     JPEG File message_consoleMode.jpg     JPEG File UnsupportedUpgradePath.jpg     JPEG File upgrade_wrongVersinoNumber.jpg    
Issue Links:
Dependency
depends on GLASSFISH-16304 domain.xml should be in UTF-8 Reopened
depends on GLASSFISH-16702 need to bump version number in upgrad... Resolved
depends on GLASSFISH-16713 JNDI name encoded using Server locale... Closed
Duplicate
duplicates GLASSFISH-16713 JNDI name encoded using Server locale... Closed
Tags: 3_1-next_release-note-added, 3_1-next_release-notes, 3_1_1-review, 3_1_1-upgrade

 Description   

Issue: Could not upgrade from ogs-3.1-windows-ml.exe to ogs-3.1.1-b05-windows-ml.exe in Windows 7 x86

To reproduce:
1. Invoke "ogs-3.1-windows-ml.exe" to install GF 3.1 into c:\glassfish3\
2. Login application server by http://[hostname]:4848/ and deploy an application for it
3. Create JDBC resouce with multibyte characters
4. Stop glassfish
5. Install GF 3.1.1 with "ogs-3.1.1-b05-windows-ml.exe" into a different directory, c:\glassfish311\
6. Run "asupgrade" under c:\glassfish311\glassfish\bin\
7. Put previous domain directory as source domain directory, master password is 'changeit'
8. Click 'Next' button.

System will pop ups dialog window say: Unsupported Upgrade Path
There are also wrong version number in Upgrade Wizard Page.

Please find attached screen shots for your reference.



 Comments   
Comment by Bobby Bissett [ 23/May/11 ]

Good catch on the wrong version number – I completely missed that. Version number should be a simple fix, and hopefully the "unsupported path" message is similar. I know that the tool works going from 3.1 to 3.1 just fine.

Comment by Bobby Bissett [ 23/May/11 ]

The version number is a simple fix, but I can't reproduce the "unsupported upgrade path" error from the workspace. I'm going to move the version number into its own issue so I can get that integrated sooner.

Comment by Bobby Bissett [ 23/May/11 ]

Adding link to new issue for the version number change. GLASSFISH-16702.

Comment by Bobby Bissett [ 23/May/11 ]

Note: I see that using the master password field no longer works in 3.1.1. I've filed issue GLASSFISH-16704 for it. Until that's fixed, you can leave password field blank as long as you haven't changed it from the default in the source server.

Comment by Bobby Bissett [ 23/May/11 ]

(Changed this from a previous comment where I thought it was a problem that the tool doesn't know about 3.1.1. I don't think that's a bug any more.)

The tool doesn't know about 3.1.1, but it treats any 3.X domain.xml as a 3.1 domain because there is no DTD to check for a version. So it should work just fine going from 3.1 to 3.1.1 or even 3.1.1 to 3.1.1 without any change to the tool. Can you attach your upgrade.log file? That should contain the actual source and target versions that the tool is complaining about.

Can you verify that you get the same message in console mode? To do that, just use the -c option to avoid the GUI. Due to issue 16704, just leave the password blank when you try the upgrade.

Comment by sunny-gui [ 23/May/11 ]

I attached the screen shot about the same message in console mode.

Comment by Rui Wang [ 23/May/11 ]

I think the reason that cause this upgrade fail is: "Invalid byte 1 of 1-byte UTF-8 sequence".
domain.xml in GlassFish 3.1 contains a MBCS name encoded in Shift_JIS:
<jdbc-resource pool-name="DerbyPool" description="" jndi-name="名と物理"></jdbc-resource>
And domain.xml do not have prolog specify the encoding of the XML file.
During the upgrade, upgrade tool then use UTF-8 to decode the xml file, and that will cause "Invalid byte 1 of 1-byte UTF-8 sequence".
So the problem lies in parse of the domain.xml. We suggest the xml reading/writting need to change to always using UTF-8 encoding

1) Write: When adding jdbc connection pool to domain.xml file, MBCS name encoded using native encoding Shift_JIS(Server Locale is ja), not UTF-8.

2) Read: After we restart GF after we add MBCS named jdbc connection in domain.xml file, it can also parse this domain.xml correctly
This means it use native encoding Shift_JIS(Server Locale is ja), not UTF-8 to parse domain.xml

Comment by Rui Wang [ 23/May/11 ]

domain.xml of GlassFish

Comment by Rui Wang [ 24/May/11 ]

This issue is caused by GLASSFISH-16713.

Comment by Bobby Bissett [ 24/May/11 ]

Am going to mark this as a duplicate of 16713 instead of a dependency, since I don't see a problem in the tool. Thanks for attaching the domain.xml – without that I couldn't duplicate the issue to see what was happening.

When filing an upgrade tool issue, please attach the upgrade.log file. That would have the same info that went to the console with the -c option, so the problem would have been obvious sooner. The root problem, as you've already pointed out, is the source xml, and it's shown here in the upgrade tool output:

— begin —
Could not create xml document object from file name /Users/bobby/eraseme/3_1/glassfish3/glassfish/domains/domain1/config/domain.xml due to: com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: Invalid byte 1 of 1-byte UTF-8 sequence.
— end —

Because the xml is malformed (due to GLASSFISH-16713), the tool can't load the xml to determine the version of the source domain. So there's this output in the log that shows why the path is unsupported:

— begin —
Unsupported Upgrade Path.
source version: null profile: null
target version: 3.1.1 profile: All
— end —

On a related note, GLASSFISH-16704 is now fixed, so you should be able to use the master password field again in the next build.

Comment by Bobby Bissett [ 24/May/11 ]

See previous comment. Closing as duplicate of GLASSFISH-16713.

Comment by Bobby Bissett [ 24/May/11 ]

For what it's worth, if the tool didn't catch this and tried to perform the upgrade, here's the output from the server:

hostname% ./asadmin start-domain --upgrade
May 24, 2011 10:50:20 AM com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: JVM invocation command line:
[...]
Launching GlassFish on Felix platform
Exception in thread "main" java.lang.reflect.InvocationTargetException
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 com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: org.jvnet.hk2.component.ComponentException: Failed to create a habitat
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.createHabitat(AbstractModulesRegistryImpl.java:169)
at com.sun.enterprise.module.bootstrap.Main.createHabitat(Main.java:425)
at org.jvnet.hk2.osgiadapter.HK2Main.createHabitat(HK2Main.java:96)
at org.glassfish.kernel.GlassFishActivator$1.newGlassFish(GlassFishActivator.java:104)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:113)
... 6 more
Caused by: java.lang.RuntimeException: Fatal Error. Unable to parse file:/Users/bobby/work/ws/br_3_1_1/v3/distributions/glassfish/target/glassfish3/glassfish/domains/domain1/config/domain.xml
at org.glassfish.config.support.DomainXml.parseDomainXml(DomainXml.java:257)
at org.glassfish.config.support.DomainXml.run(DomainXml.java:109)
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.populateConfig(AbstractModulesRegistryImpl.java:176)
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.createHabitat(AbstractModulesRegistryImpl.java:158)
... 10 more
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[37,68]
Message: Invalid byte 1 of 1-byte UTF-8 sequence.
at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:592)
at javax.xml.stream.util.StreamReaderDelegate.next(StreamReaderDelegate.java:60)
at org.glassfish.config.support.XMLStreamReaderFilter.thisNextTag(XMLStreamReaderFilter.java:94)
at org.glassfish.config.support.XMLStreamReaderFilter.nextTag(XMLStreamReaderFilter.java:74)
at org.jvnet.hk2.config.ConfigParser.handleElement(ConfigParser.java:199)
at org.jvnet.hk2.config.ConfigParser.handleElement(ConfigParser.java:215)
at org.jvnet.hk2.config.ConfigParser.handleElement(ConfigParser.java:167)
at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:98)
at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:93)
at org.glassfish.config.support.DomainXml.parseDomainXml(DomainXml.java:238)
... 13 more

...and then the server hangs and has to be manually stopped.

Comment by gmurr [ 21/Jul/11 ]

work around for this issue:
1- backup domain.xml
2- native2ascii domain.xml domain.xml.ascii
3- native2ascii -reverse -encoding UTF-8 domain.xml.ascii domain.xml
4- run asupgrade
5- native2ascii -encoding UTF-8 domain.xml domain.xml.ascii
6- native2ascii -reverse domain.xml.ascii domain.xml

Comment by Rebecca Parks [ 21/Jul/11 ]

Per a later email from gmurr, added the following to the 3.1.1 Release Notes:

Could not upgrade from ogs-3.1-windows-ml.exe to ogs-3.1.1-b05-windows-ml.exe in Windows 7 x86 (16700)

Description

Upgrading from ogs-3.1-windows-ml.exe to ogs-3.1.1-b05-windows-ml.exe in Windows 7 x86 may produce
the error, Unsupported Upgrade Path.

Workaround

Convert the domain.xml file to native encoding before upgrading. Follow these steps:

1. Back up the domain.xml file.

2. Run the following commands:

native2ascii domain.xml domain.xml.ascii
native2ascii -reverse -encoding UTF-8 domain.xml.ascii domain.xml

3. Run the asupgrade command under c:\glassfish311\glassfish\bin\.

4. Run the following commands:

native2ascii -encoding UTF-8 domain.xml domain.xml.ascii
native2ascii -reverse domain.xml.ascii domain.xml

Comment by Bobby Bissett [ 22/Jul/11 ]

That comment isn't actually correct. There is no problem specific to upgrading between those versions. The problem is that there was an unsupported character in domain.xml, and so the app server couldn't understand it when trying to parse domain.xml. This issue was closed as a duplicate of http://java.net/jira/browse/GLASSFISH-16713 – the workaround should be there instead.

If someone runs into this issue, that user needs to look at the actual upgrade tool output to see if it's this message:

"Could not create xml document object from file name /Users/bobby/eraseme/3_1/glassfish3/glassfish/domains/domain1/config/domain.xml due to: com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: Invalid byte 1 of 1-byte UTF-8 sequence."

If so, then the workaround above applies.





[GLASSFISH-16286] IllegalArgumentException: port out of range:-1 after config upgrades unit test Created: 30/Mar/11  Updated: 02/Dec/11  Resolved: 30/Mar/11

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 4.0
Fix Version/s: 3.1.1_b01

Type: Bug Priority: Major
Reporter: Amy Roh Assignee: Justin Lee
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

[java] [#|2011-03-30T09:39:34.635-0700|SEVERE|glassfish3.2|com.sun.pkg.client.SystemInfo|_ThreadID=10;_ThreadName=main;|badproxy|#]
[java]
[java] [#|2011-03-30T09:39:34.639-0700|SEVERE|glassfish3.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=10;_ThreadName=main;|java.lang.IllegalArgumentException: port out of range:-1
[java] at java.net.InetSocketAddress.<init>(InetSocketAddress.java:118)
[java] at com.sun.pkg.client.AuthProxy.newProxy(AuthProxy.java:105)
[java] at com.sun.pkg.client.SystemInfo.loadProxyInfo(SystemInfo.java:201)
[java] at com.sun.pkg.client.SystemInfo.getProxySelector(SystemInfo.java:168)
[java] at com.sun.pkg.client.Image.<init>(Image.java:965)
[java] at com.sun.pkg.client.Image.<init>(Image.java:983)
[java] at com.sun.enterprise.registration.glassfish.RegistrationUtil.getUpdateCenterImage(RegistrationUtil.java:180)
[java] at com.sun.enterprise.registration.glassfish.RegistrationUtil.setUpdateCenterUUID(RegistrationUtil.java:187)
[java] at com.sun.enterprise.registration.glassfish.RegistrationUtil.synchUUID(RegistrationUtil.java:174)
[java] at com.sun.enterprise.registration.glassfish.PingService.postConstruct(PingService.java:92)
[java] at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
[java] at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
[java] at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
[java] at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
[java] at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
[java] at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
[java] at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:326)
[java] at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
[java] at com.sun.enterprise.v3.server.UpgradeStartup.start(UpgradeStartup.java:170)
[java] at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
[java] at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at java.lang.reflect.Method.invoke(Method.java:597)
[java] at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
[java] at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
[java] |#]
[java]
[java] [#|2011-03-30T09:39:34.686-0700|INFO|glassfish3.2|null|_ThreadID=10;_ThreadName=main;|Exiting after upgrade|#]



 Comments   
Comment by Justin Lee [ 30/Mar/11 ]

these tests weren't exactly correct and are handled elsewhere so I just removed them.





[GLASSFISH-16159] asupgrade fails without internet connection Created: 04/Mar/11  Updated: 14/Mar/12  Resolved: 04/Mar/11

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01, 4.0_b37

Type: Bug Priority: Major
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File gf-16159.diff    
Tags: 3_1-next, 3_1-release-note-added, 3_1-release-notes, 3_1-upgrade

 Description   

Without an internet connection, the upgrade tool fails while trying to parse the version out of the source domain.xml. The failure is here in UpgradeUtils.java:

/*

  • We don't need to validate the xml document now as that is the
  • job of the upgrade code in the application server. We're only
  • interested in the version information here, and if that is
  • somehow wrong then the upgrade process will fail downstream
  • as the document is parsed into serverbeans objects.
    */
    public Document getDomainDocumentElement(String domainFileName) {
    DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
    factory.setNamespaceAware(true);
    Document resultDoc = null;
    try { DocumentBuilder builder = factory.newDocumentBuilder(); resultDoc = builder.parse(new File(domainFileName)); }

    catch (Exception ex)

    Unknown macro: { logger.log(Level.WARNING, stringManager.getString("upgrade.common.could_not_create_doc", new Object [] {domainFileName, ex.toString()})); }

    return resultDoc;
    }

Example error:

Could not create xml document object from file name /home/oracle/SUNWappserver/domains/domain1/config/domain.xml due to: java.net.UnknownHostException: www.sun.com

The fix for this is simple – what's bad is that this code hasn't changed since the initial commit in the v3 workspace, and no one has reported it till now (though GLASSFISH-14951 came close). We should fix this for any 3.1.next release.



 Comments   
Comment by Bobby Bissett [ 04/Mar/11 ]

The workaround is easy:

1. Copy source domain to the target domains directory (first rename the 3.1 domain if it has the same name as the one to be upgraded).
2. "asadmin start-domain --upgrade <domainname>"

Comment by Bobby Bissett [ 04/Mar/11 ]

Patch, take 1.

Comment by Bobby Bissett [ 04/Mar/11 ]

This is fixed in revision 45411.

Comment by Scott Fordin [ 15/Mar/11 ]

Does this still need to be included in the 3.1 Release Notes?

Comment by Bobby Bissett [ 15/Mar/11 ]

Thanks for checking. I guess it probably should include that you can run into this when using the upgrade tool with a 2.x domain and no internet connection. Let me know if you want me to file a separate issue or something.

Comment by Scott Fordin [ 15/Mar/11 ]

Ah, I can see where this could start to get messy. Two questions: 1) Should this information be included in the Upgrade Guide proper rather than the Release Notes? For example, it go in the Correcting Potential Upgrade Problems section (http://download.oracle.com/docs/cd/E18930_01/html/821-2437/gkrfh.html) 2) More messy, does this issue not have implications for performing closed network upgrades, as described in http://download.oracle.com/docs/cd/E18930_01/html/821-2416/gjcya.html?

I suppose I can just add the topic to Release Notes, but the closed network upgrade bit concerns me. Is there something I'm missing that makes this issue moot in closed network upgrade context? I mean, a user could copy the source domain to the target domain, as you state in the workaround, but would this workaround be necessary when the repositories are configured to be local?

Comment by Snjezana Sevo-Zenzerovic [ 15/Mar/11 ]

As far as I can tell we are OK when it comes to closed network upgrade section since there we tell user to run 'asadmin start-domain --upgrade' command which is not affected by this...

This affects only the scenario where user has side-by-side installations and runs 'upgradetool' to upgrade domain config. So, closed network updates (and regular updates) which upgrade the domain config "in place" using asadmin flag should be fine. It doesn't matter if repositories are local or remote.

Comment by Bobby Bissett [ 16/Mar/11 ]

Thanks Snjezana – I didn't get to this yesterday. I agree that we're ok on the closed-network upgrade/update. In fact, we're fine on any update since this only affects the case of upgrading from a 2.X domain. Only 2.X domains have a schema in them, and the stupid stupid stupid code in the upgrade tool tries to check that schema when it parses the domain (and it's only parsing it in order to check a version, nothing else).

So this only affects the internal version checking code in the tool, and doesn't apply to an actual upgrade at all. The "asadmin start-domain --upgrade" workaround is unaffected. To answer Scott's big question, this should probably be in the "correcting potential..." section, as it may be fairly common. (This isn't technically an upgrade problem, but that's irrelevant.) There could be a lot of people doing an upgrade from 2.X internally, and it would be good if they don't have to hunt for this info. Scott, let me know if there's something else you'd like me to do on this.

I will be so happy if/when we drop the upgrade tool for 3.2.

Comment by Scott Fordin [ 08/Apr/11 ]

Added topic to 3.1 Upgrade Guide.

Comment by Scott Fordin [ 13/Apr/11 ]

Also added issue to 3.1 Release Notes.





[GLASSFISH-15037] upgrade tool copies unnecessary files from domainX/../../lib to 3.X Created: 08/Dec/10  Updated: 08/Dec/10  Resolved: 08/Dec/10

Status: Closed
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-15043 document that users must copy 3rd par... Resolved
Tags: 3_1-upgrade

 Description   

From email to admin list:

— begin —
Hi all,

Upgrade tool has this "feature" that attempts to copy 3rd party jars from <gfv2>/lib to glassfish3/glassfish/lib if some user has decided to put jars there instead of in the domain. Ultimately, though, it's the user's responsibility to copy these jars if they exist. The tool, assuming it's used instead of just running asadmin, warns the user if it can't find <source_domain>/../../lib. In some installations of GF, it's just expected that it won't find that dir (e.g. package-based installs).

The copying is a deep copy that processes all files not in an exclude list. An example of one of these lists is here (I don't know how the contents were chosen):
v3/extras/upgrade/upgrade-jar/src/main/resources/com/sun/enterprise/tools/upgrade/common/unixV2LibExcludeList.properties

That all sounds nice, and the user is warned if the lib dir isn't found, but I've realized now that domainX/../../lib could be anything since the domainX directory can be anywhere. Even if it's in the default location, the jar contents aren't the same across all versions of GlassFish. For instance, I installed sges_ee-2_1_1-p08-solaris-sparc.bin to reproduce an issue there and saw that the upgrade tool copied these files over to the 3.1 installation:

Copied file: oam-integration.jar
Copied file: libutilforsyslog64.so
Copied file: modutil
Copied file: libjvminfoutil64.so
Copied file: libustdio.so
Copied file: libicudata.so
Copied file: libicuuc.so.2
Copied file: libicuuc.so
Copied file: libicuctestfw.so.2
Copied file: libustdio.so.2
Copied file: libicui18n.so.2
Copied file: libustdio.a
Copied file: libicutoolutil.so.2
Copied file: libicule.a
Copied file: libicuuc.a
Copied file: libicui18n.so
Copied file: libicudata.a
Copied file: libicutoolutil.a
Copied file: libicui18n.a
Copied file: libicuctestfw.a
Copied file: libicule.so
Copied file: libicutoolutil.so
Copied file: libicule.so.2
Copied file: libicuctestfw.so
Copied file: libicudata.so.2
Copied file: libsqlite3.so
Copied file: libsoftokn3.so
Copied file: libfreebl_32int_3.so
Copied file: libnss3.so
Copied file: libnssdbm3.so
Copied file: libfreebl_32int64_3.so
Copied file: libssl3.so
Copied file: libjss4.so
Copied file: libnssckbi.so
Copied file: libfreebl_32fpu_3.so
Copied file: libnssutil3.so
Copied file: libsmime3.so
Copied file: libnspr4.so
Copied dir: cpu
Copied file: libplds4.so
Copied file: libplc4.so
Copied dir: jdbcdrivers
Copied file: README.pkg

I don't think we want that.

So can I get rid of this "feature?" I can't think of any foolproof way to implement it other than to tell the user to handle it if s/he added any jars where they really shouldn't be anyway. Even if I can create an all-inclusive list of every jar file (and other file) that was ever shipped in GF v2.X or 3.X, there's no way to know that the user hasn't altered one of these jars in his/her installation unless we want to ship a copy of all of them to diff.

Thanks,
Bobby
— end —

Decided in engineering meeting that this can be dropped from the tool.



 Comments   
Comment by Bobby Bissett [ 08/Dec/10 ]

Fixed in revision 43586.

Comment by Bobby Bissett [ 08/Dec/10 ]

self-verifying.





[GLASSFISH-14963] upgrading from v2.1 domain.xml does not add a default-config entry Created: 02/Dec/10  Updated: 07/Dec/10  Resolved: 07/Dec/10

Status: Resolved
Project: glassfish
Component/s: configuration, upgrade_tool
Affects Version/s: None
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: Justin Lee Assignee: Tom Mueller
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-14857 upgrading from v2.1 domain.xml breaks... Closed

 Description   

The resulting domain.xml only has the one config (name="server-config") after upgrading.



 Comments   
Comment by Tom Mueller [ 03/Dec/10 ]

How did you get a v2.1 domain.xml that doesn't have a default-config defined in it?

A domain by default has a default-config in it for 2.1.
Please provide more details on the test case. What commands were executed in v2.1 before performing the upgrade?

Comment by Justin Lee [ 06/Dec/10 ]

I installed v2 and copied out the domain.xml file it created. Otherwise, I haven't touched the file.

Comment by Nazrul [ 06/Dec/10 ]

v2 developer profile does not have default-config in domain.xml.

Comment by Tom Mueller [ 07/Dec/10 ]

A 2.1 developer profile system doesn't have a default-config, so when this is upgraded to 3.1, it is expected to not have a default-config either. If the user wants to use clustering features in 3.1 based on an upgraded 2.1 developer domain, they have several options:

1. Use the 2.1 feature to upgrade the domain to the enterprise profile before upgrading to 3.1.
2. Create a default-config in 3.1 using asadmin copy-config command.

Creating a default-config automatically as part of an upgrade would involve an assumption that the user actually wants that created as part of the upgrade.





[GLASSFISH-14951] Glassfish 2.1.1Patch8 Cluster profile to Glassfish 3.1 Upgrade gives NullPointerException Created: 02/Dec/10  Updated: 17/Feb/11  Resolved: 07/Dec/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 3.1_b31
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: sss150302 Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Redhat Enterprise Linux Server 5.3 ( Linux 5)


Attachments: Text File server-start-domain--upgrade-domain1.log     Text File server-with-new-upgrade-tool-jar.log     Java Archive File upgrade-tool.jar    
Tags: 3_1-upgrade, 3_1-verified, QA, Upgrade, testing

 Description   

Redhat Enterprise Linux Server 5.3 ( Linux 5)

Steps to reproduce:
1)Install glassfish v2.1.1 Patch8.
2) Start the domain and the database
3)create a node agent, and two instance.
4) Deploy some applications.
5)install 3.1 B31 nightly build ( glassfish-3.1-b31-11_19_2010.zip)
6)cd to glassfish3/glassfish/bin and execute
./asupgrade --source ../../../v211p8/asb1/domains/domain1
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at com.sun.enterprise.tools.upgrade.common.VersionExtracter.extractVersionFromConfigFile(VersionExtracter.java:100)
at com.sun.enterprise.tools.upgrade.common.SourceAppSrvObj.getVersionEdition(SourceAppSrvObj.java:72)
at com.sun.enterprise.tools.upgrade.common.BaseDomainInfoObj.getVersion(BaseDomainInfoObj.java:112)
at com.sun.enterprise.tools.upgrade.common.CommonInfoModel.isUpgradeSupported(CommonInfoModel.java:109)
at com.sun.enterprise.tools.upgrade.gui.MainFrame.processArguments(MainFrame.java:437)
at com.sun.enterprise.tools.upgrade.gui.MainFrame.nextButtonActionPerformed(MainFrame.java:307)
at com.sun.enterprise.tools.upgrade.gui.MainFrame.access$200(MainFrame.java:77)
at com.sun.enterprise.tools.upgrade.gui.MainFrame$3.actionPerformed(MainFrame.java:181)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
at java.awt.Component.processMouseEvent(Component.java:6263)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
at java.awt.Component.processEvent(Component.java:6028)
at java.awt.Container.processEvent(Container.java:2041)
at java.awt.Component.dispatchEventImpl(Component.java:4630)
at java.awt.Container.dispatchEventImpl(Container.java:2099)
at java.awt.Component.dispatchEvent(Component.java:4460)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4574)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4238)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
at java.awt.Container.dispatchEventImpl(Container.java:2085)
at java.awt.Window.dispatchEventImpl(Window.java:2478)
at java.awt.Component.dispatchEvent(Component.java:4460)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
[root@ejp-172x-154 bin]# java -version
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)

When this happens asupgrade does nothing.
the domain1 dir is moved to domain1.original, No server.log is generated.



 Comments   
Comment by Bobby Bissett [ 02/Dec/10 ]

Can you tell me where exactly to get v2.1.1 Patch8? Without that, I can't reproduce this.

I'm going to remove the 'blocking' tag. To workaround this, just don't use the upgrade tool. Instead, copy the domain1 directory from the v2.1.1 server to the 3.1 server and run "asadmin start-domain --upgrade". That's all the tool really does.

Comment by Bobby Bissett [ 02/Dec/10 ]

Even without reproducing the issue I can see that the error handling code in that class is a mess. It's an NPE factory. I'll add some more checking to it and attach a new upgrade jar file today to the issue. Maybe you could drop it into your existing installation to test then.

Comment by Bobby Bissett [ 02/Dec/10 ]

Can you please try again with the attached upgrade-tool.jar file? It can replace the one in the glassfish lib directory.

I suspect there was some problem determining the version of your source domain from the domain.xml file, but the code in the tool wasn't providing good error messages. Furthermore, it then assumed it could read your domain.xml and that causes an NPE, which was then caught and a whole new NPE was caused by the catch block!

So this attached jar may not allow you to proceed with the upgrade, but it should at least tell us what the underlying problem is.

Comment by sss150302 [ 02/Dec/10 ]

Linux version of the bundle is :
http://milestone.india.sun.com/java/re/glassfish/v2.1.1-sust/promoted/p08/b01/bundles/sges_ee-2_1_1-p08-linux.bin

Meanwhile I will try with upgrade-tool.jar

Comment by sss150302 [ 02/Dec/10 ]

I copied the domain1 dir form v2.1.1 Patch8 installation to glassfishv3.
Domain is not started with "asadmin start-domain --upgrade domain1" command

I could see a major exception for which already some bug is already filed.
Attaching the server.log

[#|2010-12-03T09:16:45.669+0530|WARNING|glassfish3.1|javax.enterprise.system.util.org.glassfish.enterprise.iiop.util|_ThreadID=22;_ThreadName=Thread-1;|No default ThreadPool defined
com.sun.corba.ee.spi.orbutil.threadpool.NoSuchThreadPoolException
at org.glassfish.enterprise.iiop.util.S1ASThreadPoolManager.getThreadPool(S1ASThreadPoolManager.java:246)
at org.glassfish.enterprise.iiop.util.S1ASThreadPoolManager.getDefaultThreadPool(S1ASThreadPoolManager.java:276)
at com.sun.enterprise.connectors.work.CommonWorkManager.<init>(CommonWorkManager.java:108)
at com.sun.enterprise.connectors.work.WorkManagerFactory.createWorkManager(WorkManagerFactory.java:125)
at com.sun.enterprise.connectors.work.WorkManagerFactory.getWorkManagerProxy(WorkManagerFactory.java:196)
at com.sun.enterprise.connectors.ConnectorRuntime.getWorkManagerProxy(ConnectorRuntime.java:1121)
at com.sun.enterprise.connectors.BootstrapContextImpl.initializeWorkManager(BootstrapContextImpl.java:161)
at com.sun.enterprise.connectors.BootstrapContextImpl.<init>(BootstrapContextImpl.java:103)
at com.sun.enterprise.connectors.ActiveOutboundResourceAdapter.init(ActiveOutboundResourceAdapter.java:126)
at com.sun.enterprise.connectors.inbound.ActiveInboundResourceAdapterImpl.init(ActiveInboundResourceAdapterImpl.java:90)
at com.sun.enterprise.connectors.ActiveRAFactory.instantiateActiveResourceAdapter(ActiveRAFactory.java:135)
at com.sun.enterprise.connectors.ActiveRAFactory.createActiveResourceAdapter(ActiveRAFactory.java:106)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:210)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:344)
at com.sun.enterprise.connectors.ConnectorRuntime.createActiveResourceAdapter(ConnectorRuntime.java:352)
at com.sun.enterprise.connectors.jms.system.JmsProviderLifecycle.initializeBroker(JmsProviderLifecycle.java:110)
at com.sun.enterprise.connectors.jms.system.JmsProviderLifecycle.postConstruct(JmsProviderLifecycle.java:93)
at com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:128)
at com.sun.hk2.component.ConstructorWomb.initialize(ConstructorWomb.java:88)
at com.sun.hk2.component.AbstractWombImpl.get(AbstractWombImpl.java:79)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:64)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:136)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:73)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:326)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
at com.sun.enterprise.v3.server.UpgradeStartup.start(UpgradeStartup.java:171)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
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 com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)

#]

[#|2010-12-03T09:16:45.670+0530|SEVERE|glassfish3.1|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.work|_ThreadID=22;_ThreadName=Thread-1;|Thread-pool [ default thread-pool of server ] not found|#]

[#|2010-12-03T09:16:45.670+0530|SEVERE|glassfish3.1|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.work|_ThreadID=22;_ThreadName=Thread-1;|An error occurred during instantiation of the work manager for resource-adapter [ jmsra ]
com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Thread-pool [ default thread-pool of server ] not found
at com.sun.enterprise.connectors.work.CommonWorkManager.<init>(CommonWorkManager.java:131)
at com.sun.enterprise.connectors.work.WorkManagerFactory.createWorkManager(WorkManagerFactory.java:125)
at com.sun.enterprise.connectors.work.WorkManagerFactory.getWorkManagerProxy(WorkManagerFactory.java:196)
at com.sun.enterprise.connectors.ConnectorRuntime.getWorkManagerProxy(ConnectorRuntime.java:1121)
at com.sun.enterprise.connectors.BootstrapContextImpl.initializeWorkManager(BootstrapContextImpl.java:161)
at com.sun.enterprise.connectors.BootstrapContextImpl.<init>(BootstrapContextImpl.java:103)
at com.sun.enterprise.connectors.ActiveOutboundResourceAdapter.init(ActiveOutboundResourceAdapter.java:126)
at com.sun.enterprise.connectors.inbound.ActiveInboundResourceAdapterImpl.init(ActiveInboundResourceAdapterImpl.java:90)
at com.sun.enterprise.connectors.ActiveRAFactory.instantiateActiveResourceAdapter(ActiveRAFactory.java:135)
at com.sun.enterprise.connectors.ActiveRAFactory.createActiveResourceAdapter(ActiveRAFactory.java:106)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:210)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:344)
at com.sun.enterprise.connectors.ConnectorRuntime.createActiveResourceAdapter(ConnectorRuntime.java:352)
at com.sun.enterprise.connectors.jms.system.JmsProviderLifecycle.initializeBroker(JmsProviderLifecycle.java:110)
at com.sun.enterprise.connectors.jms.system.JmsProviderLifecycle.postConstruct(JmsProviderLifecycle.java:93)
at com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:128)
at com.sun.hk2.component.ConstructorWomb.initialize(ConstructorWomb.java:88)
at com.sun.hk2.component.AbstractWombImpl.get(AbstractWombImpl.java:79)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:64)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:136)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:73)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:326)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
at com.sun.enterprise.v3.server.UpgradeStartup.start(UpgradeStartup.java:171)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
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 com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)

#]
Comment by sss150302 [ 02/Dec/10 ]

server.log for the "asadmin start-domain --upgrade domain1"

Comment by sss150302 [ 02/Dec/10 ]

server.log with new upgrade-too.jar and " asadmin start-domain --upgrade domain1"

Comment by Bobby Bissett [ 03/Dec/10 ]

"Domain is not started with "asadmin start-domain --upgrade domain1" command "

That's right. Doing this performs the upgrade and then the server is shut down. Server log looked normal to me, but you haven't tried the new upgrade-tool.jar file I attached.

You need to run asupgrade to run the upgrade tool. Running asadmin manually is a workaround for if the tool has a bug. Again, the tool does NOT perform upgrades – it just collects data from the user and then runs asadmin.

Comment by sss150302 [ 03/Dec/10 ]

I have tried the new upgrade-tool.jar.
I could start the domain after asadmin start-domain --upgrade domain1 normally
All the deployed applications worked fine after domain startup.

Comment by Bobby Bissett [ 03/Dec/10 ]

No you DID NOT try the new upgrade tool jar if you ran "asadmin start-domain --upgrade"

If you don't believe me, delete the jar and run asadmin again.

Here's a recap of what happens:
1) you run asupgrade
2) the asupgrade script runs an upgrade tool inside upgrade-tool.jar
3) the upgrade tool runs "asadmin start-domain --upgrade" to perform the upgrade
4) asadmin exits after the upgrade
5) the upgrade tool says the upgrade is finished
6) you can then start the domain normally with asadmin

If you start with step 3 and run the upgrade manually, you are not using any code in upgrade-tool.jar. I told you how to do the upgrade manually so you wouldn't be blocked by a bug in the tool.

Comment by Bobby Bissett [ 07/Dec/10 ]

I haven't recreated the original failure, but I can see how it would happen if the domain.xml file in the source domain could not be read for some reason. I've committed code in revision 43542 to handle this.

Now, if there's an error like not having the right permissions on domain.xml to parse it, the upgrade log will contain:

Could not create xml document object from file name /Users/bobby/work/gfv2/dev/glassfish/domains/domain1/config/domain.xml due to: java.io.FileNotFoundException: /Users/bobby/work/gfv2/dev/glassfish/domains/domain1/config/domain.xml (Permission denied)

If there is some problem in the xml itself, this will come out in the log:

Could not create xml document object from file name /Users/bobby/work/gfv2/dev/glassfish/domains/domain1/config/domain.xml due to: org.xml.sax.SAXParseException: Content is not allowed in prolog.

Before, any errors like these were being ignored and then an NPE resulted by trying to parse a non-existent xml Document object. Let me know if you're seeing any other troubles.





[GLASSFISH-14898] Cluster fails to start after upgrade - No free port within range: newPort=com.sun.enterprise.v3.services.impl.monitor.MonitorableSelectorHandler Created: 30/Nov/10  Updated: 01/Dec/10  Resolved: 01/Dec/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 3.1_b31
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Amy Roh Assignee: Amy Roh
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File domain.xml     XML File domain.xml     Text File server.log     Text File server.log    
Issue Links:
Dependency
blocks GLASSFISH-14497 web-specific task for upgrade test Resolved
Tags: 3_1-upgrade

 Description   

Followed cluster upgrade example from http://wikis.sun.com/display/GlassFish/V3.1ClusterUpgradeExample

After installing v2.1.1 and creating local cluster and instances,

a new virtual server "test-server" and http listener "test-listener-1" listening to port 7777 were created on cluster1-config. Deployed web application "hello" and made sure the web app is accessible on the instances and also on newly created http listener port 7777.

After installing v3.1, upgrade, and recreating instances, cluster cannot be started

bash-3.2$ ./asadmin start-cluster cluster1
in1: Could not start instance in1 on node na1 (amys-macbook-pro.local).

Command failed on node na1 (amys-macbook-pro.local): Waiting for in1 to start ................................Command start-local-instance failed.

Error starting instance in1.
The server exited prematurely with exit code 0.

[#|2010-11-30T16:44:37.223-0800|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=main;|Shutting down v3 due to startup exception : No free port within range: 7777=com.sun.enterprise.v3.services.impl.monitor.MonitorableSelectorHandler@367720d7|#]

server.log, v3 domain.xml, and v2 domain.xml are attached



 Comments   
Comment by Bobby Bissett [ 30/Nov/10 ]

This isn't an upgrade tool issue, because the upgrade tool doesn't perform upgrades (it just runs asadmin start-domain --upgrade).

Without more information, there's nothing I can do with this. Please give the steps to create the virtual server and new listener. Also, since the instance wouldn't start, we need the instance's server.log file to see what the error is.

Without the virtual server and new listener, the upgrade works fine. So my guess is that this is an issue for the configuration, web, or grizzly areas.

Comment by Amy Roh [ 30/Nov/10 ]

In order to reproduce the error, create-http-listener in v2 and upgrade to v3.1

asadmin create-http-listener --listeneraddress 0.0.0.0 --listenerport 7777 --defaultvs server --target cluster1 test-listener

The instance fails to start with this error -

[#|2010-11-30T18:32:10.807-0800|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=17;_ThreadName=Thread-1;|Shutting down v3 due to startup exception : No free port within range: 7777=com.sun.enterprise.v3.services.impl.monitor.MonitorableSelectorHandler@6750cf54|#]

Attaching instance log and assigning to MonitorableSelectorHandler author, Alexey, for initial investigation.

Comment by Amy Roh [ 30/Nov/10 ]

Instance log file.

[#|2010-11-30T18:32:10.807-0800|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=17;_ThreadName=Thread-1;|Shutting down v3 due to startup exception : No free port within range: 7777=com.sun.enterprise.v3.services.impl.monitor.MonitorableSelectorHandler@6750cf54|#]

Comment by Amy Roh [ 01/Dec/10 ]

Apparently this is expected. V2 after creating http-listener at port 7777 cannot be started on both instances because the port is being shared by two instances.

[#|2010-11-30T18:19:13.876-0800|SEVERE|sun-appserver2.1|javax.enterprise.system.container.web|_ThreadID=18;_ThreadName=RMI TCP Connection(21)-192.168.0.11;_RequestID=a93615e0-b3bb-41b8-803c-0b59f53b23bd;|WEB0701: Error initializing endpoint
java.net.BindException: Address already in use: 7777

From Bobby,

"So I think it's actually working as expected. The other http listeners use a variable for their port such as port="$

{HTTP_LISTENER_PORT}

and then this is set in a system property for the particular instance. But you've set "7777" on the config, and so both instances try to use it and can't, both before and after the upgrade."

Comment by Amy Roh [ 01/Dec/10 ]

Not a bug.





[GLASSFISH-14590] upgrade-tool.jar needs to be excluded from common class loader's class path Created: 10/Nov/10  Updated: 26/Nov/10  Resolved: 10/Nov/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Bug Priority: Blocker
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-11683 GlassFish v3 ignores logback.xml with... Resolved
Issuezilla Id: 14,590

 Description   

When upgrade-tool.jar was moved to glassfish/lib/, nobody updated its manifest
to indicate that it needed to be excluded from common classloader's classpath as
a result of which not only it, but also all its referenced jars (some 30 odd
jars) are now added to common class loader's classpath. This must be affecting
application class loading performance.

Fix:
Add the following manifest header in this jar:

GlassFish-ServerExcluded true

Any jar in lib/ having this manifest is automatically excluded from being part
of common class loader. e.g., javaee.jar.

I suggest someone like Tom or Hong who are looking into application class
loading performance handedit this jar in their environment and do a test to see
if this really helps improve performance.



 Comments   
Comment by Sanjeeb Sahoo [ 10/Nov/10 ]

Taking ownership, as this is not just a performance bug, but it actually affects
functionality. It leaks internal server classes to applications and hence issue
11683 depends on this.
I will be applying the following patch:
ss141213@Sahoo:/space/ss141213/WS/gf/v3$ svn diff extras/upgrade/upgrade-jar/pom.xml
Index: extras/upgrade/upgrade-jar/pom.xml
===================================================================
— extras/upgrade/upgrade-jar/pom.xml (revision 42642)
+++ extras/upgrade/upgrade-jar/pom.xml (working copy)
@@ -69,6 +69,11 @@
</manifest>
<manifestEntries>
<Class-Path>../modules/common-util.jar
../lib/javahelp.jar ../lib/upgrade-branding.jar
../lib/upgrade-tool-l10n.jar</Class-Path>
+ <!-- See GlassFish issue 14590:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=14590
+ Adding the following manifest entry causes
this jar to be not part of application common class loader.
+ It must not be part of application common
class loader, as it would make internal gf classes visible
+ to applications in addition to slowing down
classloading. By Sahoo. -->
+
<GlassFish-ServerExcluded>true</GlassFish-ServerExcluded>
</manifestEntries>
</archive>
</configuration>

Comment by Sanjeeb Sahoo [ 10/Nov/10 ]

ss141213@Sahoo:/space/ss141213/WS/gf/v3$ svn commit -m "Issue #14590: Exclude
upgrade-tool.jar from being part of common class loader by adding
GlassFish-ServerExcluded: true manifest header" extras/upgrade/
Sending extras/upgrade/upgrade-jar/pom.xml
Transmitting file data .
Committed revision 42705.

Comment by Sanjeeb Sahoo [ 10/Nov/10 ]

removed [PERF} from synopsys as it is more importantly a functionality bug.





[GLASSFISH-14305] Unable to navigate in Upgrade Page to "select folder" Created: 29/Oct/10  Updated: 01/Dec/10  Resolved: 01/Dec/10

Status: Closed
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: Alex Pineda Assignee: Bobby Bissett
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: Sun


Issuezilla Id: 14,305
Tags: 3_1-upgrade

 Description   

Unable to select the target directory folder in asupgrade page. The steps to
reproduce the issue are:

  • invoke <GF3.1_Dir>/bin/asupgrade
  • On asupgrade page, select "browse" in the "Source Domain Directory"
  • A "Select Folder" window will appear.
  • Select a directory (or folder)
  • Attempt to navigate to a subdirectoy (or subfolder), is not possible.

Workaround is to go back to "cancel" the "Select Folder" window and manually
enter the path to the "Source Domain Directory".

This problem is seen on Solaris 10, RHEL 5, but not on MacOS, which may point to
a JDK issue (and not an asupgrade problem).



 Comments   
Comment by Bobby Bissett [ 01/Dec/10 ]

I've had a couple people try this on the listed systems and have tried it myself on Solaris 10. We haven't seen this behavior, so I'm afraid it's something specific to your systems. Snjezana said she could take a look on your machines some time when you're both there (since it'd be hard for me to walk over!).





[GLASSFISH-13778] upgrade tool log messages of WARNING and SEVERE Created: 04/Oct/10  Updated: 04/Oct/10  Resolved: 04/Oct/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: adf59 Assignee: adf59
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 13,778

 Description   

I notice the following WARNING and SEVERE log messages after using asupgrade
tool to upgrade a V2.1.1 developer profile domain with a web app deployed to V3.1.

[#|2010-09-23T14:22:22.498-0400|SEVERE|sun-appserver2.1|javax.enterprise.system.core.security|_ThreadID=10;_ThreadName=main;[
[
Version: V1
Subject: OU=Secure Server Certification Authority, O="RSA Data Security,
Inc.", C=US
Signature Algorithm: MD2withRSA, OID = 1.2.840.113549.1.1.2

Key: Sun RSA public key, 1000 bits
modulus:
6144706769222379850430183405655235862870193813433361902309516534729547168229223442088128897090426025874990958624426272027915771330043379079076269082776443120496525109458437435793974957144923190172655546279112796066635455545786300647745888353781002359412766112775410851780140804282673804950495744761467
public exponent: 65537
Validity: [From: Tue Nov 08 19:00:00 EST 1994,
To: Thu Jan 07 18:59:59 EST 2010]
Issuer: OU=Secure Server Certification Authority, O="RSA Data Security, Inc.",
C=US
SerialNumber: [ 02ad667e 4e45fe5e 576f3c98 195eddc0]

]
Algorithm: [MD2withRSA]
Signature:
0000: 65 DD 7E E1 B2 EC B0 E2 3A E0 EC 71 46 9A 19 11 e.......:..qF...
0010: B8 D3 C7 A0 B4 03 40 26 02 3E 09 9C E1 12 B3 D1 ......@&.>......
0020: 5A F6 37 A5 B7 61 03 B6 5B 16 69 3B C6 44 08 0C Z.7..a..[.i;.D..
0030: 88 53 0C 6B 97 49 C7 3E 35 DC 6C B9 BB AA DF 5C .S.k.I.>5.l....\
0040: BB 3A 2F 93 60 B6 A9 4B 4D F2 20 F7 CD 5F 7F 64 .:/.`..KM. .._.d
0050: 7B 8E DC 00 5C D7 FA 77 CA 39 16 59 6F 0E EA D3 ....\..w.9.Yo...
0060: B5 83 7F 4D 4D 42 56 76 B4 C9 5F 04 F8 38 F8 EB ...MMBVv.._..8..
0070: D2 5F 75 5F CD 7B FC E5 8E 80 7C FC 50 .u........P

];_RequestID=6b85f5e1-c84d-491d-bfd2-15f6b5970eaf;|SEC5054: Certificate has
expired: [
[
Version: V1
Subject: OU=Secure Server Certification Authority, O="RSA Data Security,
Inc.", C=US
Signature Algorithm: MD2withRSA, OID = 1.2.840.113549.1.1.2

Key: Sun RSA public key, 1000 bits
modulus:
6144706769222379850430183405655235862870193813433361902309516534729547168229223442088128897090426025874990958624426272027915771330043379079076269082776443120496525109458437435793974957144923190172655546279112796066635455545786300647745888353781002359412766112775410851780140804282673804950495744761467
public exponent: 65537
Validity: [From: Tue Nov 08 19:00:00 EST 1994,
To: Thu Jan 07 18:59:59 EST 2010]
Issuer: OU=Secure Server Certification Authority, O="RSA Data Security, Inc.",
C=US
SerialNumber: [ 02ad667e 4e45fe5e 576f3c98 195eddc0]

]
Algorithm: [MD2withRSA]
Signature:
0000: 65 DD 7E E1 B2 EC B0 E2 3A E0 EC 71 46 9A 19 11 e.......:..qF...
0010: B8 D3 C7 A0 B4 03 40 26 02 3E 09 9C E1 12 B3 D1 ......@&.>......
0020: 5A F6 37 A5 B7 61 03 B6 5B 16 69 3B C6 44 08 0C Z.7..a..[.i;.D..
0030: 88 53 0C 6B 97 49 C7 3E 35 DC 6C B9 BB AA DF 5C .S.k.I.>5.l....\
0040: BB 3A 2F 93 60 B6 A9 4B 4D F2 20 F7 CD 5F 7F 64 .:/.`..KM. .._.d
0050: 7B 8E DC 00 5C D7 FA 77 CA 39 16 59 6F 0E EA D3 ....\..w.9.Yo...
0060: B5 83 7F 4D 4D 42 56 76 B4 C9 5F 04 F8 38 F8 EB ...MMBVv.._..8..
0070: D2 5F 75 5F CD 7B FC E5 8E 80 7C FC 50 .u........P

]|#]
.
.
.
[#|2010-09-23T14:24:49.334-0400|WARNING|sun-appserver2.1|org.apache.coyote.tomcat5.CoyoteRequest|_ThreadID=15;_ThreadName=httpWorkerThread-4848-4;_RequestID=a6e2057b-481c-459d-b887-0e1647c661d3;|PWC4011:
Unable to set request character encoding to UTF-8 from context , because request
parameters have already been read, or ServletRequest.getReader() has already
been called|#]
.
.
.
[#|2010-09-27T12:37:26.542-0400|SEVERE|sun-appserver2.1|javax.enterprise.system.core.security|_ThreadID=10;_ThreadName=main;[
[
Version: V1
Subject: OU=Secure Server Certification Authority, O="RSA Data Security,
Inc.", C=US
Signature Algorithm: MD2withRSA, OID = 1.2.840.113549.1.1.2

Key: Sun RSA public key, 1000 bits
modulus:
6144706769222379850430183405655235862870193813433361902309516534729547168229223442088128897090426025874990958624426272027915771330043379079076269082776443120496525109458437435793974957144923190172655546279112796066635455545786300647745888353781002359412766112775410851780140804282673804950495744761467
public exponent: 65537
Validity: [From: Tue Nov 08 19:00:00 EST 1994,
To: Thu Jan 07 18:59:59 EST 2010]
Issuer: OU=Secure Server Certification Authority, O="RSA Data Security, Inc.",
C=US
SerialNumber: [ 02ad667e 4e45fe5e 576f3c98 195eddc0]

]
Algorithm: [MD2withRSA]
Signature:
0000: 65 DD 7E E1 B2 EC B0 E2 3A E0 EC 71 46 9A 19 11 e.......:..qF...
0010: B8 D3 C7 A0 B4 03 40 26 02 3E 09 9C E1 12 B3 D1 ......@&.>......
0020: 5A F6 37 A5 B7 61 03 B6 5B 16 69 3B C6 44 08 0C Z.7..a..[.i;.D..
0030: 88 53 0C 6B 97 49 C7 3E 35 DC 6C B9 BB AA DF 5C .S.k.I.>5.l....\
0040: BB 3A 2F 93 60 B6 A9 4B 4D F2 20 F7 CD 5F 7F 64 .:/.`..KM. .._.d
0050: 7B 8E DC 00 5C D7 FA 77 CA 39 16 59 6F 0E EA D3 ....\..w.9.Yo...
0060: B5 83 7F 4D 4D 42 56 76 B4 C9 5F 04 F8 38 F8 EB ...MMBVv.._..8..
0070: D2 5F 75 5F CD 7B FC E5 8E 80 7C FC 50 .u........P

];_RequestID=35cd6899-8863-42aa-a301-2c8fc2503cbc;|SEC5054: Certificate has
expired: [
[
Version: V1
Subject: OU=Secure Server Certification Authority, O="RSA Data Security,
Inc.", C=US
Signature Algorithm: MD2withRSA, OID = 1.2.840.113549.1.1.2

Key: Sun RSA public key, 1000 bits
modulus:
6144706769222379850430183405655235862870193813433361902309516534729547168229223442088128897090426025874990958624426272027915771330043379079076269082776443120496525109458437435793974957144923190172655546279112796066635455545786300647745888353781002359412766112775410851780140804282673804950495744761467
public exponent: 65537
Validity: [From: Tue Nov 08 19:00:00 EST 1994,
To: Thu Jan 07 18:59:59 EST 2010]
Issuer: OU=Secure Server Certification Authority, O="RSA Data Security, Inc.",
C=US
SerialNumber: [ 02ad667e 4e45fe5e 576f3c98 195eddc0]

]
Algorithm: [MD2withRSA]
Signature:
0000: 65 DD 7E E1 B2 EC B0 E2 3A E0 EC 71 46 9A 19 11 e.......:..qF...
0010: B8 D3 C7 A0 B4 03 40 26 02 3E 09 9C E1 12 B3 D1 ......@&.>......
0020: 5A F6 37 A5 B7 61 03 B6 5B 16 69 3B C6 44 08 0C Z.7..a..[.i;.D..
0030: 88 53 0C 6B 97 49 C7 3E 35 DC 6C B9 BB AA DF 5C .S.k.I.>5.l....\
0040: BB 3A 2F 93 60 B6 A9 4B 4D F2 20 F7 CD 5F 7F 64 .:/.`..KM. .._.d
0050: 7B 8E DC 00 5C D7 FA 77 CA 39 16 59 6F 0E EA D3 ....\..w.9.Yo...
0060: B5 83 7F 4D 4D 42 56 76 B4 C9 5F 04 F8 38 F8 EB ...MMBVv.._..8..
0070: D2 5F 75 5F CD 7B FC E5 8E 80 7C FC 50 .u........P

]|#]
.
.
.
[#|2010-09-27T12:37:37.767-0400|WARNING|sun-appserver2.1|javax.enterprise.system.tools.admin|_ThreadID=10;_ThreadName=main;_RequestID=35cd6899-8863-42aa-a301-2c8fc2503cbc;|Not
registering AMX MBean against old MBean
"com.sun.appserv:j2eeType=WebModule,name=HelloWorldWebApp,J2EEServer=server,J2EEApplication=null,category=runtime"
due to malformed composite WebModule name.|#]



 Comments   
Comment by Bobby Bissett [ 04/Oct/10 ]

None of these messages are coming from the upgrade tool. Are they in the server
log or upgrade log?

You should send the security messages to the security team, and the tomcat
message to maybe the web team. Reassigning to follow up with the proper teams.
You might want to just ask on the dev team to find out why these are happening
(sending separate emails for the different messages may get you better answers).

Comment by adf59 [ 04/Oct/10 ]

server.log file had extraneous stuff left in log V2.1.1 run of server which
makes this invalid





[GLASSFISH-13591] tool copies incorrect v2 jar files to v3 install Created: 23/Sep/10  Updated: 08/Dec/10  Resolved: 06/Oct/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 13,591
Tags: 3_1-upgrade

 Description   

To recreate:

1) Install GF v2.1.1, developer profile
2) Start, server, log into admin console, stop server
3) Unzip 3.1 installation
4) Run v3/bin/asupgrade tool and choose the v2.1.1 domain1 directory as the source
5) Start the v3 server and try to log into the admin console

I see lots and lots of stack traces at this point and can't log in. (No point
listing them out here since I think I know the cause.) However, if I skip step 4
above and instead do (don't forget to unzip v3 zip again):

4a) rm -rf v3/domains/domain1
4b) cp -R v2/domains/domain1 v3/domains/
4c) v3/bin/asadmin start-domain --upgrade

...then I can log into the admin console ok in step 5. I think that these jar
files, which are being copied by the tool into the v3 installation, are the problem:

asm-3.1.jar
jackson-asl-0.9.4.jar
jersey-bundle-1.0.3.1.jar
jettison-1.0.1.jar
jsr311-api-1.0.jar

Am testing a fix for this now. Filing the issue to track it.



 Comments   
Comment by Bobby Bissett [ 27/Sep/10 ]

Fixed in revision 41134.

hostname% svn commit extras/upgrade
Sending
extras/upgrade/upgrade-jar/src/main/resources/com/sun/enterprise/tools/upgrade/common/macV2LibExcludeList.properties
Sending
extras/upgrade/upgrade-jar/src/main/resources/com/sun/enterprise/tools/upgrade/common/unixV2LibExcludeList.properties
Sending
extras/upgrade/upgrade-jar/src/main/resources/com/sun/enterprise/tools/upgrade/common/winV2LibExcludeList.properties

Comment by adf59 [ 28/Sep/10 ]

I verified the latest fixes to this bug and the admin screen now comes up fine
after an upgrade via asupgrade tool.





[GLASSFISH-12356] clean up upgrade module metadata Created: 23/Jun/10  Updated: 07/Jul/10  Resolved: 07/Jul/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: v3.0.1
Fix Version/s: 3.1_ms03

Type: New Feature Priority: Critical
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 12,356

 Description   

The upgrade tool jar doesn't need to be an OSGi jar file.



 Comments   
Comment by Bobby Bissett [ 23/Jun/10 ]

Adding target milestone.

Comment by Bobby Bissett [ 07/Jul/10 ]

Fixed in revision 38396. Made jar into a plain jar file, not OSGi related.





[GLASSFISH-12146] have tool check for WARNING level output Created: 04/Jun/10  Updated: 12/Jul/10  Resolved: 12/Jul/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: 3.1_ms03

Type: New Feature Priority: Major
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 12,146

 Description   

It already checks for SEVERE. Just add WARNING to the pattern in Commands.java
as well. If we end up with too many constant warnings, will revisit.



 Comments   
Comment by Bobby Bissett [ 04/Jun/10 ]

Accepted, set milestone 2 target.

Comment by Bobby Bissett [ 29/Jun/10 ]

Moving target milestone to M3 to make time for some higher priority work.

Comment by Bobby Bissett [ 12/Jul/10 ]

Fixed in revision 38561.





[GLASSFISH-11924] upgrade tool swallows asadmin output Created: 18/May/10  Updated: 23/Sep/10  Resolved: 23/Sep/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: 3.1_ms05

Type: Bug Priority: Major
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 11,924

 Description   

So it doesn't get overlooked: asadmin tool sends client and server output to std
out/err, and upgrade tool parses this info. The server output includes log level
information and the tool can automatically check this for SEVERE messages to
warn the user. Info from the asadmin client side does not contain this
information, and isn't in the server.log file.

So the upgrade tool should send the client log information to the upgrade.log
file so it's not lost. While the info can't be automatically parsed, at least
it's there for the user in cases where, for instance, asadmin exits with a non
zero exit code.



 Comments   
Comment by Bobby Bissett [ 18/May/10 ]

Should be simple enough to do after 3.0.1 work. The server output follows a
certain format that the client output does not use. I can give the reader
threads a proper handle on a logger and have them log anything that doesn't
start with the expected chars.

Comment by Bobby Bissett [ 07/Jul/10 ]

Setting milestone rather than simply 3.1 final.

Comment by Bobby Bissett [ 19/Aug/10 ]

Moving these bug fixes to post ms4.

Comment by Bobby Bissett [ 23/Sep/10 ]

Fixed in revision 41070.

Files:
Sending
extras/upgrade/upgrade-jar/src/main/java/com/sun/enterprise/tools/upgrade/UpgradeToolMain.java
Sending
extras/upgrade/upgrade-jar/src/main/java/com/sun/enterprise/tools/upgrade/common/Commands.java
Sending
extras/upgrade/upgrade-jar/src/main/java/com/sun/enterprise/tools/upgrade/common/DomainsProcessor.java
Sending
extras/upgrade/upgrade-jar/src/main/resources/com/sun/enterprise/tools/upgrade/LocalStrings.properties
Sending
extras/upgrade/upgrade-jar/src/main/resources/com/sun/enterprise/tools/upgrade/common/LocalStrings.properties





[GLASSFISH-11854] tool not reporting errors/warnings from upgrade Created: 04/May/10  Updated: 05/May/10  Resolved: 05/May/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 11,854

 Description   

Saw this once during some testing and need to verify that it's actually working,
or fix if not. The asadmin command output is parsed for warning or error
messages and the tool is supposed to warn the user if one is encountered, but I
saw a server log containing a warning that did not appear in the tool as well.

Would be good to have this fixed in 3.0.1.



 Comments   
Comment by Bobby Bissett [ 05/May/10 ]

Output switched from "<LEVEL>:<text>" to "<text>|<LEVEL>|<text>" somewhere along
the line. Am changing regex pattern to match now. Can change it to just look for
the level string by itself if this continues to be an issue. That could result
in some false positives, but that's better than missing an error.

Testing now....

Comment by Bobby Bissett [ 05/May/10 ]

Fixed in the 3.0.1 branch, revision 36781.





[GLASSFISH-11823] JAVA_HOME required -- not required for asadmin Created: 26/Apr/10  Updated: 20/May/10  Resolved: 20/May/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: 3.1

Type: Bug Priority: Major
Reporter: emiddio Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Attachments: Text File asupgrade.bat    
Issuezilla Id: 11,823

 Description   

copied from email

if i set JAVA_HOME it will run; JAVA_HOME not needed for asadmin.bat for
gfv3.

not needed for any commands used for derby or gfv2.x – that i have used;

never used asupgrade.bat before;

changed "echo off" to "echo of" for both – to show differences for
defalt invocations with JAVA_HOME not set;

i see "
" in the output – surprised that works and is not syntax error.

thanks
gary
===============================

asadmin.bat —

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>asadmin

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM Copyright 1997-2008 Sun
Microsystems, Inc. All rights reserved.

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM Use is subject to license
terms.

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM Always use JDK 1.6 or higher

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM Depends on Java from
..\config\asenv.bat

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>VERIFY OTHER 2>nul

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>setlocal ENABLEEXTENSIONS

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>if ERRORLEVEL 0 goto ok

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>call
"C:\Sun\glassfish-3.0.1-b15\glassfish\bin\..\config\asenv.bat"

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM DO NOT ALTER OR REMOVE
COPYRIGHT NOTICES OR THIS HEADER.

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM Copyright 2004-2009 Sun
Microsystems, Inc. All rights reserved.

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM Use is subject to License Terms

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set AS_IMQ_LIB=..\..\mq\lib

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set AS_IMQ_BIN=..\..\mq\bin

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set AS_CONFIG=..\config

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set AS_INSTALL=..

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set AS_DEF_DOMAINS_PATH=..\domains

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set AS_DERBY_INSTALL=..\..\javadb

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>if "x" == "x" goto UsePath

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set JAVA=java

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>java -jar
"C:\Sun\glassfish-3.0.1-b15\glassfish\bin\..\modules\admin-cli.jar"
Use "exit" to exit and "help" for online help.
asadmin>

asupgrade.bat ----------

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>asupgrade

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM Copyright (c) 1997, 2010
Oracle and/or its affiliates, Inc. All rights reserved.

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM Use is subject to license
terms.

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>setlocal

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set
DIRNAME=C:\Sun\glassfish-3.0.1-b15\glassfish\bin\

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set
AS_INSTALL=C:\Sun\glassfish-3.0.1-b15\glassfish\bin
..

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set
AS_INSTALL_LIB=C:\Sun\glassfish-3.0.1-b15\glassfish\bin\\..\lib

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set
AS_INSTALL_MOD=C:\Sun\glassfish-3.0.1-b15\glassfish\bin\\..\modules

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set
CONFIG_HOME=C:\Sun\glassfish-3.0.1-b15\glassfish\bin\\..\config

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>call
"C:\Sun\glassfish-3.0.1-b15\glassfish\bin\\..\config\asenv.bat"

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM DO NOT ALTER OR REMOVE
COPYRIGHT NOTICES OR THIS HEADER.

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM Copyright 2004-2009 Sun
Microsystems, Inc. All rights reserved.

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM Use is subject to License Terms

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>REM

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set AS_IMQ_LIB=..\..\mq\lib

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set AS_IMQ_BIN=..\..\mq\bin

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set AS_CONFIG=..\config

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set AS_INSTALL=..

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set AS_DEF_DOMAINS_PATH=..\domains

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set AS_DERBY_INSTALL=..\..\javadb

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>set AS_JAVA=

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>"\bin\java"
-Dcom.sun.aas.domainRoot="C:\Sun\glassfish-3.0.1-b15\glassfish\bin\\..\domains"
-Dcom.sun.aas.java.home="" -jar
"C:\Sun\glassfish-3.0.1-b15\glassfish\bin\\..\modules/upgrade-tool.jar"
The system cannot find the path specified.

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>endlocal

C:\Sun\glassfish-3.0.1-b15\glassfish\bin>



 Comments   
Comment by Bobby Bissett [ 05/May/10 ]

Thanks for filing this. Will fix it today in the 3.0.1 branch. I've tried it on
a borrowed windows machine and it's working for me, but can you try the script
as well? I'll attach it to this issue right after this update.

As for the double backslash, I guess that's just windows magic. I can do both:

> dir a\b
> dir a
b

...and get the same results. Maybe it's equivalent to \.\ – I should have tried
3,4,n backslashes while I had the machine....

Comment by Bobby Bissett [ 05/May/10 ]

Created an attachment (id=4339)
batch script for starting asupgrade tool

Comment by Bobby Bissett [ 06/May/10 ]

Fixed in the 3.0.1 branch, revision 36805.

Comment by Bobby Bissett [ 07/May/10 ]

Also removed setlocal/endlocal lines. See issue 6838 for details.





[GLASSFISH-11581] asupgrade fails with "File source doesn't exist" Created: 17/Feb/10  Updated: 13/Dec/10

Status: Open
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: v2.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: kurti Assignee: tanujakotappa
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 11,581
Tags: future-exclude

 Description   

I try to update from GF v2.1 to v2.1.1 and get this Exception:

java.lang.IllegalArgumentException: File source doesn't exist
at com.sun.enterprise.util.io.FileUtils.copy(FileUtils.java:957)
at com.sun.enterprise.util.io.FileUtils.copy(FileUtils.java:938)
at
com.sun.enterprise.tools.upgrade.common.UpgradeUtils.copyFile(UpgradeUtils.java:
928)
at
com.sun.enterprise.tools.upgrade.realm.RealmUpgrade.backup(RealmUpgrade.java:205
)
at
com.sun.enterprise.tools.upgrade.realm.RealmUpgrade.upgrade(RealmUpgrade.java:18
6)
at
com.sun.enterprise.tools.upgrade.UpgradeHarness.invokeModules(UpgradeHarness.jav
a:202)
at
com.sun.enterprise.tools.upgrade.UpgradeHarness.startUpgrade(UpgradeHarness.java
:116)
at
com.sun.enterprise.tools.upgrade.UpgradeToolMain.upgrade(UpgradeToolMain.java:17
9)
at
com.sun.enterprise.tools.upgrade.UpgradeToolMain.processUIEvent(UpgradeToolMain.
java:169)
at
com.sun.enterprise.tools.upgrade.UpgradeToolMain.access$000(UpgradeToolMain.java
:51)
at
com.sun.enterprise.tools.upgrade.UpgradeToolMain$1.dialogProcessed(UpgradeToolMa
in.java:142)
at
com.sun.enterprise.tools.upgrade.gui.MainFrame$UpgradeActionThread.run(MainFrame
.java:378)

This is in the server logs:

java.lang.IllegalArgumentException: File source doesn't exist
at com.sun.enterprise.util.io.FileUtils.copy(FileUtils.java:957)
at com.sun.enterprise.util.io.FileUtils.copy(FileUtils.java:938)
at
com.sun.enterprise.tools.upgrade.common.UpgradeUtils.copyFile(UpgradeUtils.java:
928)
at
com.sun.enterprise.tools.upgrade.realm.RealmUpgrade.backup(RealmUpgrade.java:205
)
at
com.sun.enterprise.tools.upgrade.realm.RealmUpgrade.upgrade(RealmUpgrade.java:18
6)
at
com.sun.enterprise.tools.upgrade.UpgradeHarness.invokeModules(UpgradeHarness.jav
a:202)
at
com.sun.enterprise.tools.upgrade.UpgradeHarness.startUpgrade(UpgradeHarness.java
:116)
at
com.sun.enterprise.tools.upgrade.UpgradeToolMain.upgrade(UpgradeToolMain.java:17
9)
at
com.sun.enterprise.tools.upgrade.UpgradeToolMain.processUIEvent(UpgradeToolMain.
java:169)
at
com.sun.enterprise.tools.upgrade.UpgradeToolMain.access$000(UpgradeToolMain.java
:51)
at
com.sun.enterprise.tools.upgrade.UpgradeToolMain$1.dialogProcessed(UpgradeToolMa
in.java:142)
at
com.sun.enterprise.tools.upgrade.gui.MainFrame$UpgradeActionThread.run(MainFrame
.java:378)

#]

[#|2010-02-17T17:43:53.819+0100|WARNING|sun-
appserver2.1|javax.enterprise.system.core.security|_ThreadID=10;_ThreadName=main
;SA-Shop-Realm;_RequestID=6da610cf-d12c-42d5-85fb-fcf6feb1c3a3;|SEC1100:
Disabled realm [SA-Shop-Realm] due to errors.|#]

[#|2010-02-17T17:43:53.820+0100|WARNING|sun-
appserver2.1|javax.enterprise.system.core.security|_ThreadID=10;_ThreadName=main
;_RequestID=6da610cf-d12c-42d5-85fb-fcf6feb1c3a3;|SEC1000: Caught exception.
com.sun.enterprise.security.auth.realm.BadRealmException:
com.sun.enterprise.security.auth.realm.BadRealmException:
java.io.FileNotFoundException: /opt/glassfish-v2.1.1/domains/domain1/config/SA-
Shop-Realm.keys (No such file or directory)
at
com.sun.enterprise.security.auth.realm.Realm.doInstantiate(Realm.java:239)
at
com.sun.enterprise.security.auth.realm.Realm.instantiate(Realm.java:165)
at
com.sun.enterprise.security.RealmConfig.createRealms(RealmConfig.java:93)
at
com.sun.enterprise.security.RealmConfig.createRealms(RealmConfig.java:163)
at
com.sun.enterprise.security.SecurityLifecycle.onInitialization(SecurityLifecycle
.java:113)
at
com.sun.enterprise.server.ApplicationServer.onInitialization(ApplicationServer.j
ava:265)
at
com.sun.enterprise.server.ondemand.OnDemandServer.onInitialization(OnDemandServe
r.java:103)
at com.sun.enterprise.server.PEMain.run(PEMain.java:399)
at com.sun.enterprise.server.PEMain.main(PEMain.java:336)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.server.PELaunch.main(PELaunch.java:415)
Caused by: com.sun.enterprise.security.auth.realm.BadRealmException:
java.io.FileNotFoundException: /opt/glassfish-v2.1.1/domains/domain1/config/SA-
Shop-Realm.keys (No such file or directory)
at
com.sun.enterprise.security.auth.realm.file.FileRealm.loadKeyFile(FileRealm.java
:804)
at
com.sun.enterprise.security.auth.realm.file.FileRealm.init(FileRealm.java:217)
at
com.sun.enterprise.security.auth.realm.Realm.doInstantiate(Realm.java:233)
... 13 more

#]


 Comments   
Comment by tanujakotappa [ 22/Feb/10 ]

Pls elaborate the set-up details

Comment by tanujakotappa [ 22/Feb/10 ]

Assigning to Tanuja

Comment by kurti [ 22/Feb/10 ]

Pls elaborate, what you need.

I guess you want to know this:

The domain has a FileRealm "SA-Shop-Realm", which is configured with this key
file:

$

{com.sun.aas.instanceRoot}

/config/SA-Shop-Realm.keys

Comment by tanujakotappa [ 22/Feb/10 ]

I did the side-by-side upgrade successfully on Linux m/c without any Exception.
Pls give me the steps to reproduce this issues where i can face the given
Exception..

Comment by kurti [ 22/Feb/10 ]

I just deleted the FileRealm and upgraded without a problem, so this looks like
the problem. It has been created on 2.1 using this command:

asadmin create-auth-realm --classname
com.sun.enterprise.security.auth.realm.file.FileRealm --property
'file=$

{com.sun.aas.instanceRoot}

/config/SA-Shop-Realm.keys:jaas-
context=fileRealm' SA-Shop-Realm

Comment by tanujakotappa [ 22/Feb/10 ]

I did the side-by-side upgrade successfully on Linux m/c without any Exception.
Pls give me the steps to reproduce this issues where i can face the given
Exception..

Comment by tanujakotappa [ 22/Feb/10 ]

You mean to say upgrade works fine and after upgrade if i execute the following
command, i will hit the Exception???

asadmin create-auth-realm --classname
com.sun.enterprise.security.auth.realm.file.FileRealm --property
'file=$

{com.sun.aas.instanceRoot}

/config/SA-Shop-Realm.keys:jaas-
context=fileRealm' SA-Shop-Realm

Comment by kurti [ 22/Feb/10 ]

No, the other way round:

if the FileRealm exists in 2.1, then the upgrade fails

if I delete the FileRealm in 2.1, then it works

Comment by Bobby Bissett [ 08/Oct/10 ]

Adding future-exclude keyword as this issue does not apply to the 3.X upgrade
tool. The target milestone needs to be reset appropriately.





[GLASSFISH-11418] UnrecoverableKeyException: Cannot recover key after upgrade Created: 11/Jan/10  Updated: 13/Dec/10

Status: Open
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: v2.1.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: jomu78 Assignee: roisinflannery
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File domain1_upgrade.log    
Issuezilla Id: 11,418
Tags: future-exclude

 Description   

After an upgrade from 2.1 to 2.1.1 with set admin and master password the
following exception occurred.

[#|2010-01-11T10:23:11.900+0100|WARNING|sun-appserver2.1|javax.enterprise.system.stream.err|_ThreadID=10;_ThreadName=main;_RequestID=733cc7ca-7481-4fb3-8516-6a53f78d4837;|java.lang.reflect.InvocationTargetException
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 com.sun.enterprise.server.PELaunch.main(PELaunch.java:415)
Caused by: java.lang.ExceptionInInitializerError
at
com.sun.enterprise.security.SecurityLifecycle.onInitialization(SecurityLifecycle.java:101)
at
com.sun.enterprise.server.ApplicationServer.onInitialization(ApplicationServer.java:265)
at
com.sun.enterprise.server.ondemand.OnDemandServer.onInitialization(OnDemandServer.java:103)
at com.sun.enterprise.server.PEMain.run(PEMain.java:399)
at com.sun.enterprise.server.PEMain.main(PEMain.java:336)
... 5 more
Caused by: java.lang.IllegalStateException:
java.security.UnrecoverableKeyException: Cannot recover key
at com.sun.enterprise.security.SSLUtils.<clinit>(SSLUtils.java:128)
... 10 more
Caused by: java.security.UnrecoverableKeyException: Cannot recover key
at sun.security.provider.KeyProtector.recover(KeyProtector.java:311)
at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:121)
at sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:38)
at java.security.KeyStore.getKey(KeyStore.java:763)
at
com.sun.net.ssl.internal.ssl.SunX509KeyManagerImpl.<init>(SunX509KeyManagerImpl.java:113)
at
com.sun.net.ssl.internal.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:48)
at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:239)
at com.sun.enterprise.security.SSLUtils.initKeyManagers(SSLUtils.java:320)
at com.sun.enterprise.security.SSLUtils.<clinit>(SSLUtils.java:106)
... 10 more



 Comments   
Comment by jomu78 [ 11/Jan/10 ]

workaround: reset the masterpassword using the asadmin tool
asadmin change-master-password --save-master-password <domainname>

Comment by jomu78 [ 11/Jan/10 ]

Created an attachment (id=4153)
domain upgrade log

Comment by Bobby Bissett [ 11/Jan/10 ]

Thanks for including the workaround. I'll see if this is something that will be fixed in sustaining
engineering or not.

Comment by roisinflannery [ 19/Feb/10 ]

Assigning to myself

Comment by roisinflannery [ 23/Feb/10 ]

Unable to reproduce:

1) I installed sges2.1
/space/roisin/sges21

2) Changed the masterpassword:
asadmin change-master-password --savemasterpassword=true

3) Installed sges211
/space/roisin/211

4) Perform the upgrade
/space/roisin/211/bin/asupgrade -c -s /space/roisin/9083/sges21/domains/domain1
-t /space/roisin/9083/211

Valid values for source and Target are as follows :

If upgrading from Sun Java System Application Server 8.x or 9.x, specify domain
directory for Source. The target directory should be the domains root.

Enter the Admin User:admin
Enter the Admin Password:
Enter the Master password: **NEW PASSWORD ENTERED HERE**
Starting Upgrade Harness
(....text removed...)
Finished Upgrade
/.asadminpass removed.
Deleting Temporary password files

5) Start up 211 and it worked fine, no errors.

-------Analysis---------

From my tests, upgrade works correctly with new master password from 2.1. I
think that perhaps you are confused between --savemasterpassword=true, and
passwordfile option?

--savemasterpassword=true saves the master password into .asadminpass in the
home dir, and it is encoded
--passwordfile is an option you can pass in, pointing to your own file where the
passwords are in plaintext.

Does this make it more clear? Please let me know if I am missing a step in
reproducing this?

Comment by Bobby Bissett [ 08/Oct/10 ]

Adding future-exclude keyword as this issue does not apply to the 3.X upgrade
tool. The target milestone needs to be reset appropriately.





[GLASSFISH-11406] Graphic in Upgrade Wizard needs updating Created: 07/Jan/10  Updated: 20/May/10  Resolved: 20/May/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: 3.1

Type: Improvement Priority: Major
Reporter: Kim Haase Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 11,406

 Description   

When you run the Upgrade Wizard in v3, the graphic on the left side of the
window says "Sun Java System Application Server." The equivalent graphic for
"Sun GlassFish Enterprise Server" needs to be used instead.



 Comments   
Comment by Bobby Bissett [ 07/Jan/10 ]

Good catch. Bad graphic.

Seems like more of a bureaucratic issue than a technical one to get a new graphic made and/or approved.
Will have this fixed either very soon or very very not soon.

Comment by Bobby Bissett [ 31/Mar/10 ]

Started this thread for more info:
https://glassfish.dev.java.net/servlets/ReadMsg?list=dev&msgNo=16832
Am following up with Nazrul about it.

Comment by Bobby Bissett [ 05/May/10 ]

This is fixed in 3.0.1, revision 36367.





[GLASSFISH-11179] upgrade from 2.1 to 2.1.1 causes GUI issue Created: 25/Nov/09  Updated: 22/Feb/10  Resolved: 22/Feb/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: v2.1.1
Fix Version/s: V3

Type: Bug Priority: Critical
Reporter: Anissa Lam Assignee: roisinflannery
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Linux


Issuezilla Id: 11,179
Status Whiteboard:

v3_exclude


 Description   

This is reported in issue#7407.
Since issue# 7407 is for a different scenario, I am opening this one.
From the comment from #7407:

------- Additional comments from funwithsun Wed Nov 25 17:43:52 +0000 2009 -------

I don't believe this issue was fixed completely. Going from GF 2.1 (9.1_02
Patch09) to 2.1.1 (9.1_02 Patch12) using this file: sges-2_1_1-linux-ml.bin in
linux causes the HTTP 500 issue to appear in the Admin Console. After several
hours of troubleshooting, removing just this file: jsftemplating-1.2-SAILFIN.jar
resolves the Admin Console issue.

The two remaining templating files now are:
rw-rr- 1 root root 132712 Nov 24 14:14 jsftemplating-dynafaces-0.1.jar
rw-rr- 1 root root 422259 Nov 24 14:14 jsftemplating.jar



 Comments   
Comment by Anissa Lam [ 25/Nov/09 ]

doesn't apply to v3.

Comment by funwithsun [ 25/Nov/09 ]

BTW, this is easily repeatable by doing the following in Linux:

Installing this bundle alone works:

java_ee_sdk-507-linux.bin

Installing this bundle alone works:

java_ee_sdk-5_08-jdk-6u17-linux.bin

Installing this bundle:

java_ee_sdk-507-linux.bin

..and upgrading using this patch, causes the Admin Console HTTP Status 500 issue:

sges-2_1_1-linux-ml.bin

Hope this helps..

Comment by roisinflannery [ 19/Feb/10 ]

Reassigning to myself

Comment by roisinflannery [ 22/Feb/10 ]

This has already been fixed in cr 6901069
http://monaco.sfbay.sun.com/detail.jsf?cr=6901069





[GLASSFISH-11065] Command-line option -V / --version doesn't work Created: 17/Nov/09  Updated: 20/Jan/10  Resolved: 20/Jan/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Minor
Reporter: Kim Haase Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 11,065

 Description   

In the current GlassFish builds (I used Hudson build 3398), the commands

asupgrade -V
asupgrade --version

produce no output at all. The Upgrade Guide has been saying they display the
version of the upgrade tool.



 Comments   
Comment by Bobby Bissett [ 20/Jan/10 ]

Found the problem – it's sending the output to the upgrade.log file instead of someplace obvious.

Fixed in revision 35402.





[GLASSFISH-11013] [REGRESSION] got MarshalException for ssl/security Created: 12/Nov/09  Updated: 13/Nov/09  Resolved: 13/Nov/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Critical
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File sec-ssl-converterApp.ear     Text File server.log    
Issuezilla Id: 11,013

 Description   

Sideybside upgrade from v2.1 to v3 build 72 on linux 5.0 and cli mode
Using build v3 latest-glassfish.zip from http://glassfish.dev.java.net
11-Nov-2009 16:14 73M

After upgrade to v3, could not run get client stubs for application

Steps to reproduce:
1) install v2.1, start domain

2) checkout quicklooks test

set variables:
set CVSROOT to :pserver:<your java.net id>@cvs.dev.java.net:/cvs
set APS_HOME to point to <quicklooks workspace>/appserv-tests
set S1AS_HOME to point to appserver or glassfish server
set JAVA_HOME to point to 1.6.0_14
set ANT_HOME to point to 1.6.5
set PATH to point to $ANT_HOME/bin:$JAVA_HOME/bin:$PATH

cvs login
cvs co -r SJSAS91_FCS_BRANCH glassfish/appserv-tests

cd <workspace>/appserv-tests/sqetests/security/ssl/converter

execute ant clean build setup deploy run (do not run "ant undeploy unsetup")

3) stop domain1

4) install v3

5) run "asupgrade" tool from <v3 installation>/bin/asupgrade -c

After upgrade, run the test manually:

[root@easqelx14 converter]# /usr/nga/v3/glassfishv3/glassfish/bin/asadmin
get-client-stubs --appname sec-ssl-converterApp .

Command get-client-stubs executed successfully.
[root@easqelx14 converter]# /usr/nga/v3/glassfishv3/glassfish/bin/appclient
-client ./sec-ssl-converterAppClient.jar
Nov 12, 2009 8:36:01 AM
com.sun.enterprise.transaction.JavaEETransactionManagerSimplified initDelegates
INFO: Using
com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate as the
delegate
Default Context Initialized...
Value of key is: Converter Sample AppClient
Caught an unexpected exception!
java.rmi.MarshalException: CORBA COMM_FAILURE 1398079691 Maybe; nested exception is:
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 203 completed: Maybe
at
com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:270)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:200)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:147)
at
com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:225)
at
com.sun.s1peqe.security.ssl.converter.ejb._ConverterRemoteHome_DynamicStub.create(com/sun/s1peqe/security/ssl/converter/ejb/_ConverterRemoteHome_DynamicStub.java)
at
com.sun.s1peqe.security.ssl.converter.client.ConverterClient.run(ConverterClient.java:115)
at
com.sun.s1peqe.security.ssl.converter.client.ConverterClient.main(ConverterClient.java:72)
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.glassfish.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:424)
at
org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:151)
at
org.glassfish.appclient.client.AppClientGroupFacade.main(AppClientGroupFacade.java:64)
Caused by: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 203 completed:
Maybe
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.writeErrorSend(ORBUtilSystemException.java:3462)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.sendWithoutLock(SocketOrChannelConnectionImpl.java:1127)
at
com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.sendFragment(BufferManagerWriteStream.java:148)
at
com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.sendMessage(BufferManagerWriteStream.java:162)
at
com.sun.corba.ee.impl.encoding.CDROutputObject.finishSendingMessage(CDROutputObject.java:180)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.finishSendingRequest(CorbaMessageMediatorImpl.java:276)
at
com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete1(CorbaClientRequestDispatcherImpl.java:392)
at
com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete(CorbaClientRequestDispatcherImpl.java:364)
at
com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:235)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:187)
... 12 more
Caused by: javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected
error: java.security.InvalidAlgorithmParameterException: the trustAnchors
parameter must be non-empty
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1611)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1574)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1557)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1483)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:86)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.readFully(SocketOrChannelConnectionImpl.java:653)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.read(SocketOrChannelConnectionImpl.java:477)
at
com.sun.corba.ee.impl.protocol.giopmsgheaders.MessageBase.readGIOPHeader(MessageBase.java:133)
at
com.sun.corba.ee.impl.protocol.giopmsgheaders.MessageBase.readGIOPMessage(MessageBase.java:121)
at
com.sun.corba.ee.impl.transport.CorbaContactInfoBase.createMessageMediator(CorbaContactInfoBase.java:150)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.readBits(SocketOrChannelConnectionImpl.java:374)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.read(SocketOrChannelConnectionImpl.java:341)
at
com.sun.corba.ee.impl.transport.ReaderThreadImpl.doWork(ReaderThreadImpl.java:118)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:492)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:528)
Caused by: java.lang.RuntimeException: Unexpected error:
java.security.InvalidAlgorithmParameterException: the trustAnchors parameter
must be non-empty
at sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:59)
at sun.security.validator.Validator.getInstance(Validator.java:161)
at
com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.getValidator(X509TrustManagerImpl.java:108)
at
com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:204)
at
com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:249)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1014)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:124)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516)
at
com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:454)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1112)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:744)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
... 10 more
Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors
parameter must be non-empty
at
java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:183)
at java.security.cert.PKIXParameters.<init>(PKIXParameters.java:103)
at
java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:87)
at sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:57)
... 22 more
Generating report at
/usr/nga/v3/workspace/v2/glassfish/appserv-tests/test_results.xml

-----------------------------------------

  • Converter Sample AppClient: FAIL -
    -----------------------------------------
    Total PASS: 0
    Total FAIL: 1
    Total DID NOT RUN: 0
    -----------------------------------------
    in flushAll , creating new testSuiteHash
    in flushAll , creating new testSuiteHash


 Comments   
Comment by 1xpert [ 12/Nov/09 ]

Created an attachment (id=3895)
log

Comment by 1xpert [ 12/Nov/09 ]

forgot to set priority P2

Comment by Bobby Bissett [ 12/Nov/09 ]

Before I try this, can you confirm that the manual steps work with v2.1 before upgrading?

Comment by Bobby Bissett [ 13/Nov/09 ]

Note: there is no 'setup' target so these instructions are incorrect:

hostname$ pwd
/Users/bobby/work/ws/glassfish/appserv-tests/sqetests/security/ssl/converter
hostname$ ant clean build setup deploy run
[...]
BUILD FAILED
Target "setup" does not exist in the project "SSLconverterApp".

Am using this instead:
ant clean build deploy run

Comment by Bobby Bissett [ 13/Nov/09 ]

The instructions given do not work for the original v2.1 server, so I wouldn't expect them to work with
the upgraded domain either. Please check to make sure you can run the test manually against v2.1 and
update the issue with new instructions if you can run it. My output is below.

hostname$ ../glassfish/bin/asadmin version
Version = Sun GlassFish Enterprise Server v2.1
Command version executed successfully.

hostname$ ../glassfish/bin/appclient -client ./sec-ssl-converterAppClient.jar
Default Context Initialized...
Nov 13, 2009 10:23:17 AM com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread
run
WARNING: "IOP00710311: (INTERNAL) Worker thread Thread[p: default-threadpool; w: 3,5,ORB
ThreadGroup] caught throwable while executing work."
org.omg.CORBA.INTERNAL: vmcid: SUN minor code: 311 completed: No
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.workerThreadDoWorkThrowable(ORBUtilSystem
Exception.java:7703)
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.workerThreadDoWorkThrowable(ORBUtilSystem
Exception.java:7722)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:558)
Caused by: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 203 completed: No
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.writeErrorSend(ORBUtilSystemException.java:27
21)
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.writeErrorSend(ORBUtilSystemException.java:27
43)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.writeLock(SocketOrChannelConnecti
onImpl.java:1065)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.close(SocketOrChannelConnectionIm
pl.java:804)
at com.sun.corba.ee.impl.transport.ReaderThreadImpl.doWork(ReaderThreadImpl.java:124)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)
Nov 13, 2009 10:23:17 AM com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread
run
[etc]

With the same server running, the test works in the sqe test harness:

dhcp-ubur02-71-34:converter bobby$ pwd
/Users/bobby/work/ws/glassfish/appserv-tests/sqetests/security/ssl/converter
dhcp-ubur02-71-34:converter bobby$ ant run
Buildfile: build.xml

[...]
[exec]
[exec] -----------------------------------------
[exec] - Converter Sample AppClient: PASS -
[exec] -----------------------------------------
[exec] Total PASS: 1
[exec] Total FAIL: 0
[exec] Total DID NOT RUN: 0
[exec] -----------------------------------------
[exec] in flushAll , creating new testSuiteHash
[exec] in flushAll , creating new testSuiteHash

[...]

BUILD SUCCESSFUL
Total time: 5 seconds

Comment by Bobby Bissett [ 13/Nov/09 ]

Created an attachment (id=3905)
ear file to deploy into the server for testing

Comment by Bobby Bissett [ 13/Nov/09 ]

Note from an email thread concerning this issue: the appclient call below has worked in the past with v3;
see issue 9739. It is not working now however with v2.1 or v3. We're trying to figure out why.

Comment by Bobby Bissett [ 13/Nov/09 ]

Here is how the test harness is actually running the test, though I've replaces the app client jar with the
locally downloaded one:

<path>/appclient -client <path>/sec-ssl-converterAppClient.jar -textauth -user temp -password
temp -xml ../domains/domain1/config/sun-acc.xml

With VMARGS set in the environment as:
"-Djavax.net.ssl.trustStore=<path>/glassfish/domains/domain1/config/cacerts.jks -
Djavax.net.ssl.trustStorePassword=changeit"

With those command options and vm arguments I see the test working with both v2.1 and v3, though
there's an error in the test reporting mechanism since I'm skipping some test step. The output for both
servers is here:

--begin--
Default Context Initialized...

===========Beginning Simple Test=====

$100 is : 12160.00Yen
Yen is :0.77Euro
Value of key is: Converter Sample AppClient
Reporter exception occurred!
--end--





[GLASSFISH-11003] [REGRESSION] could not generate stubs Created: 12/Nov/09  Updated: 12/Nov/09  Resolved: 12/Nov/09

Status: Closed
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Critical
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File server.log    
Issuezilla Id: 11,003

 Description   

Sideybside upgrade from v2.1 to v3 build 72 on linux 5.0 and cli mode
Using build v3 latest-glassfish.zip from http://glassfish.dev.java.net
11-Nov-2009 16:14 73M

After upgrade to v3, could not run get client stubs for application

Steps to reproduce:
1) install v2.1, start domain

2) checkout quicklooks test

set variables:
set CVSROOT to :pserver:<your java.net id>@cvs.dev.java.net:/cvs
set APS_HOME to point to <quicklooks workspace>/appserv-tests
set S1AS_HOME to point to appserver or glassfish server
set JAVA_HOME to point to 1.6.0_14
set ANT_HOME to point to 1.6.5
set PATH to point to $ANT_HOME/bin:$JAVA_HOME/bin:$PATH

cvs login
cvs co -r SJSAS91_FCS_BRANCH glassfish/appserv-tests

cd <workspace>/appserv-tests/sqetests/ejb/stateful/passivate

execute ant clean build setup deploy run (do not run "ant undeploy unsetup")

3) stop domain1

4) install v3

5) run "asupgrade" tool from <v3 installation>/bin/asupgrade -c

After upgrade, run the test manually:

[root@easqelx14 passivate]# $S1AS_HOME/bin/asadmin get-client-stubs --appname
ejb-sfsblifecycleApp .
com.sun.enterprise.admin.cli.CommandException: remote failure: Application
ejb-sfsblifecycleApp was not found

I checked applications directory in v3, it shows the app exists:

[root@easqelx14 passivate]# ls -al $S1AS_HOME/domains/domain1/applications/
total 36
drwxr-xr-x 9 root root 4096 Nov 12 05:37 .
drwxr-xr-x 17 root root 4096 Nov 12 05:37 ..
drwxr-xr-x 6 root root 4096 Nov 12 05:37 ejb-cmp-rosterApp
drwxr-xr-x 5 root root 4096 Nov 12 05:37 ejb-ejb30-hello-sessionApp
drwxr-xr-x 5 root root 4096 Nov 12 05:37 ejb-mdb-simpleApp
drwxr-xr-x 5 root root 4096 Nov 12 05:37 ejb-sfsblifecyleApp
drwxr-xr-x 2 root root 4096 Nov 12 05:36 lifecycle-modules
drwxr-xr-x 2 root root 4096 Nov 12 05:36 mbeans
drwxr-xr-x 5 root root 4096 Nov 12 05:37 sec-ssl-converterApp

[root@easqelx14 passivate]# echo $S1AS_HOME
/usr/nga/v3/glassfishv3/glassfish



 Comments   
Comment by 1xpert [ 12/Nov/09 ]

Created an attachment (id=3886)
log

Comment by Bobby Bissett [ 12/Nov/09 ]

Am rebuilding workspace now. Can you try this:

asadmin get-client-stubs --appname ejb-sfsblifecyleApp .

...instead of the text you pasted? From the text you have below, there is a spelling error in the application
name. Also check in admin console to see the deployed applications – they may be different than the dir
names in the application directory.

Comment by Bobby Bissett [ 12/Nov/09 ]

Following the instructions, I get the error with 2.1 as well:

hostname$ ../glassfish/bin/asadmin get-client-stubs --appname ejb-sfsblifecycleApp .
Invalid application name: ejb-sfsblifecycleApp

However, this works for both servers. v2.1:

hostname$ ../glassfish/bin/asadmin get-client-stubs --appname ejb-sfsblifecyleApp .
Command get-client-stubs executed successfully.

v3:

hostname$ ../glassfishv3/glassfish/bin/asadmin get-client-stubs --appname ejb-sfsblifecyleApp .

Command get-client-stubs executed successfully.
hostname$ ls -l
total 8
drwxr-xr-x 6 bobby staff 204 Nov 12 16:51 ejb-sfsblifecyleAppClient
rw-rr- 1 bobby staff 1061 Nov 12 16:50 ejb-sfsblifecyleAppClient.jar
hostname$

So I think this is just a typo in the test name. Give it a shot with the actual deployed name and let me
know if there are other problems.

Comment by 1xpert [ 12/Nov/09 ]

Did you upgrade before issuing the get-client-stubs in v3?

Comment by Bobby Bissett [ 12/Nov/09 ]

If I hadn't upgraded to v3, then I wouldn't have been able to download the stubs, right? You have a typo.
Please try what I asked and you'll see it.

"ejb-sfsblifecycleApp" != "ejb-sfsblifecyleApp"

Comment by 1xpert [ 12/Nov/09 ]

invalid





[GLASSFISH-10444] could not access admin gui, http port Created: 20/Oct/09  Updated: 21/Oct/09  Resolved: 21/Oct/09

Status: Closed
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: v2.1.1
Fix Version/s: v2.1.1

Type: Bug Priority: Critical
Reporter: 1xpert Assignee: 1xpert
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Attachments: Text File server.log     Text File upgrade.log    
Issuezilla Id: 10,444
Status Whiteboard:

v3_exclude


 Description   

Could not access admin gui after inplace upgrade from v2.1 to v2.1.1 on suse linux

When I access the brower, I got error:

The connection was interrupted
The connection to bigapp-opteron-3.red.iplanet.com:4848 was interrupted while
the page was loading.

Steps to reproduce:
1) install sges_ee_2_1-linux.bin from
/net/figaro.sfbay/export/legacy_repo/stable/glassfish/2.1/linux
choose Nodeagent, DAS, samples
2) start domain, deploy some application

3) stop domain

4) install sges_ee-2_1_1-fcs-bin-b31g-linux-19_oct_2009.bin from
http://javaweb.sfbay.sun.com/java/re/glassfish_branch/2.1.1/promoted/fcs/31g/bundles
in the same directory as previous installation

5) during installation, choose option to Upgrade, proceed to end of installation

6) invoke <v2.1.1 installation>/bin/asupgrade, gives source and target values



 Comments   
Comment by 1xpert [ 20/Oct/09 ]

Created an attachment (id=3565)
server's log

Comment by 1xpert [ 20/Oct/09 ]

Created an attachment (id=3566)
upgrade.log

Comment by kumara [ 20/Oct/09 ]

Changing target milestone and excluding from v3 list because the issue is specific to v2.x.

Comment by rebeccas [ 20/Oct/09 ]

This is not a bug. The user should not be running upgrade tool for a 2.1 to
2.1.1 inplace upgrade. The user should only install the 2.1.1 on top of the 2.1
and then run start-domain.

Comment by 1xpert [ 20/Oct/09 ]

Also could not access http port 8080, 38081, 38084 (instances port of a cluster)

Comment by 1xpert [ 21/Oct/09 ]

Issue is specific to machine environment

Comment by 1xpert [ 21/Oct/09 ]

Closing issue since I could access the application on mac machine. Puneet was
able to access the application on 3 machines.

Comment by 1xpert [ 21/Oct/09 ]

Closing issue





[GLASSFISH-10039] [BLOCKING] appserver hang after upgrade Created: 06/Oct/09  Updated: 04/Nov/09  Resolved: 04/Nov/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Critical
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Attachments: File hellojsf.war     Text File server.log     Text File server.log     Text File server.log    
Issuezilla Id: 10,039

 Description   

Sidebyside upgrade from v3 prelude to v3 nightly build 10/01/09 on linux

Appserver hangs after upgrading to v3. See attached logs.

Steps to reproduce:
1) install v3 prelude, start domain1, start derby
2) checkout v3 prelude quicklook test as followed:

need to have subversion-1.6.5
need to set environment variables JAVA_HOME, ANT_HOME, S1AS_HOME (glassfish
location), PATH to point to ANT_HOME\bin, JAVA_HOME\bin,SVN_HOME\bin

svn co https://svn.dev.java.net/svn/glassfish-svn/tags/glassfish-3.0-Prelude-
b28c/tests
cd <workspace>\tests\quicklook\classloader\hellojsf
ant -Dglassfish.home=%S1AS_HOME% build deploy runtest

3) stop domain1

4) install v3 glassfish build 10/01/09 called latest-glassfishi.zip from
http://download.java.net/glassfish/v3/promoted/

latest-glassfish.zip 01-Oct-2009 14:09 74M

  1. pwd
    /usr/nga/v3/glassfishv3/glassfish
  2. bin/asadmin version
    Version string could not be obtained from Server [localhost:4848] for some reason.
    (Turn debugging on e.g. by setting AS_DEBUG=true in your environment, to see the
    details).
    Using locally retrieved version string from version class.
    Version = GlassFish v3.0-b66 (build 66)
    Command version executed successfully.

5) invoke asupgrade tool from <v3 installation>/bin/asupgrade -c
give source and target values

6) start v3 domain1 — Server hangs



 Comments   
Comment by 1xpert [ 06/Oct/09 ]

Created an attachment (id=3445)
v3's server.log

Comment by 1xpert [ 06/Oct/09 ]

Created an attachment (id=3447)
v3 prelude's server.log

Comment by 1xpert [ 06/Oct/09 ]

For fresh checkout of quicklooks tests first time only:

In step 2 after executing – svn co
https://svn.dev.java.net/svn/glassfish-svn/tags/glassfish-3.0-Prelude-
b28c/tests

Need apache maven 2.2.1 installation

Execute command "mvn -Dglassfish.home=<v3 prelude installation> test" to
download all dependencies

Comment by Bobby Bissett [ 07/Oct/09 ]

With build 66, I do see this behavior. The asadmin process never exits, but I can get to localhost:8080
in a browser – the server isn't hanging, but it hasn't finished starting yet.

From server log:
[#|2009-10-07T13:13:55.766-
0400|WARNING|glassfish|org.jvnet.hk2.osgimain|_ThreadID=11;_ThreadName=Thread-3;|Exception
while starting bundle com.sun.enterprise.osgi-adapter [130]
org.osgi.framework.BundleException: Activator start error in bundle com.sun.enterprise.osgi-adapter
[130].
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1750)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1621)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:890)
at org.jvnet.hk2.osgimain.Main.start(Main.java:124)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:667)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1699)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1621)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1076)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:637)
Caused by: com.sun.enterprise.module.ResolveError: Not able to locate a unique module by name
org.glassfish.jsftemplating
at
com.sun.enterprise.v3.server.ClassLoaderHierarchyImpl.createApplicationParentCL(ClassLoaderHierarch
yImpl.java:166)
at
org.glassfish.deployment.common.DeploymentContextImpl.createClassLoader(DeploymentContextImpl.
java:187)
at
org.glassfish.deployment.common.DeploymentContextImpl.createDeploymentClassLoader(Deployment
ContextImpl.java:172)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:218)
at
com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.jav
a:331)
at
com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:17
3)
at com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:174)
at com.sun.hk2.component.ConstructorWomb$1.run(ConstructorWomb.java:91)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.hk2.component.ConstructorWomb.initialize(ConstructorWomb.java:88)
at com.sun.hk2.component.AbstractWombImpl.get(AbstractWombImpl.java:77)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:58)
at com.sun.hk2.component.LazyInhabitant.get(LazyInhabitant.java:107)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:60)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:243)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:130)
at com.sun.enterprise.module.bootstrap.Main.launch(Main.java:457)
at com.sun.enterprise.module.bootstrap.Main.launch(Main.java:401)
at org.jvnet.hk2.osgiadapter.HK2Main.start(HK2Main.java:121)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:667)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1699)
... 9 more

I'm going to try this with a more current build to see if it's still happening.

Comment by Bobby Bissett [ 08/Oct/09 ]

The behavior is different with a current build. Asadmin start-domain returns successfully, but in the
server log I see this (the original prelude domain had the classloader/hellojsf quicklook test deployed):

[...]
[#|2009-10-07T14:48:08.131-0400|INFO|glassfish|null|_ThreadID=15;_ThreadName=Thread-
3;|Grizzly Framework started in: 270ms listening on port 4848|#]

[#|2009-10-07T14:48:08.131-0400|INFO|glassfish|null|_ThreadID=16;_ThreadName=Thread-
3;|Grizzly Framework started in: 435ms listening on port 8080|#]

[#|2009-10-07T14:48:09.757-
0400|WARNING|glassfish|org.jvnet.hk2.osgimain|_ThreadID=11;_ThreadName=Thread-3;|Exception
while starting bundle com.sun.enterprise.osgi-adapter [131]
org.osgi.framework.BundleException: Activator start error in bundle com.sun.enterprise.osgi-adapter
[131].
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1750)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1621)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:890)
at org.jvnet.hk2.osgimain.Main.start(Main.java:124)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:667)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1699)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1621)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1076)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:637)
Caused by: com.sun.enterprise.module.ResolveError: Not able to locate a unique module by name
org.glassfish.jsftemplating
at
com.sun.enterprise.v3.server.ClassLoaderHierarchyImpl.createApplicationParentCL(ClassLoaderHierarch
yImpl.java:166)
at
org.glassfish.deployment.common.DeploymentContextImpl.createClassLoader(DeploymentContextImpl.
java:187)
at
org.glassfish.deployment.common.DeploymentContextImpl.createDeploymentClassLoader(Deployment
ContextImpl.java:172)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at
com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.jav
a:340)
at
com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:16
3)
at com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:174)
at com.sun.hk2.component.ConstructorWomb$1.run(ConstructorWomb.java:91)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.hk2.component.ConstructorWomb.initialize(ConstructorWomb.java:88)
at com.sun.hk2.component.AbstractWombImpl.get(AbstractWombImpl.java:77)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:58)
at com.sun.hk2.component.LazyInhabitant.get(LazyInhabitant.java:107)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:60)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:233)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:129)
at com.sun.enterprise.module.bootstrap.Main.launch(Main.java:457)
at com.sun.enterprise.module.bootstrap.Main.launch(Main.java:401)
at org.jvnet.hk2.osgiadapter.HK2Main.start(HK2Main.java:121)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:667)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1699)
... 9 more

And the last message in the log is:

[#|2009-10-07T14:48:09.892-
0400|INFO|glassfish|org.glassfish.web.osgi|_ThreadID=20;_ThreadName=Thread-3;|Waiting for Server
to start|#]

After that I can hit localhost:8080 and 4848, but the latter doesn't actually load the admin console. Am
just watching the "loading in progress screen" with this message over and over:

[#|2009-10-07T15:00:53.360-0400|INFO|glassfish|null|_ThreadID=23;_ThreadName=Thread-
3;|AdminConsoleAdapter's STATE IS: The Admin Console is loading...|#]

And, finally, I can't stop the server normally:

hostname% ^start^stop
./bin/asadmin stop-domain domain1
CLI306 Warning - server is not running.
Command stop-domain executed successfully.

Comment by dochez [ 29/Oct/09 ]

I think this is an upgrade issue, seems like 2 jsftemplating bundles are installed after update
see the error message :
Not able to locate a unique module by name
org.glassfish.jsftemplating

re-assigning to Snjezana for further investigation.

Comment by Snjezana Sevo-Zenzerovic [ 29/Oct/09 ]

As per bug scrub discussion, this is not an issue with the packaging or
updatetool since scenario was side-by-side upgrade. So, any changes to the
content of target installation were done by asupgrade. The working hypothesis is
that QL application adds libraries which should be cleaned up during upgrade.
Reassigning to Bobby.

Comment by Bobby Bissett [ 02/Nov/09 ]

As a reminder, this is a valid upgrade path: "asadmin start-domain old_domain"

The asupgrade tool is not needed to perform an upgrade, and I see this bug without using the tool at
all:
1. run the test on a prelude server
2. copy the prelude domain to v3/domains
3. start server (see log)

So we're back to my original question: should someone clean up the extra bits, should the server
somehow ignore them, or is this an invalid case? The web app is deployed with the jsf jar in WEB-
INF/lib:

hostname% ls ~/servers/glassfishv3/glassfish/domains/domain1/applications/hellojsf/WEB-INF/lib
jsftemplating-dynafaces-0.1.jar

If that's a valid use case, then the server should distinguish between bits loaded from the modules
directory and from the application itself:

hostname% find ~/servers/glassfishv3/glassfish | grep jsftemplating
/Users/bobby/servers/glassfishv3/glassfish/domains/domain1/applications/hellojsf/WEB-
INF/lib/jsftemplating-dynafaces-0.1.jar
/Users/bobby/servers/glassfishv3/glassfish/modules/jsftemplating.jar

Comment by Bobby Bissett [ 02/Nov/09 ]

Created an attachment (id=3715)
server log of domain before, during, and after upgrade

Comment by Bobby Bissett [ 02/Nov/09 ]

Note: deploying the web app directly to a v3 server fails with the same error (I'll attach the war), so this is
either a deployment/classloading issue or not a valid test case.

Comment by Bobby Bissett [ 02/Nov/09 ]

Created an attachment (id=3716)
web app used in test. does not deploy directly into v3

Comment by Bobby Bissett [ 03/Nov/09 ]

Per eng meeting, am reassigning to look into class loading issue. Simplest way to reproduce: just deploy
the hellojsf war file that is attached to this issue. If that app deploys, then the upgrade test should be
fixed (feel free to assign it back to me to check.)

Comment by kumara [ 03/Nov/09 ]

-> Real user id of sahoo

Comment by Sanjeeb Sahoo [ 03/Nov/09 ]

The application (hellojsf.war) is invalid. Whoever has written the app needs to
explain why they have added the following manifest entry:

HK2-Import-Bundles org.glassfish.jsftemplating

which is causing the deployment to fail because there is no bundle with symbolic
name org.glassfish.jsftemplating; there is one by the name com.sun.jsftemplating.

Without this manifest entry, the app runs fine.

Comment by Bobby Bissett [ 04/Nov/09 ]

Thanks for the info. Since this was a prelude test, maybe there was some prelude-specific functionality
that was being tested. I removed that entry from the manifest and the test still runs fine against prelude
however. I then upgraded and there were no problems – could upgrade, start up, and access web app. So
I'm closing this as invalid due to a bug in the web app.





[GLASSFISH-9996] need correct usage error when user gives incorrect input Created: 05/Oct/09  Updated: 07/Oct/09  Resolved: 07/Oct/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Major
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File server.log     Text File server.log    
Issuezilla Id: 9,996

 Description   

Install v3 glassfish build 66, invoke asupgrade tool in cli mode.

I entered "yes" when tool prompts to rename. Tool should issue usage to use y
or n. Currently the tool throws error "There is an existing domain
directory: /usr/nga/v3/glassfishv3/glassfish/domains/domain1. Tool will"

#bin/asupgrade -c
Enter the source domain directory://usr/nga/v2.1/glassfish/domains/domain1
Enter the target domains root directory:/usr/nga/v2/gla^H^H^[[3~^[[3~
Target directory is invalid. Please enter a target path or type ctrl-c to exit.
Enter the target domains root
directory:/usr/nga/v3/glassfishv3/glassfish/domains
"domain1" already exists in the target directory. Would you like to rename it
(y/n)?yes
There is an existing domain
directory: /usr/nga/v3/glassfishv3/glassfish/domains/domain1. Tool will
Target directory is invalid. Please enter a target path or type ctrl-c to exit.
Enter the target domains root
directory:/usr/nga/v3/glassfishv3/glassfish/domains
"domain1" already exists in the target directory. Would you like to rename it
(y/n)?y
Moving /usr/nga/v3/glassfishv3/glassfish/domains/domain1
to /usr/nga/v3/glassfishv3/glassfish/domains
Enter the master password (leave blank for default):
Start copying of user lib files.
Copied dir: installer-builder
Copied file: Pack200Task.jar
Copied file: LICENSE.txt
Copied file: libcliutil64.so
Copied file: libloadmetrics.so
Finished copying of user lib files.
Executing command: /usr/nga/v3/glassfishv3/glassfish/bin/asadmin start-domain -
-upgrade --domaindir
Upgrade completed.



 Comments   
Comment by Bobby Bissett [ 05/Oct/09 ]

Not sure if this is a bug or feature request, but it's worth the time to get it fixed to avoid confusion. I
should get this one done soon.

Comment by 1xpert [ 05/Oct/09 ]

Created an attachment (id=3426)
v3 prelude 's server.log

Comment by 1xpert [ 05/Oct/09 ]

Created an attachment (id=3427)
v3 's server.log

Comment by Bobby Bissett [ 05/Oct/09 ]

Why do we need the server logs for these? It's just a change to the UI, right? Was there any problem with
the upgrade?

Comment by 1xpert [ 06/Oct/09 ]

The logs was for security issue 9855. Please ignore it..I was attached
unintentionally.

Comment by Bobby Bissett [ 07/Oct/09 ]

Fixed in revision 32390.





[GLASSFISH-9993] upgrade hangs when derby is shut down Created: 05/Oct/09  Updated: 06/Oct/09  Resolved: 06/Oct/09

Status: Closed
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Major
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File server.log    
Issuezilla Id: 9,993

 Description   

Using windows xp and upgrade tool in gui mode.

Upgrade tool should not hang when derby is shutdown. It should exit when it
detect a hang and inform user about it.

Steps to reproduce:
1) install v2.1, start derby databse, start domain
2) execute an application that uses derby database
3) stop domain, stop derby
4) install v3 build 66
5) start upgrade tool – notice it will hang. Domain's server.log will shows
exception about finding tables.



 Comments   
Comment by Bobby Bissett [ 05/Oct/09 ]

"execute an application that uses derby database"

Please provide one.

Note that if the server hangs, there isn't much the tool can do about it. But it would be good to isolate
such a bug and get it fixed in the server.

Comment by 1xpert [ 05/Oct/09 ]

Use bookstore application by checking out the source at:

1) set variables:
set CVSROOT to :pserver:<your java.net id>@cvs.dev.java.net:/cvs
set APS_HOME to point to <quicklooks workspace>/appserv-tests
set S1AS_HOME to point to appserver or glassfish server
set JAVA_HOME to point to 1.6.0_14
set ANT_HOME to point to 1.6.5
set PATH to point to $ANT_HOME/bin:$JAVA_HOME/bin:$PATH

2) cvs login
cvs co -r SJSAS91_FCS_BRANCH glassfish/appserv-tests

3) cd <workspace
directory>/appserv-tests/sqetests/web/bookstore

4) run command "ant clean build setup deploy-war run-war"

The tool hangs..Server doesn't hang.

Comment by 1xpert [ 05/Oct/09 ]

Created an attachment (id=3421)
v3 server.log

Comment by Bobby Bissett [ 05/Oct/09 ]

Can you explain what you mean by "tool hangs?" Is the GUI unresponsive?

You say that the server didn't hang, but from the server log you attached it looks like exactly that. It
ends with "felix.fileinstall.bundles.new.start" rather than "Shutdown procedure finished"

I cannot reproduce this. I've installed and run the book store application and then shut down everything
and performed the upgrade:

hostname% ps -ef | grep java
501 13763 170 0 0:00.00 ttys002 0:00.00 grep java

hostname% ./bin/asupgrade -s ~/servers/gfv2.1/glassfish/domains/domain1 -t
~/servers/glassfishv3/glassfish/domains

Neither the tool nor the server hung when I tried. Can you tell me when build 66 was? You could be
running into old bugs if it's not recent. If you want to give me a direct link to the build I can try it, but
even if I reproduce the bug there it appears to be fixed now.

Comment by Bobby Bissett [ 05/Oct/09 ]

Meant to add vella before. Adding to cc list in case there's more info on this one.

Comment by 1xpert [ 06/Oct/09 ]

Checked the build version and was using wrong build. Problem is fixed in b66.





[GLASSFISH-9992] process still remains after existing out of upgrade tool Created: 05/Oct/09  Updated: 05/Oct/09  Resolved: 05/Oct/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Major
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 9,992

 Description   

Using v2.1 glassfish installation on windows xp.

When upgrade tool hangs, I close the tool by clicking on the X on the top of
the GUI however the upgrade process still running. This process should be
killed when user exited the tool because it causes the tool to hang again when
the same derby database is running in v2.1 and v3 (no shutdown takes place in
v2.1)

Result of ps -ef shows process id 3600 is running:

Administ 2904 2192 0 10:00:01 con 0:00 "C:\WINDOWS\system32\cmd.exe"
Administ 3600 3040 0 11:01:36 con 0:00 cmd /c C:\nga\v3\glassfishv3
\glassfish\bin\asadmin.bat start-domain --upgrade --domaindir C:\nga\v3
\glassfishv3\glassfish\domains domain1
Administ 3436 3600 0 11:01:37 con 0:00 "c:\sun\sdk\jdk\bin\java" -
jar "C:\nga\v3\glassfishv3\glassfish\bin\..\modules\admin-cli.jar" start-
domain --upgrade --domaindir C:\nga\v3\glassfishv3\glassfish\domains domain1
Administ 3240 3436 0 11:01:38 con 0:04 C:\sun\SDK\jdk\bin\java.exe -cp
C:/nga/v3/glassfishv3/glassfish/modules/glassfish.jar -XX:MaxPermSize=192m -
XX:NewRatio=2 -Xmx512m -client -
javaagent:C:/nga/v3/glassfishv3/glassfish/lib/monitor/bt
race-agent.jar=unsafe=true -Dsun.rmi.dgc.client.gcInterval=3600000 -
Djdbc.drivers=org.apache.derby.jdbc.ClientDriver -
Djavax.net.ssl.keyStore=C:\nga\v3\glassfishv3
\glassfish\domains\domain1/config/keystore.jks -Djava.security.policy=C:\nga\
v3\glassfishv3\glassfish\domains\domain1/config/server.policy -Dsun.rmi.dgc

To reproduce a hang:
1) install v2.1, start derby database, start domain
2) run some test that uses derby database
3) stop v2.1, stop derby database
4) install v3 build 66
5) invoke upgrade tool in GUI mode
6) exit this tool by closing the X on top right of the tool
7) notice that the process is still there after exiting the tool..



 Comments   
Comment by Bobby Bissett [ 05/Oct/09 ]

I don't understand what starting the v2.1 db and server have to do with this issue. Your steps to
produce a hang don't include anything showing the hang. What doesn't work after you exit the tool?

When I click the close window button on the tool, it asks if I want to exit the wizard or not. Does that
happen for you? If so, and you exit, this sounds like a duplicate of 9366: closing the tool does not stop
the upgrade. They're separate processes. I don't intend to add functionality to exit the asadmin process
in this release as it's too late in the cycle for something that has so many unknowns.

Comment by 1xpert [ 05/Oct/09 ]

After exiting the tool, I notice that upgrade process was still running (see
result from ps -ef)

I have to manually killed the upgrade process. Upgrade tool should kill running
process that remains after user exited the tool. Why should you leave the
process running when user is not running the tool ?

I close the X to exit the tool, the tool prompts if i want to exit or not.

Comment by Bobby Bissett [ 05/Oct/09 ]

"Why should you leave the process running when user is not running the tool ?"

Because it's a separate process. By that logic, the server should stop running when asadmin exits. Why did
you exit the upgrade process after the tool ended? If the server is really hanging, that is a new (and high
priority) issue. But I can't reproduce it. What was in the server log? Was it still actively running when you
killed it or hanging?

As written, this is a duplicate of 9366. If we discover that the upgrade process (asadmin, not asupgrade) it
actually hanging, we should isolate that and file a separate issue.

      • This issue has been marked as a duplicate of 9366 ***
Comment by 1xpert [ 05/Oct/09 ]

Asupgrade brings up the tool and it uses asadmin start-domain --upgrade do the
actual work. These processes combined work together. If user canceled the tool,
the process "asadmin start-domain --upgrade" should also stop upgrading..I will
attach v3's server.log.

I had to kill the upgrade process because the upgrade tool was hanging for a
long time more than 4-5minutes.

Comment by Bobby Bissett [ 05/Oct/09 ]

Please go read 9366. This is a duplicate of it. Currently the tool is doing what I expect it to do.

If you think the server has a problem with a hang, run it manually with "asadmin start-domain --upgrade
etc" and file an issue about the server hanging.

      • This issue has been marked as a duplicate of 9366 ***




[GLASSFISH-9872] EN:The version is not correct in Upgrade Wizard window Created: 30/Sep/09  Updated: 16/Nov/09  Resolved: 16/Nov/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: v2.1.1
Fix Version/s: v2.1.1

Type: Bug Priority: Trivial
Reporter: xiangguoli Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: PNG File en-upgrade-heading-name-error.png    
Issuezilla Id: 9,872

 Description   

Description:
1. Install sges-2_1_1-solaris-sparc-ml.bin(build b31d-fcs)
2. Go to /opt/SUNWappserver/appserver/bin directory
3. Run 'asupgrade' to show Upgrade Wizard window
4. Observe the title of the Upgrade Wizard window

Acutal Result:
The version number is not consistent with the installed build
For details please refer to the snapshot



 Comments   
Comment by Bobby Bissett [ 02/Oct/09 ]

I don't see how this bug can be found in one version and fixed in another. Is this a v2.X bug that needs to
be fixed in 2.x or is this a v3 bug? If a v3 bug, please tell me which text is incorrect specifically.

Comment by xiangguoli [ 04/Oct/09 ]

Created an attachment (id=3403)
snapshot for issue 9872

Comment by Bobby Bissett [ 05/Oct/09 ]

Thanks for the update with the version information. I've changed the target milestone to 2.1.1 and will try
to see who handles that.

Comment by Bobby Bissett [ 07/Oct/09 ]

Am lowering the priority since this doesn't affect functionality. Still need to find the person who owns
previous versions of the tool.

Comment by Bobby Bissett [ 11/Nov/09 ]

This was fixed by sustaining engineering and will be in 2.1.1 patch 1.

Comment by Bobby Bissett [ 16/Nov/09 ]
      • Issue 9869 has been marked as a duplicate of this issue. ***
Comment by Bobby Bissett [ 16/Nov/09 ]
      • Issue 9870 has been marked as a duplicate of this issue. ***




[GLASSFISH-9870] EN:Wrong version number in Upgrade Wizard window Created: 30/Sep/09  Updated: 16/Nov/09  Resolved: 16/Nov/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: v2.1.1
Fix Version/s: V3

Type: Bug Priority: Minor
Reporter: xiangguoli Assignee: Bobby Bissett
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 9,870

 Description   

Description:
1. Install sges-2_1_1-solaris-sparc-ml.bin(build b31d-fcs)
2. Go to /opt/SUNWappserver/appserver/bin directory
3. Run 'asupgrade' to show Upgrade Wizard window
4. Observe the title of the Upgrade Wizard window

Acutal Result:
The version number is not consistent with the installed build
For details please refer to the snapshot



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 13/Nov/09 ]

Moving to correct subcategory.

Comment by Bobby Bissett [ 16/Nov/09 ]

I know it's odd to mark as a duplicate of a later issue, but this one was just now reassigned to me and the
full information is in issue 9872.

      • This issue has been marked as a duplicate of 9872 ***




[GLASSFISH-9869] EN:Wrong version number in Upgrade Wizard window Created: 30/Sep/09  Updated: 16/Nov/09  Resolved: 16/Nov/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: v2.1.1
Fix Version/s: V3

Type: Bug Priority: Minor
Reporter: xiangguoli Assignee: Bobby Bissett
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 9,869

 Description   

Description:
1. Install sges-2_1_1-solaris-sparc-ml.bin(build b31d-fcs)
2. Go to /opt/SUNWappserver/appserver/bin directory
3. Run 'asupgrade' to show Upgrade Wizard window
4. Observe the title of the Upgrade Wizard window

Acutal Result:
The version number is not consistent with the installed build
For details please refer to the snapshot



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 13/Nov/09 ]

Moving to correct subcategory.

Comment by Bobby Bissett [ 16/Nov/09 ]

I know it's odd to mark as a duplicate of a later issue, but this one was just now reassigned to me and the
full information is in issue 9872.

      • This issue has been marked as a duplicate of 9872 ***




[GLASSFISH-9855] security-constraint not enforced correctly Created: 29/Sep/09  Updated: 06/Oct/09  Resolved: 06/Oct/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Critical
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File hellojspsecure.war     Text File server.log     XML File web.xml     Text File web.xml.diff    
Issuezilla Id: 9,855

 Description   

Sidebyside upgrade from v3 prelude to v3 nightly build 9/29/09 on winxp using
securiy test from v3 prelude quicklooks test

After upgrade, got Error on security-constraint

runtest-impl-class:
[echo] =============Starting TestNG test at ../..//classes/test
============
[testng] [Parser] Running:
[testng] security

[testng] URL is: http://localhost:8080/hellojspsecure/first.html
[testng] Connecting to: http://localhost:8080/hellojspsecure/first.html
[testng] ERROR: Anonymous Client access was Allowed, security-constraint not
Enforced correctly
[testng] URL is: http://localhost:8080/hellojspsecure/simpleservlet
[testng] Connecting to: http://localhost:8080/hellojspsecure/simpleservlet
[testng] ERROR: Anonymous Client access was Allowed, security-constraint not
Enforced correctly
[testng] URL is: http://localhost:8080/hellojspsecure/hello.jsp
[testng] Connecting to: http://localhost:8080/hellojspsecure/hello.jsp
[testng] ERROR: Anonymous Client access was Allowed, security-constraint not
Enforced correctly

[testng] ===============================================
[testng] security
[testng] Total tests run: 3, Failures: 3, Skips: 0
[testng] ===============================================

Steps to reproduce:
1) install v3 prelude, start domain1, start derby
2) checkout v3 prelude quicklook test as followed:

need to have subversion svn-win32-1.5.4.zip
need to set environment variables JAVA_HOME, ANT_HOME, S1AS_HOME (glassfish
location), PATH to point to ANT_HOME\bin, JAVA_HOME\bin,SVN_HOME\bin

svn co https://svn.dev.java.net/svn/glassfish-svn/tags/glassfish-3.0-Prelude-
b28c/tests
cd <workspace>\tests\quicklook\security\helloworld
ant -Dglassfish.home=%S1AS_HOME% build deploy runtest

3) stop domain, stop derby

4) install v3 build 9/29/09 from location below:
http://javaweb.sfbay.sun.com/java/re/glassfish/v3/nightly/bundles/

latest-glassfish.zip 29-Sep-2009 03:03 73M

5) start asupgrade from <v3 installation>/bin

6) cd <workspace>\tests\quicklook\security\helloworld
run "ant -Dglassfish.home=<v3 installation> runtest"



 Comments   
Comment by 1xpert [ 29/Sep/09 ]

Created an attachment (id=3358)
log

Comment by 1xpert [ 02/Oct/09 ]

Raising priority to P2

Comment by Bobby Bissett [ 02/Oct/09 ]

From the log, it may be that the security code isn't handling backwards compatibility or that the
application isn't actually compliant. Will look at this one next.

Comment by Bobby Bissett [ 02/Oct/09 ]

Cannot run:

hostname% pwd
/Users/bobby/work/ws/v3quicklook_tests/tests/quicklook/security/helloworld
hostname% ant -emacs -Dglassfish.home=$S1AS_HOME build deploy runtest
Buildfile: build.xml

BUILD FAILED
/Users/bobby/work/ws/v3quicklook_tests/tests/quicklook/security/helloworld/build.xml:44: The
following error occurred while executing this line:
/Users/bobby/work/ws/v3quicklook_tests/tests/quicklook/gfproject/build-impl.xml:86: taskdef class
org.testng.TestNGAntTask cannot be found

Total time: 0 seconds

Will look through build files to see where it expects to find testng, but if you can tell me first that
would be a time saver.

My environment is as you described (except that I already have a svn client and don't need the windows
build you mention).

Comment by Bobby Bissett [ 02/Oct/09 ]

I see there's a top level pom.xml file that needs to be run to install the dependencies before any individual
tests can be run. This would be good information to include with any issue reports that use the v3 prelude
quicklook tests.

Comment by Bobby Bissett [ 03/Oct/09 ]

Have now built, deployed, tested, and performed the upgrade. When I start the v3 server, I see the
following error in the server log:

[#|2009-10-03T20:24:14.485-
0400|SEVERE|glassfish|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_T
hreadID=11;_ThreadName=Thread-3;|DPL8015: Invalid Deployment Descriptors in Deployment
descriptor file WEB-INF/web.xml in archive [hellojspsecure].
Line 72 Column 31 – The content of element type "security-constraint" must match "(web-resource-
collection+,auth-constraint?,user-data-constraint?)".|#]

So there is either a bug in the test case (that wasn't caught in prelude) or there has been an
incompatible change in v3.

Please check the server log, not just during an upgrade, but also when starting up the v3 server. The
bug here isn't that the security-constraint isn't enforced, but that there is a problem that the
application can't be properly deployed in the v3 server.

I'll check the validity of the deployment descriptor and if there's any issue during upgrade that is
changing it.

Comment by Bobby Bissett [ 03/Oct/09 ]

Created an attachment (id=3401)
War file created by the quicklook/security/helloworld test

Comment by Bobby Bissett [ 03/Oct/09 ]

Created an attachment (id=3402)
Web.xml file used in quicklook/security/helloworld war file

Comment by Bobby Bissett [ 03/Oct/09 ]

I see the same error when deploying to a v2.1 server, so this is a bug in the test that wasn't caught in v3
prelude. The error in web.xml is described in the attached server.log file. It may simply be that the
description element should be removed and the rest will work. It's understandable that v3 prelude
wouldn't catch such a detail.

I'd normally resolve this issue as "invalid," but the test case should be fixed and I'd like to make sure it
works with v3 once the test case is fixed. Am reassigning to sqe to have the test case fixed.

Comment by Bobby Bissett [ 03/Oct/09 ]

Adding Vella to cc list to keep him up to date.

Comment by Bobby Bissett [ 05/Oct/09 ]

It looks like this file was generated in NetBeans and the the bulk of the xml copied into an old web.xml
file. The current DTD in this file is old and the xml file fail validation even without building and
deploying the app. From the NetBeans xml validation tool:

XML validation started.
Checking
file:/Users/bobby/work/ws/v3quicklook_tests/tests/quicklook/security/helloworld/metadata/web.xml.
..
The content of element type "security-constraint" must match "(web-resource-collection+,auth-
constraint?,user-data-constraint?)". [72]
XML validation finished.

Assuming you want to use a servlet 2.5 app, I've replaced the old dtd with the correct schema and the
test passes in prelude, the upgrade test works with v3, and the app can be deployed to gfv2.1. I will
attach the diff.

Comment by Bobby Bissett [ 05/Oct/09 ]

Created an attachment (id=3414)
Web.xml diff that fixes the test application.

Comment by 1xpert [ 05/Oct/09 ]

This is not a bug in the test because tests run fine in V3 Prelude, but could
not run successfully in V3..I notice that you ran this test on v2.1 and saw the
same problem invalid descriptor in web.xml that also appeared in v3..I ran the
test on V3 Prelude.

I tried to use the web.xml.diff and executed the test, however I got some error
during deployment in v3 that version needs to be added to web-app element. I
have added but it still complained.

Thus, I started fresh , went through the steps to reproduce this issue. I
noticed that there is no error in v3 prelude 's server.log. I only see problem
exception in v3. I will attach both server.log, v3 prelude's domain1

Comment by 1xpert [ 05/Oct/09 ]

Reassign issue to Upgrade

Comment by Bobby Bissett [ 05/Oct/09 ]

You're obviously not reading what I'm writing. I'm aware that the test passes in prelude – this is because
prelude isn't validating the xml against the DTD. The web.xml file is simply not valid whether prelude
catches it or not. Please check it for yourself in NetBeans (or some other validation tool) if you don't
believe me.

I tried to be helpful about this and fix the test case rather than marking it invalid, but that led nowhere.
Am marking as invalid – if you want, you can file a bug against sqe tests to get this fixed.

Comment by 1xpert [ 06/Oct/09 ]

I make changes to web.xml using web.xml.diff attachment, deploying it to v3
prelude, upgrade and check in against v3 server. It gives error that version
needs to be used for <web-app>. This error is bogus because version is already
present in <web-app>

The problem was I did not remove the line starting with DTD...I guess it's more
helpful to post the web.xml itself rather than diff because it's easy to make
human errors when editing manually

I tried the upgrade from v3 prelude to v3 and it works like a charm...Thanks for
the fix.





[GLASSFISH-9852] SQLSystaxErrorException: Table/View does not exist Created: 29/Sep/09  Updated: 02/Oct/09  Resolved: 02/Oct/09

Status: Closed
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Major
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File server.log     Text File server.log    
Issuezilla Id: 9,852

 Description   

Sidebyside upgrade from v3 prelude to v3 nightly build 9/29/09 on winxp using
JPA test

Could access url http://localhost:8080/jpainjectemf/jpa?testcase=llinit

Steps to reproduce:
1) install v3 prelude, start domain1, start derby
2) checkout v3 prelude quicklook test as followed:

need to have subversion svn-win32-1.5.4.zip
need to set environment variables JAVA_HOME, ANT_HOME, S1AS_HOME (glassfish
location), PATH to point to ANT_HOME\bin, JAVA_HOME\bin,SVN_HOME\bin

svn co https://svn.dev.java.net/svn/glassfish-svn/tags/glassfish-3.0-Prelude-
b28c/tests
cd <workspace>\tests\quicklook\persistence\jpainjectemf
ant -Dglassfish.home=%S1AS_HOME% build deploy runtest
open ij in <v3 installation>/javadb/bin
at the prompt ij> , enter command
connect 'jdbc:derby://localhost:1527/sun-appserv-
samples;create=true;user=app;password=app';
at the prompt ij>, enter command
delete from Department;
delete from Employee;

3) stop domain, stop derby

4) install v3 build 9/29/09 from location below:
http://javaweb.sfbay.sun.com/java/re/glassfish/v3/nightly/bundles/

latest-glassfish.zip 29-Sep-2009 03:03 73M

5) start asupgrade from <v3 installation>/bin

6) cd <workspace>\tests\quicklook\persistence\jspinjectemf

run "ant -Dglassfish.home=<v3 installation> runtest"



 Comments   
Comment by 1xpert [ 29/Sep/09 ]

Created an attachment (id=3356)
server.log

Comment by 1xpert [ 29/Sep/09 ]

Created an attachment (id=3357)
server.log

Comment by Bobby Bissett [ 01/Oct/09 ]

From these instructions, you never restarted the database (or the v3 app server), so the tables won't be
found by the application. Can you confirm these steps and make sure the database is running – the same
one that was running when you deployed the apps into the original server?

Comment by 1xpert [ 02/Oct/09 ]

Closed. duplicate of issue 9851.
Same issue was entered in the system twice due to recent outage problem.

Comment by Bobby Bissett [ 02/Oct/09 ]

Marking resolved per Nga's comment.

      • This issue has been marked as a duplicate of 9851 ***
Comment by Bobby Bissett [ 02/Oct/09 ]

Closing since this one wasn't meant to be filed. Per Nga's request.





[GLASSFISH-9851] SQLSystaxErrorException: Table/View does not exist Created: 29/Sep/09  Updated: 05/Oct/09  Resolved: 05/Oct/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Major
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 9,851

 Description   

Sidebyside upgrade from v3 prelude to v3 nightly build 9/29/09 on winxp using
JPA test

Steps to reproduce:
1) install v3 prelude, start domain1, start derby
2) checkout v3 prelude quicklook test as followed:

need to have subversion svn-win32-1.5.4.zip
need to set environment variables JAVA_HOME, ANT_HOME, S1AS_HOME (glassfish
location), PATH to point to ANT_HOME\bin, JAVA_HOME\bin,SVN_HOME\bin

svn co https://svn.dev.java.net/svn/glassfish-svn/tags/glassfish-3.0-Prelude-
b28c/tests
cd <workspace>\tests\quicklook\persistence\jpainjectemf
ant -Dglassfish.home=%S1AS_HOME% build deploy runtest
open ij in <v3 installation>/javadb/bin
at the prompt ij> , enter command
connect 'jdbc:derby://localhost:1527/sun-appserv-
samples;create=true;user=app;password=app';
at the prompt ij>, enter command
delete from Department;
delete from Employee;

3) stop domain, stop derby

4) install v3 build 9/29/09 from location below:
http://javaweb.sfbay.sun.com/java/re/glassfish/v3/nightly/bundles/

latest-glassfish.zip 29-Sep-2009 03:03 73M

5) start asupgrade from <v3 installation>/bin

6) cd <workspace>\tests\quicklook\persistence\jspinjectemf

run "ant -Dglassfish.home=<v3 installation> runtest"



 Comments   
Comment by Bobby Bissett [ 01/Oct/09 ]

From these instructions, you never restarted the database (or the v3 app server), so the tables won't be
found by the application. Can you confirm these steps and make sure the database is running – the same
one that was running when you deployed the apps into the original server?

Comment by Bobby Bissett [ 02/Oct/09 ]
      • Issue 9852 has been marked as a duplicate of this issue. ***
Comment by Bobby Bissett [ 05/Oct/09 ]

These steps are unusual – it would be good to include the explanation that the data in the tables
must be manually dropped before repeating the test. Note that I can't delete the Department data
before Employee. Instead I have to use: "delete from Employee; delete from Department;"

As long as I leave the database running, I can perform the upgrade and run the test successfully
against server. I think the issue you're seeing is because you shut down the database that had the
tables in it.

— begin —
hostname% ant -emacs -Dglassfish.home=/Users/bobby/servers/glassfishv3/glassfish runtest
Buildfile: build.xml

runtest:

runtest-impl:

compile-tests:
compiling test client to ../..//classes/test
Compiling 1 source file to /Users/bobby/work/ws/v3quicklook_tests/tests/quicklook/classes/test
Note:
/Users/bobby/work/ws/v3quicklook_tests/tests/quicklook/persistence/jpainjectemf/src/test/JpaInject
EMFTestNG.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

checkTestNGXML:

runtest-impl-class:
=============Starting TestNG test at ../..//classes/test ============
[Parser] Running:
jpainjectemf

url=http://localhost:8080/jpainjectemf/jpa?testcase=llinit
url=http://localhost:8080/jpainjectemf/jpa?testcase=llquery

===============================================
jpainjectemf
Total tests run: 2, Failures: 0, Skips: 0
===============================================

checkTestNGXML:

runtest-impl-xml:

BUILD SUCCESSFUL
Total time: 7 seconds
— out —





[GLASSFISH-9846] Content of help page needs to be updated Created: 29/Sep/09  Updated: 02/Oct/09  Resolved: 02/Oct/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Major
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 9,846

 Description   

Install glassfish v3 nightly build 9/28/09 on Windows XP
Invoke asupgrade tool
Click on "Help" button
From Table of Contents, choose "Upgrade Tool Overview". See content on the
right page..Content needs to be updated to reflect current upgrade support



 Comments   
Comment by Bobby Bissett [ 02/Oct/09 ]

Tried to update this issue yesterday but it didn't go through I guess.

      • This issue has been marked as a duplicate of 9429 ***




[GLASSFISH-9699] [Blocking] got exception Unsupported endpoint address: REPLACE_WITH_ACTUAL_URL Created: 23/Sep/09  Updated: 03/Oct/09  Resolved: 03/Oct/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Critical
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Attachments: Text File server.log    
Issuezilla Id: 9,699

 Description   

Sidebyside upgrade from glassfish v2.1 to glassfish v3 on linux5.0 using CLI
mode. Deploy jbi application in V2 Quicklooks tests

After upgrade, I ran the application and got the following error from the
console. See attached server.log (please ignore the NPE exception seen in log
belongs to another application)

Error seen at console:

  1. ant run
    Buildfile: build.xml

run:

setOSConditions:

setToolWin:

setToolUnix:

setToolProperty:

setS1ASclassPath:

init-common:

run-local-client:
[java] Host [localhost] port (8080)
[java] Calling Servlet /callMessagesEJB/TestServlet?test=testPing
[java] HTTP/1.1 200 OK
[java] X-Powered-By: Servlet/3.0
[java] Server: GlassFish/v3
[java] Content-Type: text/html;charset=UTF-8
[java] Content-Length: 3167
[java] Date: Wed, 23 Sep 2009 16:15:47 GMT
[java] Connection: close

[java] Calling test : testPing
[java] testPing:FAIL
[java] Value of key is:jbi.helloca.messages.testPing
[java] javax.xml.ws.WebServiceException: Unsupported endpoint address:
REPLACE_WITH_ACTUAL_URL
[java] at
com.sun.xml.ws.api.pipe.TransportTubeFactory.create(TransportTubeFactory.java:144)
[java] at
com.sun.xml.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:129)
[java] at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:629)
[java] at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:588)
[java] at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:573)
[java] at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:470)
[java] at com.sun.xml.ws.client.Stub.process(Stub.java:319)
[java] at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:157)
[java] at
com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:109)
[java] at
com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
[java] at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140)
[java] at $Proxy167.ping(Unknown Source)
[java] at outbound.servlet.TestServlet.testPing(TestServlet.java:54)
[java] at outbound.servlet.TestServlet.processRequest(TestServlet.java:40)
[java] at outbound.servlet.TestServlet.doGet(TestServlet.java:128)
[java] at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
[java] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
[java] at
org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1522)
[java] at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:292)
[java] at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
[java] at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
[java] at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
[java] at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
[java] at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
[java] at
org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:332)
[java] at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:233)
[java] at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:209)
[java] at
com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:753)
[java] at
com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:661)
[java] at
com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:914)
[java] at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:166)
[java] at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
[java] at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
[java] at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
[java] at
com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
[java] at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
[java] at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
[java] at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
[java] at
com.sun.grizzly.util.FixedThreadPool$BasicWorker.dowork(FixedThreadPool.java:379)
[java] at
com.sun.grizzly.util.FixedThreadPool$BasicWorker.run(FixedThreadPool.java:360)
[java] at java.lang.Thread.run(Thread.java:619)

Steps to produce:
1) install glassfish v2.1
2) asadmin start-domain, asadmin start-database
3) check out V2 Quicklooks workspace, choose test case reside under <workspace
directory>/sqetests/jbi/helloca/scripts/messages

set environment variables APS_HOME pointing to v2 workspace, ANT_HOME,
JAVA_HOME. S1AS_HOME, PATH to $ANT_HOME/bin:$JAVA_HOME/bin:$PATH

4) execute "ant setup"

5) asadmin stop-domain
asadmin stop-database

6) install v3 nightly build 9/22/09

7) run <v3 install>/bin/asupgrade -c

8) asadmin start-domain
asadmin start-database

9) cd appserv-tests/sqetests/jbi/helloca/scripts/messages
type "ant run"



 Comments   
Comment by 1xpert [ 23/Sep/09 ]

Created an attachment (id=3281)
log

Comment by 1xpert [ 24/Sep/09 ]

More details on Step 3 of this issue.

Easy way to checkout V2 quicklooks test:

1) set variables:
set CVSROOT to :pserver:<your java.net id>@cvs.dev.java.net:/cvs
set APS_HOME to point to <quicklooks workspace>/appserv-tests
set S1AS_HOME to point to appserver or glassfish server
set JAVA_HOME to point to 1.6.0_14
set ANT_HOME to point to 1.6.5
set PATH to point to $ANT_HOME/bin:$JAVA_HOME/bin:$PATH

2) cvs login
cvs co -r SJSAS91_FCS_BRANCH glassfish/appserv-tests

3) cd <workspace
directory>/sqetests/jbi/helloca/scripts/messages

Comment by 1xpert [ 28/Sep/09 ]

Per Abhijit and Alex's requests, I add keyword Blocking for tracking purpose

Comment by Hong Zhang [ 01/Oct/09 ]

The JBI is not enabled out of box in v3, we are currently talking with JBI team
to figure out how to support the upgrade scenario for JBI applications in v3.

Comment by Hong Zhang [ 01/Oct/09 ]

add mohit (from jbi team) and myself to cc

Comment by Bobby Bissett [ 02/Oct/09 ]

Adding Vella to cc list as well. Am adding this information here and will check with the powers that be.

From part of a separate email conversation about how to handle this, I wrote:
"My suggestion: document that JBI isn't supported out of the box, mark 9699 as a feature request, and
make sure that upgrade still works even if one application fails to deploy. Does anyone see a serious issue
with that?"

It was pointed out that even if we can't make this a part of an automated upgrade, we should figure out
the manual steps to do so.

Comment by Bobby Bissett [ 03/Oct/09 ]

Have heard back that we can forget this one for v3. Right now we should not do any testing that involved
JBI. Please just make sure there are other web service tests so that the endpoint address issue isn't general
and not part of JBI support.





[GLASSFISH-9698] [Blocking] got HTTP Status 500 NPE while running bookstore application Created: 23/Sep/09  Updated: 30/Sep/09  Resolved: 30/Sep/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Critical
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Attachments: Text File bookstore_server.log     Java Archive File domain1_startdatabase.jar     Text File server.log     Text File server.log_startdatabase.log    
Issuezilla Id: 9,698

 Description   

Sidebyside upgrade from glassfish v2.1 to glassfish v3 on linux5.0 using CLI mode

After upgrade, I ran bookstore application and got NullPointerException when
accessing URL /bookstore3/bookcatalog?Add=205. Other urls work fine. See
attachment for server.log

1) install glassfish v2.1
2) asadmin start-domain, asadmin start-database
3) check out V2 Quicklooks workspace, choose test case reside under <workspace
directory>/appserv-tests/sqetests/web/bookstore
set environment variables APS_HOME pointing to v2 workspace, ANT_HOME,
JAVA_HOME. S1AS_HOME, PATH to $ANT_HOME/bin:$JAVA_HOME/bin:$PATH

4) run command "ant build setup deploy-war run-war"
test pass

5) install glassfish v3 in another directory

6) run "asupgrade -c" under <v3>/bin

7) asadmin start-domain, asadmin start-database

8) run "ant run-war"

Test Result:

Buildfile: build.xml

setOSConditions:

setToolWin:

setToolUnix:

setToolProperty:

setS1ASclassPath:

init-common:

run-war:

setOSConditions:

setToolWin:

setToolUnix:

setToolProperty:

setS1ASclassPath:

init-common:

runwebclient-common:
[java] size of buffer is4001
[java] HTTP port :8080
[java] HTTP hostname :localhost
[java] addTest with testSuiteId:: testId -> jstl-servlet (stand-alone war
based)::/bookstore3/bookcatalog?Add=
[java] jstl-servlet (stand-alone war based)
/bookstore3/bookcatalog?Add= PASS
[java] HTTP port :8080
[java] HTTP hostname :localhost
[java] addTest with testSuiteId:: testId -> jstl-servlet (stand-alone war
based)::/bookstore3/template/duke.books.gif
[java] jstl-servlet (stand-alone war based)
/bookstore3/template/duke.books.gif PASS
[java] HTTP port :8080
[java] HTTP hostname :localhost
[java] addTest with testSuiteId:: testId -> jstl-servlet (stand-alone war
based)::/bookstore3/bookdetails?bookId=205
[java] jstl-servlet (stand-alone war based)
/bookstore3/bookdetails?bookId=205 PASS
[java] HTTP port :8080
[java] HTTP hostname :localhost
[java] addTest with testSuiteId:: testId -> jstl-servlet (stand-alone war
based)::/bookstore3/bookcatalog?Add=205
[java] !!Server returned error..Application Exiting
[java] jstl-servlet (stand-alone war based)
/bookstore3/bookcatalog?Add=205 FAIL
[java] in flushAll , creating new testSuiteHash
[java] in flushAll , creating new testSuiteHash

BUILD SUCCESSFUL



 Comments   
Comment by 1xpert [ 23/Sep/09 ]

Created an attachment (id=3280)
log

Comment by 1xpert [ 24/Sep/09 ]

More details on Step 3 of this issue.

Easy way to checkout V2 quicklooks test:

1) set variables:
set CVSROOT to :pserver:<your java.net id>@cvs.dev.java.net:/cvs
set APS_HOME to point to <quicklooks workspace>/appserv-tests
set S1AS_HOME to point to appserver or glassfish server
set JAVA_HOME to point to 1.6.0_14
set ANT_HOME to point to 1.6.5
set PATH to point to $ANT_HOME/bin:$JAVA_HOME/bin:$PATH

2) cvs login
cvs co -r SJSAS91_FCS_BRANCH glassfish/appserv-tests

3) cd <workspace
directory>/appserv-tests/sqetests/web/bookstore

Comment by 1xpert [ 28/Sep/09 ]

Per Abhijit and Alex's requests, I add keyword Blocking for tracking purpose

Comment by Hong Zhang [ 28/Sep/09 ]

From the server.log, it seems the redeployment of the application is successful.
But somehow the application failed to run.

Can you try to deploy the same application directly to a v3 domain, and see if
it works that way? If it still fails to run, we could ask people from web
container to take a look.

And in general, if you find some application fail to upgrade, one of the first
steps to look at the problem is to try deploying the same application directly
to v3 domain to see if it works. So we know if the problem is specific to upgrade.

Comment by 1xpert [ 28/Sep/09 ]

Hong
The application might need repackaging to run successfully on v3. Thus this same
application might not work on v2. Is there another way to turn on the log level
during upgrade to pinpoint the issue ?

Comment by Hong Zhang [ 28/Sep/09 ]

Nga: Have you tried to deploy the application directly to a v3 installation? If
yes, what kind of error message did you get in the server.log?
You mentioned the repackaging might be needed, what kind of repackging
would be needed?

Comment by 1xpert [ 28/Sep/09 ]

deploying the app to v3 works however app run doesn't work for two urls. See
bookstore_server.log in attachment for details. The last portion of the logs
belongs to bookstore application.

1) Got error below when accessing url with context root :
http://easqelx14.red.iplanet.com:8080/bookstore3/bookdetails?bookId=205

Your request cannot be completed. The server got the following error:

javax.servlet.jsp.JspTagException: javax.el.ELException:
exception.BookNotFoundException: Couldn't find book: 205 : javax.el.ELException:
exception.BookNotFoundException: Couldn't find book: 205

2)http://easqelx14.red.iplanet.com:8080/bookstore3/bookcatalog?Add=205

Comment by 1xpert [ 28/Sep/09 ]

Created an attachment (id=3333)
log for bookstore app deployed to v3 without upgrade

Comment by Hong Zhang [ 28/Sep/09 ]

Just to clarify: so when you tried to run the application after deploying the
application to v3 directly, you got the same error message as when you tried to
run the application after this application is upgraded from a v2 domain?

Comment by Hong Zhang [ 28/Sep/09 ]

Looking at the server.log, I just noticed this

java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild:
start: org.apache.catalina.LifecycleException: java.lang.NoClassDefFoundError:
com/sun/enterprise/InjectionExceptionjava.lang.IllegalStateException:
ContainerBase.addChild: start: org.apache.catalina.LifecycleException:
java.lang.NoClassDefFoundError: com/sun/enterprise/InjectionException

Can you attach or give a link to the application source code, did the
application actually explicitly reference the InjectionException? The
InjectionException class has been moved to another package in v3.

Comment by Hong Zhang [ 28/Sep/09 ]

Also when you attach server.log for deployment directly to a v3 domain, can you
start from a fresh installation or at least start with a clean server.log, it's
very hard to tell which part of the log is from what..

Comment by 1xpert [ 29/Sep/09 ]

Hong,

Please check out the test case and run it in v3. I have lots to do in regard to
testing..

1) set variables:
set CVSROOT to :pserver:<your java.net id>@cvs.dev.java.net:/cvs
set APS_HOME to point to <quicklooks workspace>/appserv-tests
set S1AS_HOME to point to appserver or glassfish server
set JAVA_HOME to point to 1.6.0_14
set ANT_HOME to point to 1.6.5
set PATH to point to $ANT_HOME/bin:$JAVA_HOME/bin:$PATH

2) cvs login
cvs co -r SJSAS91_FCS_BRANCH glassfish/appserv-tests

3) cd <workspace
directory>/appserv-tests/sqetests/web/bookstore

Comment by 1xpert [ 29/Sep/09 ]

Hong,

Please check out the test case and run it in v3. I have lots to do in regard to
testing..

1) set variables:
set CVSROOT to :pserver:<your java.net id>@cvs.dev.java.net:/cvs
set APS_HOME to point to <quicklooks workspace>/appserv-tests
set S1AS_HOME to point to appserver or glassfish server
set JAVA_HOME to point to 1.6.0_14
set ANT_HOME to point to 1.6.5
set PATH to point to $ANT_HOME/bin:$JAVA_HOME/bin:$PATH

2) cvs login
cvs co -r SJSAS91_FCS_BRANCH glassfish/appserv-tests

3) cd <workspace
directory>/appserv-tests/sqetests/web/bookstore

Comment by Hong Zhang [ 30/Sep/09 ]

I have tried this and it worked for me, all tests passed when I ran them after
the upgrade.

Note, some tests failed for you probably due to the fact you were using a
different database after upgrade, so all the previous data got lost when you
switched database.

When I tried, I did not shutdown the database associated with v2 installation
which I started in step 2), and did not start another database which is
associated with v3 installation in step 7). I just used the same database instance.

Comment by 1xpert [ 30/Sep/09 ]

Created an attachment (id=3362)
server.log when using command start-database

Comment by 1xpert [ 30/Sep/09 ]

Created an attachment (id=3363)
domain1.jar using start-database command





[GLASSFISH-9683] tool should prompt for source lib dir when not found Created: 23/Sep/09  Updated: 17/Sep/10  Resolved: 17/Sep/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: 3.1

Type: Improvement Priority: Minor
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 9,683
Status Whiteboard:

v3_exclude


 Description   

When the source domain is not in gf/domains directory, upgrade tool should prompt the user for it. Since
this is a UI change, it will wait for 3.1.



 Comments   
Comment by Bobby Bissett [ 02/Oct/09 ]

I don't want to leave this in unconfirmed state...

Comment by Bobby Bissett [ 10/Nov/09 ]

Setting target milestone to 3.1.

Comment by Bobby Bissett [ 10/Nov/09 ]

This is just a help for copying 3rd party jars from v2.X lib directory to the v3 server. It's not required for
the v3 upgrade, but would be nice to have.

Comment by Bobby Bissett [ 17/Sep/10 ]

This is a minor improvement, and the case it covers is already documented. Am
closing the RFE and we can create a new one for 3.2 or later if there is any
interest.





[GLASSFISH-9665] improve error handling for application which fails upgrade Created: 22/Sep/09  Updated: 31/Oct/09  Resolved: 31/Oct/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Major
Reporter: 1xpert Assignee: Tim Quinn
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Attachments: Java Archive File domains.jar     Text File ejb-stateless-converterApp.ear     Text File server.log     Text File server.log    
Issuezilla Id: 9,665

 Description   

After upgrade to v3, could not get client stubs to run application.

Os= linux5.0
upgradetype = sidebyside
mode=cli

Steps to reproduce:

1) install 9.1_01 from /net/koori/onestop/glassfish/9.1_01/promoted/fcs/b09d/bundles
2) check out quicklooks test using instruction at
http://glassfish.dev.java.net/public/GuidelinesandConventions.html#Quicklook_Tests
3)cd workspace/v2/glassfish/appserv-tests/sqetests/ejb/stateless/converter
4) edit build.xml to skip undeploy and unsetup
5) start-domain, start derby
6) execute ant all
7) stop domain, stop derby
8) install latest-glassfish.zip dated 9/22/09 nightly build
9) get client stubs

Output from console:
/usr/nga/v3/retest/glassfishv3/glassfish/bin/asadmin get-client-stubs --user
admin --appname ejb-stateless-converterApp .
Deprecated syntax, instead use:
asadmin --user admin get-client-stubs [options] ...
com.sun.enterprise.admin.cli.CommandException: remote failure: Error while
downloading generated files
/usr/nga/v3/retest/glassfishv3/glassfish/domains/domain1/generated/xml/ejb-stateless-converterApp/ejb-stateless-converter-client_jar/ejb-stateless-converter-clientClient.jar
(No such file or directory)

Command get-client-stubs failed.

Error in server.log:
[#|2009-09-22T09:18:08.542-0700|SEVERE|glassfish|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=31;_ThreadName=Thread-3;|Error
while downloading generated files
java.io.FileNotFoundException:
/usr/nga/v3/retest/glassfishv3/glassfish/domains/domain1/generated/xml/ejb-stateless-converterApp/ejb-stateless-converter-client_jar/ejb-stateless-converter-clientClient.jar
(No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at
org.glassfish.admin.payload.PayloadImpl$Outbound.attachFile(PayloadImpl.java:117)
at
org.glassfish.deployment.admin.DeployCommand.retrieveArtifacts(DeployCommand.java:431)
at
org.glassfish.deployment.admin.DeployCommand.retrieveArtifacts(DeployCommand.java:414)
at
org.glassfish.appclient.server.core.GetClientStubsCommand.execute(GetClientStubsCommand.java:106)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$4.execute(CommandRunnerImpl.java:403)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:418)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:505)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:138)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:355)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:195)
at
com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
at
com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
@ at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:215)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:753)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:661)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:914)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:166)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
com.sun.grizzly.util.FixedThreadPool$BasicWorker.dowork(FixedThreadPool.java:379)
at
com.sun.grizzly.util.FixedThreadPool$BasicWorker.run(FixedThreadPool.java:360)
at java.lang.Thread.run(Thread.java:619)

#]


 Comments   
Comment by 1xpert [ 22/Sep/09 ]

Created an attachment (id=3265)
converter application

Comment by 1xpert [ 22/Sep/09 ]

Use attached EAR to avoid checking out workspace..Haven't tried deploying alone
however i checked and do not need to setup resource.

Comment by Bobby Bissett [ 22/Sep/09 ]

Please deploy the application you've attached into v2 and make sure it works there. Then attach the
working v2 domain to the issue so I can reproduce it. You can't try the upgrade without having the
working domain, so it would be a lot faster to attach it.

Comment by 1xpert [ 22/Sep/09 ]

Attached is the domain using application from quicklooks workspace.

I will try the ear and attach it later.

Comment by 1xpert [ 22/Sep/09 ]

Created an attachment (id=3268)
domains directory using ear assembled in quicklooks test

Comment by 1xpert [ 22/Sep/09 ]

I tried the ear attachment and it works fine. Please go ahead and use it on your
testing.

  1. bin/asadmin deploy ./ejb-stateless-converterApp.ear
    Command deploy executed successfully.
  1. bin/asadmin get-client-stubs --user admin --appname ejb-stateless-converterApp .
    Command get-client-stubs executed successfully.
  1. bin/appclient -client ./ejb-stateless-converterAppClient.jar
    Default Context Initialized...

===========Beginning Simple Test=====

$100 is : 12160.00Yen
Yen is :0.77Euro
Value of key is: AppClient

Comment by Hong Zhang [ 22/Sep/09 ]

Did you run the upgrade between step 8) and 9)? If yes, did this application get
redeployed successfully as part of the upgrade? If not, what's the exception?

Comment by 1xpert [ 23/Sep/09 ]

Created an attachment (id=3274)
log

Comment by 1xpert [ 28/Sep/09 ]

Per Abhijit's request and Alex, for tracking purpose, I add key word [Blocking]

Comment by 1xpert [ 28/Sep/09 ]

Per Abhijit's request and Alex, for tracking purpose, I add key word [Blocking]

Comment by Hong Zhang [ 28/Sep/09 ]

There are a bunch of exceptions related to tables in the server.log

Marina: could you take a look to why we got those exceptions?

The table related params are specified as false for redeployment during upgrade
as requested:
deployParams.dropandcreatetables = false;
deployParams.createtables = false;

Comment by marina vatkina [ 29/Sep/09 ]

The server.log is very strange as it seems like in the middle of the run the
table disappeared.

Comment by marina vatkina [ 29/Sep/09 ]

The server.log is very strange as it seems like in the middle of the run the
table disappeared.

Comment by Hong Zhang [ 30/Sep/09 ]

Yes, I can reproduce the problem. The get-client-stubs failed after the upgrade.
The redeployment did seem to get through successfully during the upgrade, not
sure why the client jars were not generated. Assign to Tim to take a look at
this part.

Marina: I have attached the server.log for the start up after upgrade. There are
still bunch of exceptions there. Can you take a look to see if they are any
different than the previous ones? If yes, why? We will need your help to resolve
this part.

Comment by Hong Zhang [ 30/Sep/09 ]

Created an attachment (id=3366)
server.log from my run

Comment by Tim Quinn [ 30/Sep/09 ]

neither of the attached server logs show problems in the app client deployer.
Both show problems with database-related access. So I've reassigned this to
Marina.

If we discover that there are app client issues (either in deployment or in
download or ACC) we can reassign this back to me at that point.

Comment by marina vatkina [ 01/Oct/09 ]

The errors in the log are because the Timer Service table needs to be upgraded
(see https://glassfish.dev.java.net/issues/show_bug.cgi?id=9645), and the
converter app uses the Timer Service, so it can't be successfully loaded if the
Timer Service is not fully functioning.

I could've closed it as a duplicate, but I'm reassigning to Hong (I don't know
if it's you Tim or Hong who owns the answers) to decide a) what should happen on
the upgrade if an app fails to redeploy, b) if and how to notify the user about
the problem, and c) how to have a better message on access of that app.

Comment by Hong Zhang [ 01/Oct/09 ]

As this issue is now only open for better error handling, I am moving this bug
to P3 with a new synopsis.

Comment by Bobby Bissett [ 02/Oct/09 ]

Hiya. Can you let me know specifically what error handling the upgrade tool needs to do? All it can do,
as far as I know, if monitor the output of asadmin and alert the user if something has gone wrong. At that
point, the user has to view the server log for output.

Comment by Hong Zhang [ 02/Oct/09 ]

For what Marina pointed out:
a) what should happen on the upgrade if an app fails to redeploy,
b) if and how to notify the user about the problem
c) how to have a better message on access of that app.

For a), the current behavior is we will not fail the whole upgrade if one
application failed to redeploy. I think this is the desired behavior and also
the same behavior as in v2. So we will keep it.

For b), yes, it's a general issue at upgrade level and not specific to
application. This part is for you to figure out (I don't have an answer for it).

For c), I think it will be pretty hard, and it will be different for different
applications. But I will work with Marina to look at what we can do for this
particular case. Any obvious sign during redeployment which can tell us it needs
timer service and it's not there, and print a servere message there to alert
user. Marina: any good place in the code where we can do this?

Comment by Hong Zhang [ 27/Oct/09 ]

marina: please take a look at my last comment on c), anything we can do for this
particular case?

Comment by marina vatkina [ 27/Oct/09 ]

Hong, I can't reproduce the original problem after all the fixes that went in.
But what does happen if the app fails to deploy after upgrade? Does it stay
disabled? If yes, can a user e.g. request the stubs on the disabled app? Do we
know that it's access of an app after an upgrade? If yes, can we tell the user
to go and check the upgrade results?

Comment by Hong Zhang [ 27/Oct/09 ]

Marina: for an application which failed to deploy during upgrade, the log will
show something like "application xxx failed to deploy during upgrade, please
manually redeploy the application".
I don't think we can prevent the user from downloading stubs for an application
which failed deployment, it's just the downloading stubs will fail. And we
cannot really tell if the application is deployed through upgrade after the
fact. But you would hope user would look at the upgrade.log after the upgrade to
search for the error messages, especially after they find one of the application
stopped working..

Comment by marina vatkina [ 28/Oct/09 ]

Hong, will this message "application xxx failed to deploy during upgrade" logged
at the SEVERE level (I think this is the only one that is guaranteed to be
displayed by the upgrade tool)?

Also, can the DeployCommand.retrieveArtifacts first check if the files exist,
and report a (more) meaningful error?

Comment by Bobby Bissett [ 28/Oct/09 ]

Yep, anything logged at the SEVERE level will trigger some behavior in upgrade tool. If there are >0 severe
messages anywhere in the asadmin output, the upgrade tool will tell the user that potential errors were
detected and that the user should check the server log for details.

It used to detect SEVERE and WARNING, but there was always a WARNING message from MiniXmlParser
about parsing things twice and so I removed that. Now that MiniXmlParser is quieter, I can add the check
for WARNING messages back in if you'd prefer. (I just need to check to make sure there isn't some other
warning that always happens.)

Comment by Hong Zhang [ 28/Oct/09 ]

yes, this message is logged as SEVERE.

tim: can you look at the request from marina on improving the error reporting on
DeployCommand.retrieveArtifacts to see if this is something can be easily done?
thanks.

Comment by Tim Quinn [ 28/Oct/09 ]

The DeployCommand#retrieveArtifacts message logging could be revised, but I do
not think that would help much though.

There is nothing the end-user can do to cause or correct such an error (except
perhaps to maliciously manually delete a generated file from the app server's
directory). If an entry exists in the downloadable artifacts data structure but
the file is not there then there is a bug in GlassFish. In such cases the added
information in the log - the stack trace and the missing file - helps to
identify what went wrong.

In the original error scenario, do we know how we got a DownloadableArtifacts
entry for a non-existent file? That shouldn't happen.

Comment by marina vatkina [ 29/Oct/09 ]

Good point. To reproduce the original problem we need to disable __TimerPool
upgrade, and I'm wondering if removing/renaming the
glassfishv3/glassfish/lib/install/databases/upgrade/ejbtimer_upgrade_derby.sql
file can bring us back to that point. Tim, do you have time to check? Otherwise
reassign it to me to try to get the answer.

Comment by Tim Quinn [ 29/Oct/09 ]

I'm afraid I don't have the cycles to redo that test, Marina, so I'll go ahead
and send this back to you.

Comment by marina vatkina [ 29/Oct/09 ]

Tim,

The error says that a) "Error while downloading generated files" and b) that
there is no ejb-stateless-converter-clientClient.jar (and on the latest build
there is no stack trace printed on the asadmin client).

So the problem is not in the stubs (i.e. the error text is misleading), but
that there is no generated directory after the upgrade for a failed redeploy.

On the other note: there are no generated stubs in the v2 deploy, so I'm not
sure if anything would've been download in the 1st place...

Reassigning back to you to check for the generated dir and to improve the error
message. To reproduce the problem I commented out the body of the postConstruct
method in EJBTimerServiceUpgrade.

Comment by Tim Quinn [ 29/Oct/09 ]

Sorry to be dense, but what error text do you think is misleading, Marina? The
admin CLI says that the get-client-stubs command failed, which is true. The
displayed message says that the server could not download a file it tried to
download, which is true.

As for the app generating stubs (or not) in v2 and v3... You are
(understandably) confusing downloaded client files with stubs. Stub classes can
appear inside one of the generated downloaded files, but the downloaded files
will exist (in a successful deployment at least) regardless of whether stubs
were generated or not during the deployment.

What has happened, somehow, is (1) the app client deployer registered the app's
expected files for download, and (2) those files are not there when
get-client-stubs asks for them. I do not understand how this would happen,
especially in the absence of any errors in the server.log at the time of the app
client deployer work.

Bobby and Hong, during the upgrade if the redeploy fails does the upgrade tool
or the attempted redeployment operation itself delete any files that might have
been generated so far? If so, how does it do that? The AppClientDeployer's
clean method which is invoked during an undeployment unregisters the
downloadable artifacts for the client. If the upgrade path in case of an error
were to undeploy the app then the get-client-stubs command should not even find
entries for those files when it runs.

So I guess the app is not undeployed, because GetClientStubsCommand checks to
make sure the app is in the configuration before proceeding, and it must be
there because the logic continues on after its check to try to download the
files. But the files are not there, so that's why I wonder if the follow-up
after the failed redeployment includes cleaning out the generated directory for
the app.

Comment by marina vatkina [ 29/Oct/09 ]

Yes, I was confused, thinking that RMI stubs are being registered without being
created.

But this is what happens in my test (and somebody needs to explain this behavior):
1.run with -upgrade true - this exits at the end
2. % find glassfishv3/glassfish/domains/v2domain1/generated | grep
ejb-stateless-converterApp
glassfishv3/glassfish/domains/v2domain1/generated/jsp/ejb-stateless-converterApp
glassfishv3/glassfish/domains/v2domain1/generated/jsp/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar
glassfishv3/glassfish/domains/v2domain1/generated/jsp/ejb-stateless-converterApp/ejb-stateless-converter-client_jar
glassfishv3/glassfish/domains/v2domain1/generated/ejb/ejb-stateless-converterApp
glassfishv3/glassfish/domains/v2domain1/generated/ejb/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar
glassfishv3/glassfish/domains/v2domain1/generated/ejb/ejb-stateless-converterApp/ejb-stateless-converter-client_jar
glassfishv3/glassfish/domains/v2domain1/generated/xml/ejb-stateless-converterApp
glassfishv3/glassfish/domains/v2domain1/generated/xml/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar
glassfishv3/glassfish/domains/v2domain1/generated/xml/ejb-stateless-converterApp/ejb-stateless-converter-client_jar
glassfishv3/glassfish/domains/v2domain1/generated/xml/ejb-stateless-converterApp/ejb-stateless-converter-client_jar/ejb-stateless-converter-clientClient.jar
glassfishv3/glassfish/domains/v2domain1/generated/xml/ejb-stateless-converterApp/ejb-stateless-converterAppClient.jar
glassfishv3/glassfish/domains/v2domain1/generated/policy/ejb-stateless-converterApp
glassfishv3/glassfish/domains/v2domain1/generated/policy/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar
glassfishv3/glassfish/domains/v2domain1/generated/policy/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar/granted.policy

3. run with the new domain (this fails to start the timer service)
4. % find glassfishv3/glassfish/domains/v2domain1/generated | grep
ejb-stateless-converterApp
glassfishv3/glassfish/domains/v2domain1/generated/policy/ejb-stateless-converterApp
glassfishv3/glassfish/domains/v2domain1/generated/policy/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar
glassfishv3/glassfish/domains/v2domain1/generated/policy/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar/granted.policy

Comment by Hong Zhang [ 29/Oct/09 ]

tim: for a failed (re)deployment during upgrade, we handle like what we handled
with any failed deployment in normal path. We tried to roll back as much as we
can (cleaning up the registry, deleting the files etc). It's possible that the
policy files were left behind as the security code does their own clean up in
failed situation. But I don't understand why the file contents are different
right after upgrade versus after starting the new domain.

Comment by Tim Quinn [ 31/Oct/09 ]

I went through exactly the steps outlined in the original post, with the
exception that I downloaded the Oct. 31 nightly build of b71.

The files in the generated directory were as expected.

Everything worked as expected, including the get-client-stubs. I could even
launch the client successfully after the download.

So I'm closing this, because it seems to be working with the latest changes in v3.





[GLASSFISH-9663] upgrade hang when multiple applications are deployed Created: 22/Sep/09  Updated: 26/Nov/10  Resolved: 02/Oct/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Critical
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Attachments: Java Archive File domains.jar     Java Archive File domains.jar     Text File server.log    
Issue Links:
Dependency
depends on GLASSFISH-9251 user messages going to log instead of... Resolved
Issuezilla Id: 9,663

 Description   

Sidebyside upgrade between 9.1_01 and v3 on linux5.0 in cli mode.

I deployed 10 applications on 9.1_01 b09d. After upgrading to v3, the upgrade
process hangs after more than 20 minutes wait time.

  1. ls -al /opt/91_01/domains/domain1/applications/j2ee-apps/
    total 56
    drwxr-xr-x 14 root root 4096 Sep 22 07:50 .
    drwxr-xr-x 6 root root 4096 Sep 22 07:23 ..
    drwxr-xr-x 5 root root 4096 Sep 22 07:40 connector-cciApp
    drwxr-xr-x 6 root root 4096 Sep 22 07:42 connector-embedded-cciApp
    drwxr-xr-x 6 root root 4096 Sep 22 07:37 ejb-cmp-cmporderApp
    drwxr-xr-x 6 root root 4096 Sep 22 07:35 ejb-cmp-rosterApp
    drwxr-xr-x 4 root root 4096 Sep 22 07:33 __ejb_container_timer_app
    drwxr-xr-x 5 root root 4096 Sep 22 07:32 ejb-ejb30-hello-sessionApp
    drwxr-xr-x 5 root root 4096 Sep 22 07:28 ejb-mdb-simpleApp
    drwxr-xr-x 5 root root 4096 Sep 22 07:44 ejb-sfsblifecyleApp
    drwxr-xr-x 5 root root 4096 Sep 22 07:25 ejb-stateless-converterApp
    drwxr-xr-x 4 root root 4096 Sep 22 07:25 __JWSappclients
    drwxr-xr-x 4 root root 4096 Sep 22 07:24 MEjbApp
    drwxr-xr-x 5 root root 4096 Sep 22 07:50 sec-ssl-converterApp

Steps to produce:
1) pick up from
/net/koori/onestop/glassfish/9.1_01/promoted/fcs/b09d/bundles/sjsas-9_1_01-fcs-bin-b09d-linux-06_dec_2007.bin
2) install build
3) checkout quicklooks tests using instruction at
http://glassfish.dev.java.net/public/GuidelinesandConventions.html#Quicklook_Tests
4) need to modify each test build.xml to do everything except undeploy,unsetup
because we need these applications and its setup to be transferred to v3 server.
5) execute tests using ant all-pe
6) stop domain1, derby db
7) install glassfish v3 nightly build dated 9/22/09 in a different location
other than 9.1_01 build location
8) invoke asupgrade in <glassfishv3 install>/bin/asupgrade in cli mode



 Comments   
Comment by Bobby Bissett [ 22/Sep/09 ]

Can you try this with the gui mode first and let me know if it still hangs? There are a couple bugs still
open about the command line mode.

Please attach a domain to reproduce this. You can zip up the one you already have.

Comment by 1xpert [ 22/Sep/09 ]

Created an attachment (id=3266)
domains of 9.1_01 build

Comment by 1xpert [ 22/Sep/09 ]

Created an attachment (id=3267)
attachment for ejb-stateless-converterApp.ear deployment

Comment by 1xpert [ 22/Sep/09 ]

pls ignore attachment for ejb-stateless-converterApp.ear deployment..this is for
a different bug.

Will attach domain in gui mode later.

Comment by Bobby Bissett [ 23/Sep/09 ]

Adding dependency since the hang could be related to some bug in the CLI.

Comment by 1xpert [ 23/Sep/09 ]

Created an attachment (id=3272)
server log

Comment by 1xpert [ 23/Sep/09 ]

pls ignore this server.log...wrong attachment ...

Comment by 1xpert [ 24/Sep/09 ]

More details on Step 3 of this issue.

Easy way to checkout V2 quicklooks test:

1) set variables:
set CVSROOT to :pserver:<your java.net id>@cvs.dev.java.net:/cvs
set APS_HOME to point to <quicklooks workspace>/appserv-tests
set S1AS_HOME to point to appserver or glassfish server
set JAVA_HOME to point to 1.6.0_14
set ANT_HOME to point to 1.6.5
set PATH to point to $ANT_HOME/bin:$JAVA_HOME/bin:$PATH

2) cvs login
cvs co -r SJSAS91_FCS_BRANCH glassfish/appserv-tests

3) cd <workspace directory>/appserv-tests/sqetests and choose to execute the
following tests.

connector/cci
connector/cci-embedded
ejb/cmp/roster
ejb/ejb30/hello
ejb/mdb/simple
ejb/stateful/passivate
ejb/stateless/converter
ejb/security/ssl/converter

Comment by Bobby Bissett [ 01/Oct/09 ]

Cannot run the server with the attached domain. There are many warnings in the log when I start up. Were
there any databases created? If so, these need to be attached as well. I'll try just deploying the individual
sqe tests to see if that works, but if not we may need to have a simplified test case for this bug. I'd rather
not spend too much time on this because I think it may be fixed anyway now because of work on issue
9351.

Comment by Bobby Bissett [ 02/Oct/09 ]

Still cannot even run the test case as instructed. Running even one test, sqetests/connector/cci, hangs
during the test run and I see this error in the v2.1 server log:

[#|2009-10-02T11:51:05.946-0400|INFO|sun-
appserver2.1|javax.enterprise.resource.resourceadapter|_ThreadID=18;_ThreadName=p: thread-pool-
1; w: 6;|org.apache.derby.client.am.SqlException: Java exception: 'SampleExternalMethods:
java.lang.ClassNotFoundException'.|#]

Will try again to simply deploy the apps without running the test and do an upgrade, but this is the best
I can do without further instructions on how to use the sqe tests.

Comment by Bobby Bissett [ 02/Oct/09 ]

Works for me – the steps I took are below. I am thinking that the work on issue 9351 fixed this. Here
my steps for reproducing the issue in case I've missed anything:

1. In v2.1/glassfish dir, started database and server.

2. Deploy connector/cci

hostname% cvs diff build.xml
Index: build.xml
===============================================================
====
RCS file: /cvs/glassfish/appserv-tests/sqetests/connector/cci/build.xml,v
retrieving revision 1.3
diff -r1.3 build.xml
18c18
< <target name="all" depends="build,setup,deploy,run,undeploy,unsetup"/>

> <target name="all" depends="build,setup,deploy"/>

run "ant -emacs all"

3. Repeat
hostname% cvs diff build.xml
Index: build.xml
===============================================================
====
RCS file: /cvs/glassfish/appserv-tests/sqetests/connector/cci-embedded/build.xml,v
retrieving revision 1.3
diff -r1.3 build.xml
18c18
< <target name="all" depends="build,setup,deploy,run,undeploy,unsetup"/>

> <target name="all" depends="build,setup,deploy"/>

Server had the following error, but the ant target completed successfully so am continuing:

[#|2009-10-02T12:21:28.006-0400|WARNING|sun-
appserver2.1|javax.enterprise.system.stream.err|_ThreadID=15;_ThreadName=httpWorkerThread-
4848-0;_RequestID=26925415-6c35-41b4-9628-436605c4b6e4;|java.lang.NullPointerException
at
com.sun.enterprise.server.ConnectorResourcesLoader.loadEmbeddedRarResources(ConnectorResources
Loader.java:170)
at
com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:664)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.invokeApplicationDeployEventListener(AdminEv
entMulticaster.java:959)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.handleApplicationDeployEvent(AdminEventMult
icaster.java:943)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java:467)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java:182
)
at
com.sun.enterprise.admin.server.core.DeploymentNotificationHelper.multicastEvent(DeploymentNotific
ationHelper.java:308)
at
com.sun.enterprise.deployment.phasing.DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils
.java:231)
at
com.sun.enterprise.deployment.phasing.ServerDeploymentTarget.sendStartEvent(ServerDeploymentTar
get.java:298)
at
com.sun.enterprise.deployment.phasing.ApplicationStartPhase.runPhase(ApplicationStartPhase.java:132
)
at
com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java
:966)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:609)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:653)
at
com.sun.enterprise.admin.mbeans.ApplicationsConfigMBean.start(ApplicationsConfigMBean.java:773)
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 com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:381)
at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:364)
at com.sun.enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java:477)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836
)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java:90)
at $Proxy1.invoke(Unknown Source)
at
com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.invoke(SunoneInterceptor.java:304)
at com.sun.enterprise.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:174)
at com.sun.enterprise.admin.jmx.remote.server.callers.InvokeCaller.call(InvokeCaller.java:69)
at
com.sun.enterprise.admin.jmx.remote.server.MBeanServerRequestHandler.handle(MBeanServerRequest
Handler.java:155)
at
com.sun.enterprise.admin.jmx.remote.server.servlet.RemoteJmxConnectorServlet.processRequest(Remo
teJmxConnectorServlet.java:122)
at
com.sun.enterprise.admin.jmx.remote.server.servlet.RemoteJmxConnectorServlet.doPost(RemoteJmxCo
nnectorServlet.java:193)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:427)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:315)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:287)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:218)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.ja
va:98)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:222)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1096)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:166)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1096)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:288)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.ja
va:647)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:5
79)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:831
)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.jav
a:341)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at com.sun.enterprise.web.connector.grizzly.WorkerThreadImpl.run(WorkerThreadImpl.java:116)

#]

[#|2009-10-02T12:21:28.014-0400|WARNING|sun-
appserver2.1|javax.enterprise.system.tools.admin|_ThreadID=15;_ThreadName=httpWorkerThread-
4848-0;_RequestID=26925415-6c35-41b4-9628-436605c4b6e4;|ADM5603:Event listener error
[null]|#]

[#|2009-10-02T12:21:28.029-0400|WARNING|sun-
appserver2.1|javax.enterprise.system.tools.admin|_ThreadID=15;_ThreadName=httpWorkerThread-
4848-0;Error while loading application [connector-embedded-cciApp]. Please refer to the server log
for more details. ;_RequestID=26925415-6c35-41b4-9628-436605c4b6e4;|ADM1075:Error on
listening event:[Error while loading application [connector-embedded-cciApp]. Please refer to the
server log for more details. ]|#]

4. Repeat

hostname% cvs diff build.xml
Index: build.xml
===============================================================
====
RCS file: /cvs/glassfish/appserv-tests/sqetests/ejb/cmp/roster/build.xml,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 build.xml
15c15
< <target name="all" depends="build,setup,deploy,run,undeploy,unsetup"/>

> <target name="all" depends="build,setup,deploy"/>

5. Repeat

hostname% cvs diff build.xml
Index: build.xml
===============================================================
====
RCS file: /cvs/glassfish/appserv-tests/sqetests/ejb/ejb30/hello/session/build.xml,v
retrieving revision 1.6
diff -r1.6 build.xml
17c17
< <target name="all" depends="build,setup,deploy,run,undeploy,unsetup"/>

> <target name="all" depends="build,setup,deploy"/>

(Note: for some reason, this stopped and restarted the server. That should be a separate target!)

6. Repeat

hostname% cvs diff build.xml
Index: build.xml
===============================================================
====
RCS file: /cvs/glassfish/appserv-tests/sqetests/ejb/mdb/simple/build.xml,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 build.xml
15c15
< <target name="all" depends="build,setup,deploy,run,undeploy,unsetup"/>

> <target name="all" depends="build,setup,deploy"/>

7. Repeat

hostname% !cvs
cvs diff build.xml
Index: build.xml
===============================================================
====
RCS file: /cvs/glassfish/appserv-tests/sqetests/ejb/stateful/passivate/build.xml,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 build.xml
15c15
< <target name="all" depends="build,setup,deploy,run,undeploy,unsetup"/>

> <target name="all" depends="build,setup,deploy"/>

8. Repeat

hostname% cvs diff build.xml
Index: build.xml
===============================================================
====
RCS file: /cvs/glassfish/appserv-tests/sqetests/ejb/stateless/converter/build.xml,v
retrieving revision 1.3
diff -r1.3 build.xml
16c16
< <target name="all" depends="clean,build,setup,deploy,run,undeploy,unsetup"/>

> <target name="all" depends="clean,build,setup,deploy"/>

9. Repeat

hostname% cvs diff build.xml
Index: build.xml
===============================================================
====
RCS file: /cvs/glassfish/appserv-tests/sqetests/security/ssl/converter/build.xml,v
retrieving revision 1.6
diff -r1.6 build.xml
16c16
< <target name="all" depends="build,deploy,run,undeploy"/>

> <target name="all" depends="build,deploy"/>

10. Verify that they're deployed:

hostname% ~/servers/gfv2.1/glassfish/bin/asadmin list-components
cciblackbox-tx <connector-module>
connector-cciApp <j2ee-application>
connector-embedded-cciApp <j2ee-application>
ejb-cmp-rosterApp <j2ee-application>
ejb-ejb30-hello-sessionApp <j2ee-application>
ejb-mdb-simpleApp <j2ee-application>
ejb-sfsblifecyleApp <j2ee-application>
ejb-stateless-converterApp <j2ee-application>
sec-ssl-converterApp <j2ee-application>
Command list-components executed successfully.

11. Shut down v2 server

12. Run the upgrade. Upgrade did not hang. There were some errors in the server log about a corba
issue, but this is unrelated to the upgrade (I see the same error simply starting the domain with revision
32174 of the workspace).

Comment by Bobby Bissett [ 02/Oct/09 ]

Adding vella to cc list to keep up to date on upgrade status.





[GLASSFISH-9653] upgrade fails if source domain is in target domains dir Created: 22/Sep/09  Updated: 23/Sep/09  Resolved: 23/Sep/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Critical
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 9,653

 Description   

Given a v2 and v3 server, asupgrade works fine with "-s v2/domains/domain1." If domain1 is copied to
the v3 installation, asupgrade fails with "-s v3/domains/domain1." The asadmin start-domain process
is exiting with an error code of 1 and no other information is given at the default logging level.

This is specific to using the tool, because running "asadmin start-domain --upgrade domain1" is
successful (with a newly built server). After getting the error above and trying manually, I get the error
output below. Hopefully this is just a problem that the copylibs code shouldn't be run when the domain
to be upgraded is already in the target server's domains dir.

— begin —
Error occurred during initialization of VM
agent library failed to init: instrument
Error opening zip file or JAR manifest missing :
/Users/bobby/servers/glassfishv3/glassfish/lib/monitor/btrace-agent.jar
JVM failed to start: com.sun.enterprise.admin.launcher.GFLauncherException: The server exited
prematurely with exit code 1.
Before it died, it produced the following output:

Command start-domain failed.
— end —



 Comments   
Comment by Bobby Bissett [ 22/Sep/09 ]

Nope, not the copylibs code. Only other obvious difference between the tool and manually upgrading (by
calling asadmin) is the --domaindir option used by the tool. Will give that a look.

Comment by Bobby Bissett [ 23/Sep/09 ]

Yeah, it was the copylibs. I have a fix to avoid this.

Comment by Bobby Bissett [ 23/Sep/09 ]

Fixed in revision 31763.





[GLASSFISH-9641] Cannot start admin console on upgraded v2.1 domain Created: 22/Sep/09  Updated: 27/Nov/10  Resolved: 01/Oct/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Critical
Reporter: Bobby Bissett Assignee: jluehe
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Attachments: XML File domain.xml     GZip Archive empty_v2_1_domain.tar.gz     Text File server.log    
Issuezilla Id: 9,641

 Description   

-Perform an upgrade of an empty GFv2.1 domain.
-Start the newly upgraded domain.
-Try to go to localhost:4848 in browser.

Will attach logs and domain, but this is the output in the server log:
[#|2009-09-22T11:42:24.676-0400|INFO|glassfish|null|_ThreadID=33;_ThreadName=Thread-3;|The
Admin Console Application is not yet installed.|#]

[#|2009-09-22T11:42:24.676-0400|INFO|glassfish|null|_ThreadID=33;_ThreadName=Thread-
3;|Problem while attempting to install admin console!
java.lang.NullPointerException
at java.lang.reflect.Proxy.getInvocationHandler(Proxy.java:636)
at org.jvnet.hk2.config.Dom.unwrap(Dom.java:167)
at org.jvnet.hk2.config.ConfigSupport.apply(ConfigSupport.java:129)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.install(InstallerThread.java:249)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:99)



 Comments   
Comment by Anissa Lam [ 22/Sep/09 ]

What does that mean by "empty GFv2.1 domain" ?
Can you attach domain.xml ?
Does the upgrade already have lib/install/applications/admingui.war ?
Is it possible to include the steps too reproduce this bug. Please specify the
command and where we can find the build, tools etc.
thanks

Comment by Bobby Bissett [ 22/Sep/09 ]

Created an attachment (id=3258)
Empty (nothing deployed) v2.1 domain before upgrade

Comment by Bobby Bissett [ 22/Sep/09 ]

Created an attachment (id=3259)
Server log when I start the domain and try to access localhost:4848

Comment by Bobby Bissett [ 22/Sep/09 ]

Am still trying to attach the newly upgraded domain but it is timing out. (Gzipped domain goes from 3
meg to 50 meg during upgrade; that's gotta be a problem). Will cancel and attach domain.xml instead.

I've attached the server.log when the error occurs. To answer your questions, an empty domain is the
baseline: GFv2.1 installed, started, stopped. Nothing deployed. The upgrade goes through without any
errors, but then a user should be able to use this domain as if it were a v3 domain. The server starts
and I can view localhost:8080, but not the admin console.

More details about the steps: You can download the v2.1 domain I've attached. Then run bin/asupgrade
on it (the v2 domain is the source, your v3 server is the target). Then start the domain normally and try
to access the admin console.

Will attach the domain.xml after the upgrade (but before starting the domain) next since I can't attach
the domain itself.

Comment by Bobby Bissett [ 22/Sep/09 ]

Created an attachment (id=3260)
domain.xml after upgrade, before starting domain

Comment by Anissa Lam [ 23/Sep/09 ]

The issue is due to the missing
<system-applications /> in domain.xml

The installation code of admingui is expecting the existence of this element,
but this is a new element for v3, thus doesn't exist in the upgrade scenario.

Thus, in the line
ConfigSupport.apply(code, domain.getSystemApplications(), server);

domain.getSystemApplications() causes NPE.
We may need to add the empty "system-applications" element.

Comment by Anissa Lam [ 24/Sep/09 ]

Talked with Hong. Instead for GUI to add <system-applications/> in the adapter
code when user first access GUI, she will add this during the upgrade process.
Transferring to her.

Comment by Hong Zhang [ 25/Sep/09 ]

I have made the changes in the UpgradeService to add the empty
system-applications element. But for some reason, it did not add it, maybe
because it's an empty element. I have checked in what I have and asked jerome to
take a look to see if the underlying hk2 code prevent it from happening.

Comment by Hong Zhang [ 30/Sep/09 ]

Jerome has fixed adding the system-applications part. But now I am seeing a
different problem when loading the gui:

Caused by: java.lang.NoClassDefFoundError: com/sun/enterprise/InjectionException
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
at java.lang.Class.getConstructor(Class.java:1657)
at
com.sun.faces.spi.InjectionProviderFactory.getProviderInstance(InjectionProviderFactory.java:147)
at
com.sun.faces.spi.InjectionProviderFactory.createInstance(InjectionProviderFactory.java:112)
at
com.sun.faces.application.ApplicationAssociate.<init>(ApplicationAssociate.java:197)
at
com.sun.faces.application.ApplicationImpl.<init>(ApplicationImpl.java:209)

After talking with Ryan Lubke, he pointed the problem is this element in
default-web.xml.

<context-param>
<param-name>com.sun.faces.injectionProvider</param-name>
<param-value>com.sun.faces.vendor.GlassFishInjectionProvider</param-value>
</context-param>

this element needs to be removed as part of the upgrade.

I am assigning this issue to Jan to follow up.

Comment by jluehe [ 01/Oct/09 ]

Sending
web/web-glue/src/main/java/com/sun/enterprise/web/TomcatDeploymentConfig.java
Transmitting file data .
Committed revision 32123.





[GLASSFISH-9563] upgrade tool should use javahelp in modules dir Created: 17/Sep/09  Updated: 18/Sep/09  Resolved: 18/Sep/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Critical
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 9,563

 Description   

Upgrade tool should use the javahelp module already in the modules dir. Bundling the classes causes
issues in the findbugs automated run and duplicates classes.



 Comments   
Comment by Bobby Bissett [ 17/Sep/09 ]

Changes were simple; just waiting on pom review now.

Comment by Bobby Bissett [ 18/Sep/09 ]

Fixed in revision 31484.





[GLASSFISH-9429] help documentation needs to be updated Created: 09/Sep/09  Updated: 26/Nov/10  Resolved: 08/Oct/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Major
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issue Links:
Dependency
depends on GLASSFISH-9428 admin username and password should be... Resolved
Issuezilla Id: 9,429

 Description   

The help documentation needs to be updated, especially with the user interface changes.



 Comments   
Comment by Bobby Bissett [ 09/Sep/09 ]

Adding dependency.

Comment by Bobby Bissett [ 02/Oct/09 ]
      • Issue 9846 has been marked as a duplicate of this issue. ***
Comment by Bobby Bissett [ 08/Oct/09 ]

Fixed in revision 32482.





[GLASSFISH-9428] admin username and password should be removed Created: 09/Sep/09  Updated: 26/Nov/10  Resolved: 15/Sep/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Critical
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issue Links:
Dependency
blocks GLASSFISH-9429 help documentation needs to be updated Resolved
Issuezilla Id: 9,428

 Description   

Admin username and password are not used in v3, so it's confusing and unnecessary to ask the user for
them. I need to remove them from the GUI and command line interface. Master password is still used if
someone has set a different master password in his/her server.



 Comments   
Comment by Bobby Bissett [ 11/Sep/09 ]

Starting on this one (once I can build in IDE again).

Comment by Bobby Bissett [ 15/Sep/09 ]

Fixed in revision 31362.





[GLASSFISH-9412] can't change log level of upgrade tool output Created: 08/Sep/09  Updated: 11/Sep/09  Resolved: 11/Sep/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Major
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 9,412

 Description   

Can't change the log levels thought the scripts – they have some old logger name in them rather than
the current logger being used by the tool.



 Comments   
Comment by Bobby Bissett [ 11/Sep/09 ]

Issue was that those properties shouldn't be there in the first place. Use normal logging.properties file to
change log levels. Removed props in revision 31264.





[GLASSFISH-9387] tool prompts for new target location when user do not want to rename domain1 Created: 04/Sep/09  Updated: 08/Sep/09  Resolved: 08/Sep/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Major
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 9,387

 Description   

Using latest-glassfish.zip of 03-Sep-2009 13:03 75M

Tool prompts for new target directory if user doesn't want to rename domain1
directory..Tool should let user to continue instead of giving prompt again.

bash-3.00# bin/asupgrade -c
Enter the Domain directory of the source:/opt/91/domains/domain1
Enter the Target Domains Root:/export/home/glassfishv3/glassfish/domains
The domain domain1 already exists. Would you like to rename it (y/n)?n
Enter the Target Domains Root:/export/home/glassfishv3/glassfish/domains
The domain domain1 already exists. Would you like to rename it (y/n)?y



 Comments   
Comment by Bobby Bissett [ 08/Sep/09 ]

The user can't continue in this case. If there is already a domain (or any directory) in the target directory
with the same name as the domain to be copied over, the tool can't copy the domain. The user either
needs to pick a new target directory or let the tool rename the existing domain to get it out of the way.

I'll clean up the language to make this more clear when I handle issue 9253.





[GLASSFISH-9366] Cancel button doesn't cancel upgrade in progress Created: 03/Sep/09  Updated: 07/Dec/11  Resolved: 07/Dec/11

Status: Closed
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: future release

Type: Improvement Priority: Minor
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 9,366
Status Whiteboard:

v3_exclude

Tags: 3_2-upgrade

 Description   

Am filing this as a P3, but am open to reducing it. I don't know if this ever worked before.

There is a cancel button in the GUI that allows the user to exit the tool at the data collection stage. Once
the user clicks "next," the upgrade proceeds and the cancel button is not enabled. This should probably
be enabled and be connected so that ends the upgrade process. However, the process doesn't take very
long so this might not be needed (especially is a confirmation dialog of "are you sure you want to hose
your upgrade?" is presented).



 Comments   
Comment by Bobby Bissett [ 15/Sep/09 ]

Downgrading to a P4. This wasn't originally in the upgrade tool and I'm not sure it's worth the effort now
since killing the asadmin process during an upgrade would have an unknown result. If we think asadmin is
going to start hanging then we can revisit.

Comment by Bobby Bissett [ 05/Oct/09 ]

Per issue 9992, exiting the tool (at least the GUI) should also cancel the asadmin process. Alternatively, it
could give the user to let the upgrade run while ending the upgrade tool process only.

Comment by Bobby Bissett [ 05/Oct/09 ]
      • Issue 9992 has been marked as a duplicate of this issue. ***
Comment by Bobby Bissett [ 05/Oct/09 ]
      • Issue 9992 has been marked as a duplicate of this issue. ***
Comment by Bobby Bissett [ 10/Nov/09 ]

Setting target milestone to 3.1.

Comment by Bobby Bissett [ 10/Nov/09 ]

This is actually an enhancement, not defect. Am raising to a P3 to add for release 3.1.

Comment by Bobby Bissett [ 07/Dec/11 ]

The upgrade tool has been discontinued post 3.1.X, so am closing this issue.





[GLASSFISH-9364] Upgrade tool does not start the server to perform the upgrade Created: 03/Sep/09  Updated: 26/Nov/10  Resolved: 03/Sep/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Critical
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issue Links:
Dependency
depends on GLASSFISH-9360 broken pipe error can occur with asad... Resolved
Issuezilla Id: 9,364

 Description   

The current code to exec() the asadmin process doesn't work. A fix is known; am filing this issue to track
it. Due to issue 9360, a workaround may be used rather than using asadmin internally. May use "java -jar"
to start the server instead.



 Comments   
Comment by Bobby Bissett [ 03/Sep/09 ]

Added dependency on issue 9360. I can add a workaround now, but I probably need to use asadmin
rather than calling java command directly.

Comment by Bobby Bissett [ 03/Sep/09 ]

This is now fixed in revision 31122. However, it includes a workaround for issue 9360 that we may want
to remove after that one is resolved. Email thread is here:
https://glassfish.dev.java.net/servlets/BrowseList?list=dev&by=thread&from=2003015





[GLASSFISH-9328] command line msgs to log, not console Created: 01/Sep/09  Updated: 03/Sep/09  Resolved: 03/Sep/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Major
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 9,328

 Description   

Prompts meant for the user are going to the upgrade.log file rather than the console, so the user is
missing feedback.



 Comments   
Comment by Bobby Bissett [ 03/Sep/09 ]

This is actually the cause of issue 9251. Am closing this one as a duplicate.

      • This issue has been marked as a duplicate of 9251 ***




[GLASSFISH-9262] could not open upgrade tool on windows xp Created: 25/Aug/09  Updated: 31/Aug/09  Resolved: 31/Aug/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Major
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File asupgrade.bat    
Issuezilla Id: 9,262

 Description   

Using 8/25/09 V3 latest-glassfish.zip build from
http://download.java.net/glassfish/v3/nightly

Install latest-glassfish.zip on windows XP

Try to invoke asupgrade tool but got error below:

C:\nga\glassfishv3\glassfish\bin>asupgrade.bat
=C:/nga/glassfishv3/glassfish
'AS_INSTALL' is not recognized as an internal or external command,
operable program or batch file.
'AS_INSTALL_LIB' is not recognized as an internal or external command,
operable program or batch file.
'AS_INSTALL_MOD' is not recognized as an internal or external command,
operable program or batch file.
'CONFIG_HOME' is not recognized as an internal or external command,
operable program or batch file.
'"\asenv.bat"' is not recognized as an internal or external command,
operable program or batch file.
'AS_INSTALL' is not recognized as an internal or external command,
operable program or batch file.
The system cannot find the path specified.



 Comments   
Comment by Bobby Bissett [ 31/Aug/09 ]

Am stealing a little windows time and am seeing the error. Time to
dust off the part of my brain that remembers batch files.

Comment by Bobby Bissett [ 31/Aug/09 ]

I've committed a change that I think fixes this issue. I'm not sure how this batch script ever worked since
it wasn't using 'set' to define vars, but what do I know? I need to pull down a build on a borrowed windows
machine to make sure this is the right fix. In the mean time, I will attach the asupgrade.bat file so you can
try a fix immediately.

Comment by Bobby Bissett [ 31/Aug/09 ]

Created an attachment (id=3152)
windows asupgrade script to test

Comment by Bobby Bissett [ 31/Aug/09 ]

Just tested the changes from a continuous integration build and everything worked. There's a dependence
on JAVA_HOME being set, but I'm not sure right now if the other scripts depend on that or not. If we need
to add a user message about it, it needs to be in both scripts; I'd rather have a separate bug about that
and deal with it after everything is working.

Fixed in revision 30954.





[GLASSFISH-9258] prompts for valid values Created: 25/Aug/09  Updated: 23/Sep/09  Resolved: 23/Sep/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Improvement Priority: Major
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 9,258

 Description   

Using 8/25/09 V3 latest-glassfish.zip

Some suggestion to current prompting for source and target directory

Current prompts have:

Enter the Domain directory of the source:
Enter the Target Domains Root:

Suggestions for consideration:

Enter the Source directory:
Enter the Target directory:

or

Enter the domain directory of the source:
Enter domains root directory of the target:

or

Enter the Source's domain:
Enter the Target domains root:



 Comments   
Comment by Bobby Bissett [ 25/Aug/09 ]

Am reassigning v3 upgrade bugs to myself.

Comment by Bobby Bissett [ 01/Sep/09 ]

Am changing this to an RFE. I agree that the wording could be clearer and want to make the changes, but I
want to organize issues to handle defects first.

Comment by Bobby Bissett [ 23/Sep/09 ]

Fixed in revision 31769.





[GLASSFISH-9257] password values should be hidden, need message on location of upgrade.log Created: 25/Aug/09  Updated: 23/Sep/09  Resolved: 23/Sep/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Major
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 9,257

 Description   

Need to hide admin password and masterpassword as user entered them. Also,
there's no message on the location of upgrade.log after giving correct target
directory location

Steps to reproduce:
1) use latest-glassfish.zip dated 8/25/09 from
http://download.java.net/glassfish/v3/nightly

2) execute <glassfish installation>/bin/asupgrade -c

bash-3.00# bin/asupgrade -c
Enter the Domain directory of the source:/opt/sges21/domains
Enter the Domain directory of the source:
Enter the Domain directory of the source:/opt/sges21/domains/domain1
Enter the Target Domains Root:/export/home/glassfishv3/glassfish/domains
The domain domain1 already exists. Would you like to rename it (y/n)?y
Enter the Admin User:admin
Enter the Admin Password:adminadmin
Enter the Master password:changeit



 Comments   
Comment by Bobby Bissett [ 25/Aug/09 ]

Am reassigning v3 upgrade bugs to myself.

Comment by Bobby Bissett [ 31/Aug/09 ]

Will give this a look. The code for input/output has changed and I need to check what it's using now.
java.io.Console should be fine unless it's relying on some other shared glassfish code.

Comment by Bobby Bissett [ 23/Sep/09 ]

Fixed in revision 31769.





[GLASSFISH-9253] need message display valid values for source, target directory prior to prompting Created: 25/Aug/09  Updated: 23/Sep/09  Resolved: 23/Sep/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Major
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 9,253

 Description   

Steps to reproduce:

1) download latest-glassfish.zip of datestamp 8/25/08 from
http://download.java.net/glassfish/v3/nightly

2) unzip latest-glassfish.zip to install

3) execute <glassfish installation>/bin/asupgrade -c

Need message to show acceptable values for source and target directory used in
upgrade. In previous release, we have the following output message. For V3,
message needs to be different to reflect current data.

Valid values for source and Target are as follows :

If upgrading from Sun Java System Application Server 8.x or 9.x, specify domain
directory for Source. The target directory should be the domains root.

Enter the Domain directory of the source:



 Comments   
Comment by 1xpert [ 25/Aug/09 ]

Some suggestion:

Valid value for source directory is the domain directory you wish to upgrade.
For target directory, it should be domains root directory.

Example of upgrading domain1 of v2.1 to glassfish v3:

Enter source directory: /export/sgesv2.1/domains/domain1
Enter target directory: /export/glassfishv3/glassfish/domains

Comment by Bobby Bissett [ 25/Aug/09 ]

Am reassigning v3 upgrade bugs to myself.

Comment by Bobby Bissett [ 08/Sep/09 ]

Additional note: make the text more clear about renaming conflicting domains or picking a new target
directory. See issue 9387 for details.

Comment by Bobby Bissett [ 23/Sep/09 ]

I've made this more clear (it matches the GUI case now, on which the help pages are based), but don't want
to add examples in there unless we really need to. I've made the text more clear when an invalid entry is
entered. Will mark fixed with next commit.

Comment by Bobby Bissett [ 23/Sep/09 ]

Fixed in revision 31769.





[GLASSFISH-9251] user messages going to log instead of console Created: 25/Aug/09  Updated: 26/Nov/10  Resolved: 23/Sep/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Critical
Reporter: 1xpert Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issue Links:
Dependency
blocks GLASSFISH-9663 upgrade hang when multiple applicatio... Resolved
Issuezilla Id: 9,251

 Description   

Tool doesn't detect nonexistent source directory

Steps to execute:
1. download glassfish v3 from http://download.java.net/glassfish/v3/nightly/
having date stamp:

latest-glassfish.zip 25-Aug-2009 04:50 74M

2. unzip latest-glassfish.zip

3. invoke upgrade tool in CLI mode. Gives incorrect sges v2.1 build location.
The tool gives more prompts to enter. It should gives error if the source
directory doesn't exist.

bash-3.00# bin/asupgrade -c
Enter the Domain directory of the source:/opt/sgesv21
Enter the Domain directory of the source:
Enter the Domain directory of the source:
Enter the Domain directory of the source:^C



 Comments   
Comment by 1xpert [ 25/Aug/09 ]

Tool should give error and usage text. Example from previous release:

Source Directory is invalid. Please enter a valid Domain Directory or Domain
Root. Refer to Help for more information.
Usage :
asupgrade [-c/--console] [-V/-v/--version] [-h/--help] [s/-source
source_domain_directory] [-t/--target target_domains_root] [-a/--adminuser user]
[-f/--passwordfile pwd_file_path]

-c --console Launches the upgrade command line utility.
-V -v --version The version of the Upgrade Tool.
-h --help Displays the arguments for launching the upgrade utility.
-s --source The directory of the older Application Server's domain.
-t --target The directory of the Application Server 9.1's domain.
-a --adminuser The admin user for the source server.
-f --passwordfile The path to the file containing admin and master
passwords.

Comment by Bobby Bissett [ 03/Sep/09 ]
      • Issue 9328 has been marked as a duplicate of this issue. ***
Comment by Bobby Bissett [ 03/Sep/09 ]

This is actually the problem that messages are being sent to the log rather than to the console where the
user can see them. In the GUI case, I think the user is properly notified.

Comment by Bobby Bissett [ 08/Sep/09 ]

Changing the summary to the underlying issue so I can keep track better. Original summary was:
"upgrade tool fails to detect nonexistent source directory"

Comment by Bobby Bissett [ 23/Sep/09 ]

Fixed in revision 31763.





[GLASSFISH-9163] list-virtual-servers failed to list server created before upgrade happens Created: 18/Aug/09  Updated: 01/Dec/10  Resolved: 11/Sep/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: v2.1.1
Fix Version/s: v2.1.1_dev

Type: Bug Priority: Major
Reporter: 1xpert Assignee: rebeccas
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Attachments: Text File upgrade.log    
Issuezilla Id: 9,163

 Description   

OS: linux5.0
Type of upgrade: sidebyside

After upgrade to v2.1.2, virtual server created in v2 is not available

1) install v2
2) create new domain using port 4849
3) create cluster
4) create virtual server e.g.:

$S1AS_HOME/bin/asadmin create-virtual-server --user admin --passwordfile $pass
--port 4849 --target sqe-cluster --hosts localhost myvs1

5) stop all processes
6) upgrade to v2.1.1 by installing v2.1.1 in a new directory than v2
7) invoke upgrade tool e.g. <v2.1.1 installation>/bin/asupgrade -c, provide the
required values
8) start all processes (domain, nodeagent --syncinstances=true)
9) issue command below:

bin/asadmin list-virtual-servers --port 4849
Please enter the admin user name>admin
Please enter the admin password>
server
__asadmin
Command list-virtual-servers executed successfully

On windows, it shows the virtual server created in v2 however on linux and
solaris, it doesn't show the virtual server created.



 Comments   
Comment by 1xpert [ 18/Aug/09 ]

Created an attachment (id=3100)
upgrade log

Comment by 1xpert [ 25/Aug/09 ]

need fix in v2.1.1

Comment by rebeccas [ 26/Aug/09 ]

The short term workaround, perform an in-place upgrade. Do not run upgrade tool.
Start the server.

Comment by 1xpert [ 31/Aug/09 ]

Closing bug as not a bug.

Comment by Ed Bratt [ 11/Sep/09 ]

Closing as stated by reporter, not a bug





[GLASSFISH-9162] [BLOCKING] could not access application after upgrade Created: 18/Aug/09  Updated: 01/Dec/10  Resolved: 11/Sep/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: v2.1.1
Fix Version/s: v2.1.1_dev

Type: Bug Priority: Critical
Reporter: 1xpert Assignee: rebeccas
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File server.log     Text File upgrade.log    
Issuezilla Id: 9,162

 Description   

OS: winxp
Type of upgrade: sidebyside between glassfish v2 b58g to glassfish v2.1.1 b28
Problem: Could not access application after upgrade

Steps to produce:
1) install glassfish v2, invoke ant -f setup-cluster.xml
2) start-domain domain1, setup new domain, setup cluster on the same machine,
create 2 instances
3) deploy application webapps-simple.war, ejb-stateless-converterApp.ear
4) stop all processes
5) install glassfish v2.1.1 on b28
6) invoke upgrade tool e.g. <v2.1.1 installation>\bin\asupgrade, give values at
the prompt
7) start-domain domain1, new domain, nodeagent using --syncinstances=true
8) verify applications deployed are accessible.

email me if you need machine login info to view this setup



 Comments   
Comment by 1xpert [ 18/Aug/09 ]

Created an attachment (id=3098)
instance1 log

Comment by 1xpert [ 18/Aug/09 ]

Created an attachment (id=3099)
upgrade log

Comment by jagadesh [ 24/Aug/09 ]

Need fix in v2.1.1.

Comment by rebeccas [ 24/Aug/09 ]

You should not run upgrade tool when you install a new version of GF 2.1x on top
of an existing one. Install the new version and start the app server, that is
all you need to do.

Comment by 1xpert [ 31/Aug/09 ]

Closing per Rebecca's comment
Reassign to Rebecca for closing since there's no option to close this bug.

Comment by 1xpert [ 31/Aug/09 ]

Wrote comment for wrong bug. Please dont close bug. I need to re-execute this on
winxp.

Comment by 1xpert [ 02/Sep/09 ]

Not a bug. Tried on build b30 and it passed without using upgrade tool.

Comment by Ed Bratt [ 11/Sep/09 ]

Per reporter, not a bug.





[GLASSFISH-9083] incorrect verion displayed in admin gui after upgrade Created: 10/Aug/09  Updated: 19/Feb/10  Resolved: 19/Feb/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: v2.1.1
Fix Version/s: V3

Type: Bug Priority: Major
Reporter: 1xpert Assignee: roisinflannery
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 9,083
Status Whiteboard:

v3_exclude


 Description   

After upgrade, login admin gui and notice appserver is incorrect on login page
and other web pages.

OS: suselinux
Steps to reproduce:

Install glassfishv1 9.0 (build b48)
Install glassfish v2.1.1 build 27 in a different directory
Execute <glassfish v2.1.1 installation>/bin/asupgrade -c
Give parameters at the prompt
After upgrade completed, start domain
Open web browser and enter at the browser http://<machine name>:4848, press enter
Notice that the display is incorrect where it says Sun Glassfish Enterprise
Server v2.1. It should be Sun Glassfish Enterprise Server v2.1.1. Incorrect
appserver version needs correction after login the admin gui succeesssfully



 Comments   
Comment by kumara [ 14/Sep/09 ]

Excluded from v3, Upgrade from v1 to v2, not to v3.

Comment by roisinflannery [ 19/Feb/10 ]

Reassigning to myself

Comment by roisinflannery [ 19/Feb/10 ]

Just tried to reproduce this issue and was unable - I think that this must have
already been fixed. On the login page it says v2.1.1 and after you log in it
also says v2.1.1 in the top left hand corner.

I used the following versions...

9.0 version:
deimos# ./asadmin version --verbose=true
Unable to communicate with admin server, getting version locally.
Version = Sun Java System Application Server Platform Edition 9.0_01 (build b02-p01)
Command version executed successfully.

2.1.1 version:
./asadmin version --verbose=true
Unable to communicate with admin server, getting version locally.
Version = Sun GlassFish Enterprise Server v2.1.1 ((v2.1 Patch06)(9.1_02
Patch12)) (build b31g-fcs)
Command version executed successfully.

Comment by roisinflannery [ 19/Feb/10 ]

Just tried to reproduce this issue and was unable - I think that this must have
already been fixed. On the login page it says v2.1.1 and after you log in it
also says v2.1.1 in the top left hand corner.

I used the following versions...

9.0 version:
deimos# ./asadmin version --verbose=true
Unable to communicate with admin server, getting version locally.
Version = Sun Java System Application Server Platform Edition 9.0_01 (build b02-p01)
Command version executed successfully.

2.1.1 version:
./asadmin version --verbose=true
Unable to communicate with admin server, getting version locally.
Version = Sun GlassFish Enterprise Server v2.1.1 ((v2.1 Patch06)(9.1_02
Patch12)) (build b31g-fcs)
Command version executed successfully.





[GLASSFISH-7466] asupgrade fails on UnsatisfiedLinkError with Java 6 Created: 29/Mar/09  Updated: 08/Oct/10  Resolved: 08/Oct/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: v2.1
Fix Version/s: v2.1.2

Type: Bug Priority: Major
Reporter: Alexis MP Assignee: rebeccas
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS X
Platform: Macintosh


Issuezilla Id: 7,466
Status Whiteboard:

3.1-exclude v3_exclude

Tags: 3_1-exclude

 Description   

% pwd
/Users/Foo/tmp/glassfish

% java -version
java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode)

% bin/asupgrade -c
Valid values for source and Target are as follows :

If upgrading from Sun Java System Application Server 8.x or 9.x, specify domain directory for Source.
The target directory should be the domains root.

Enter the Domain directory of the source: /Applications/glassfish2.1/domains/domain1
Enter the Target Domains Root: /Users/Foo/tmp/glassfish/domains
Enter the Admin User:admin
Enter the Admin Password: Exception in thread "main" java.lang.UnsatisfiedLinkError:
/Users/Foo/tmp/glassfish/lib/libcliutil.jnilib:
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1822)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1739)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1030)
at com.sun.enterprise.cli.framework.CliUtil.loadCliNative(CliUtil.java:73)
at com.sun.enterprise.cli.framework.CliUtil.<init>(CliUtil.java:59)
at com.sun.enterprise.tools.upgrade.cli.CLIParser.collectMissingArguments(CLIParser.java:303)
at com.sun.enterprise.tools.upgrade.common.ArgsParser.parse(ArgsParser.java:192)
at com.sun.enterprise.tools.upgrade.cli.CLIParser.<init>(CLIParser.java:76)
at com.sun.enterprise.tools.upgrade.UpgradeToolMain.startCLI(UpgradeToolMain.java:155)
at com.sun.enterprise.tools.upgrade.UpgradeToolMain.main(UpgradeToolMain.java:205)

Most likely due to using Java 6 which is 64-bit only...
Simply use Java 5 as the workaround.



 Comments   
Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by kumara [ 14/Sep/09 ]

Excluded from v3. The native library mentioned is no longer used in v3.

Comment by Nazrul [ 16/May/10 ]

Excluding from 3.1

Comment by Bobby Bissett [ 08/Oct/10 ]

Not an issue in upgrade tool.





[GLASSFISH-7301] [sailfin] sidebyside upgrade fails with error Transformation failed Created: 11/Mar/09  Updated: 08/Oct/10  Resolved: 08/Oct/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: v2.1
Fix Version/s: V3

Type: Improvement Priority: Major
Reporter: 1xpert Assignee: rebeccas
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 7,301
Tags: future-exclude

 Description   

Upgrade type: sidebyside-manual
OS: solaris sparc
Appserver versions: sailfin 1.0
(http://javaweb.sfbay.sun.com/java/re/sailfin/1.0/promoted/fcs_branch/b60g/bundles/)to
sailfin 2.0
(http://javaweb.sfbay.sun.com/java/re/sailfin/2.0//promoted/fcs/b05/bundles/)

Steps to reproduce:
1) install sailfin 1.0, choose developer profile
2) create 2nd domain, deploy ear,war to the domain, stop appserver
3) install sailfin 2.0, choose developer profile
4) invoke asupgrade from <sailfin2.0>/bin/asupgrade
5) got error Transformation Failed



 Comments   
Comment by rebeccas [ 12/Mar/09 ]

There is no upgrade tool for Sailfin 2.0 so this is not a bug. It is a REF. I
have changed the status to indicate such.

Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Bobby Bissett [ 08/Oct/10 ]

Issue does not apply to ongoing work.





[GLASSFISH-6871] got exception during upgrade glassfish v2 to 9.1.1 b60a Created: 03/Dec/08  Updated: 08/Oct/10  Resolved: 08/Oct/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: v2.1
Fix Version/s: V3

Type: Bug Priority: Minor
Reporter: 1xpert Assignee: rebeccas
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Attachments: Text File upgrade.log    
Issuezilla Id: 6,871
Tags: future-exclude

 Description   

Upgrade from glassfish v2 to 9.1.1 b60a on Linux 4.0

I get different exception during upgrade when I install 9.1.1 with developer
profile versus when I install 9.1.1 with cluster profile. Glassfish installation
is a developer profile however it went through cluster transformation via
command create-domain --profile after installation.

When install 9.1.1 with SIP settings as Cluster profile, I get exception
complain the source and target have different profiles e.g. source: developer
profile, target: cluster profile

When install 9.1.1 with SIP settings as Developer profile then I get the
following Cant find bundle for some base name. More details below:

/opt/sailfin/bin/asupgrade -c

Valid values for source and Target are as follows :

If upgrading from Sun Java System Application Server 8.x or 9.x, specify domain
directory for Source. The target directory should be the domains root.

Enter the Domain directory of the source:
/usr/nga/911/GF/glassfish/domains/sqe-domain
Enter the Target Domains Root: /opt/sailfin/domains
Enter the Admin User:admin
Enter the Admin Password:
Enter the Master password:
Upgraded domain will be created under cluster profile.
Starting Upgrade Harness
Executing command: create-domain --profile "cluster" --domaindir
"/opt/sailfin/domains" --adminport 4849 --user admin --passwordfile
"/tmp/ugpw27107.tmp" --savemasterpassword=true --instanceport 8090
--domainproperties
http.ssl.port=8081:orb.ssl.port=3830:orb.mutualauth.port=3930:jms.port=7676:orb.listener.port=59598:domain.jmxPort=8696
sqe-domain
An exception occured: Can't find bundle for base name
org.jvnet.glassfish.comms.admin.cli.extensions.commands.LocalStrings, locale en_US
An exception occured: Error while creating the domain: sqe-domain
Deleting Temporary password files

Steps:
install glassfish-installer-v2-b58g.jar
start domain1
check out appserver-sqe/bootstrap.xml, ant -f bootstrap.xml co-jms
set environment variables: JAVA_HOME, ANT_HOME, S1AS_HOME, SPS_HOME (point to
<location of cvs checkout of appserver-sqe>)
execute ant-setup-cluster-profile
deploy webapps-simple.war
stop all domains (domain1, sqe-domain, node-agent)
install 9.1.1 b60a in a different location. Choose "Developer" profile
invoke asupgrade binary



 Comments   
Comment by harpreet [ 03/Dec/08 ]

Can you attach the detailed exceptions

Comment by 1xpert [ 05/Dec/08 ]

Created an attachment (id=2130)
upgrade.log

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Bobby Bissett [ 08/Oct/10 ]

Issue does not apply to ongoing work.





[GLASSFISH-6638] Got exception during creating domain in sidebyside upgrade from v2 ur1 to 9.1.1 Created: 23/Oct/08  Updated: 01/Dec/10  Resolved: 30/Oct/08

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 9.1.1
Fix Version/s: 9.1.1_dev

Type: Bug Priority: Critical
Reporter: 1xpert Assignee: rebeccas
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File upgrade.log    
Issuezilla Id: 6,638
Status Whiteboard:

911Approved


 Description   

Upgrade from glassfish v2 ur1 to 9.1.1 promoted build b57 has problem creating
domain during upgrade process. See upgrade.log for more details

Steps to produce
1) install glassfish v2ur1 e.g. glassfish-installer-v2.1-b56-windows.jar from
http://glassfish.dev.java.net
2) deploy webapps-simple.war, ejb-stateless-converter.ear
3) create a new domain called sqe-domain
4) stop domain1, sqe-domain
5) install 9.1.1 b57 promoted build in a different location
6) invoke asupgrade



 Comments   
Comment by 1xpert [ 23/Oct/08 ]

Created an attachment (id=2014)
Log

Comment by 1xpert [ 23/Oct/08 ]

This happens on Windows 2008 ..Tested on Linux and do not see this issue.

Comment by harpreet [ 24/Oct/08 ]

Approved for v2.1

Comment by rebeccas [ 27/Oct/08 ]

I logged into the system. I was not able to reproduce the problem.
I upgraded glassfish/domains/sqe-domain to 911b57. I created
glassfish/domains/mep and upgrade it to 911b57. I moved
glassfish/domains/backup/domain1_*
to glassfish/domains/domain1 and upgraded it to 911b57.

Would you try the test again?

Comment by rebeccas [ 30/Oct/08 ]

Not reproducable.





[GLASSFISH-6265] glassfish v1 to glassfish v2.1 failed during upgrading JBI module Created: 23/Sep/08  Updated: 20/Oct/08  Resolved: 20/Oct/08

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 9.1.1
Fix Version/s: 9.1.1

Type: Bug Priority: Major
Reporter: 1xpert Assignee: rebeccas
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Attachments: Text File upgrade.log     Text File upgrade.log    
Issuezilla Id: 6,265
Status Whiteboard:

911Approved


 Description   

upgrade glassfish v1 to glassfish v2.1 failed for module JBI

Steps to reproduce on MAC OS:
1) install glassfish v1
2) start/stop domain, deploy an app, create a new domain, deploy an app on the new domain
3) stop domain, sqe-domain
4) install glassfish v2.1 in a new directory
5) invoke asupgrade in gui mode

see upgrade.log attached



 Comments   
Comment by 1xpert [ 23/Sep/08 ]

Created an attachment (id=1870)
upgrade.log

Comment by 1xpert [ 23/Sep/08 ]

Created an attachment (id=1871)
upgrade.log

Comment by 1xpert [ 24/Sep/08 ]

also happens for 8.2 to 9.1.1 upgrade

Comment by 1xpert [ 29/Sep/08 ]

Also fails on 8.0ur1 to 9.1.1, 8.1ur2 to 9.1.1, 9.0ur1 to 9.1.1 side by side upgrade

Comment by harpreet [ 02/Oct/08 ]

Marking it approved for v2.1.

Comment by harpreet [ 20/Oct/08 ]

Issue has been fixed by Rebecca - closing it.





[GLASSFISH-6170] says its is installed when it isn't Created: 19/Sep/08  Updated: 19/Sep/08  Resolved: 19/Sep/08

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Major
Reporter: vince kraemer Assignee: rebeccas
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: PC


Attachments: Text File output.txt    
Issuezilla Id: 6,170
Status Whiteboard:

gfv3-prelude-included


 Description   

I run the glassfishv3-prelude/bin/updatetool twice and it says it has
successfully installed twice... since it is just supposed to install once, it
seems like this behavior is a bug.

See the attached output



 Comments   
Comment by vince kraemer [ 19/Sep/08 ]

Created an attachment (id=1846)
the output

Comment by vince kraemer [ 19/Sep/08 ]

promoted build 25...

Comment by vince kraemer [ 19/Sep/08 ]

now it is working...

I must have done something stupid.

Comment by kumara [ 19/Sep/08 ]

v3 defect tracking





[GLASSFISH-5591] extend "asupgrade" to support migration to remote domains Created: 22/Aug/08  Updated: 10/Jan/11  Resolved: 10/Jan/11

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 9.1peur2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: kawazu Assignee: Tom Mueller
Resolution: Won't Fix Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5,591

 Description   

Following the tutorial of migrating domains between different glassfish
installations outlined in [1], I happen to see this in our environment quite
often having three types of system (dev, staging, production), on different hosts.

In such an environment, it would be desirable if asupgrade provided an option to
choose a remote domain rather than just a "target domains root directory" for
migrating the settings to, as this (in course of deploying different
glassfish/SJSAS installments across the three different hosts) would make things
somewhat easier.

[1]http://blogs.sun.com/alexismp/entry/i_m_moving_from_the



 Comments   
Comment by kawazu [ 22/Aug/08 ]
      • Issue 5591 has been confirmed by votes. ***
Comment by janey [ 06/Jan/11 ]

reassign to Tom.

Comment by janey [ 06/Jan/11 ]

reassign to Tom.

Comment by Tom Mueller [ 10/Jan/11 ]

Release 3.1 supports the backup/restore-domain commands which can be used to promote a domain from development to production. Modifying asupgrade to also support domain transfer would be taking the asupgrade design in contrary to the intent of asupgrade.

Marking as "won't fix".





[GLASSFISH-4340] V3 - Upgrade tool support for side-by-side upgrade Created: 29/Feb/08  Updated: 25/Nov/10  Resolved: 22/Sep/09

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: V3
Fix Version/s: V3

Type: New Feature Priority: Critical
Reporter: Snjezana Sevo-Zenzerovic Assignee: rebeccas
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-4328 V3 - Support side-by-side upgrade Resolved
Issuezilla Id: 4,340
Status Whiteboard:

v3-prd-item


 Description   

This is dependency feature for installer PRD item INST-3 covered in issue 4328.

Upgrade tool should support side-by-side upgrade from SJSAS 8.1, SJSAS 8.2,
GlassFish V1, GlassFish V2.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 29/Feb/08 ]

prd keyword

Comment by Snjezana Sevo-Zenzerovic [ 29/Feb/08 ]

Adjusting priority to match dependent installer feature.

Comment by Satish Kumar [ 12/May/08 ]

Reassigning bug to Rebecca who is the current owner of the Upgrade Tool...

Comment by Bobby Bissett [ 03/Sep/09 ]

Where are we on this issue? It was filed before I joined the upgrade team and I'm just now seeing it.
Upgrade tool is now more or less working in v3. Can we mark this as fixed?

Comment by Snjezana Sevo-Zenzerovic [ 03/Sep/09 ]

Eons ago we were told to file feature type issues for all v3 PRD items. As far
as I am concerned, you can definitely go ahead and mark it as fixed.

Comment by Bobby Bissett [ 22/Sep/09 ]

Thanks. Will finally get this closed. I think we're supporting upgrade in v3 now.





[GLASSFISH-4254] policy file not upgraded completely Created: 25/Feb/08  Updated: 08/Oct/10  Resolved: 08/Oct/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 9.1peur1
Fix Version/s: 9.2

Type: Improvement Priority: Major
Reporter: cchidamb Assignee: rebeccas
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 4,254
Status Whiteboard:

as911-na

Tags: future-exclude

 Description   

To follow up with our upgrade summit last week, I'm opening up an issue just to
keep track of the upgrade issues I've experienced on glassfish wiki upgrade.

login.conf file entries not getting upgraded.

Comments block in server.policy file need to be copied over to the target server.

Some entries in server.policy file is missing e.g. reference to our own keystore
file, and a couple of grant permission entries also. We've to test this scenario
correctly, and make our upgrade tool more robust to these type of test cases.



 Comments   
Comment by Satish Kumar [ 12/May/08 ]

Reassigning the bug to Rebecca who is the current owner of the Upgrade Tool...

Comment by harpreet [ 10/Jun/08 ]

Transferring comments is not critical for release. Marking issue for next release.

Comment by rebeccas [ 10/Sep/08 ]

This is an enhancement request.

Comment by Bobby Bissett [ 08/Oct/10 ]

Issue does not apply to ongoing work.





[GLASSFISH-3947] Update Center fails with proxy authentication Created: 27/Dec/07  Updated: 08/Feb/08  Resolved: 08/Feb/08

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 9.0peur1
Fix Version/s: 9.1.1

Type: Bug Priority: Major
Reporter: writtmeyer Assignee: rp100353
Resolution: Incomplete Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,947

 Description   

Using GF v2 UR1 the update center fails downloading the list of available updates.

Right after the UI was up for the first time I changed the proxy information in
the preferences tab. Clicking "Check for Updates" only resulted in a failure
message ("Download Failed"). When I tried to register to see whether this was a
download problem only I got the following message:

>> Unable to tunnel through proxy. Proxy returns "HTTP/1.0 407 Proxy
Authentication Required". <<

But all the necessary information in the preferences tab have been entered.



 Comments   
Comment by raccah [ 04/Jan/08 ]

Should probably be moved to updatecenter's issuetracker, but Rajeshwar can confirm.

Comment by rp100353 [ 08/Feb/08 ]

Moved this issue to Update Center issue tracker. UC issue number is
https://updatecenter.dev.java.net/issues/show_bug.cgi?id=349





[GLASSFISH-3764] <BT6614947>(sbs) 8.2 to 9.1ur1 upgrade: could not start nodeagent on 2nd machine Created: 11/Oct/07  Updated: 12/May/08  Resolved: 12/May/08

Status: Closed
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 9.1peur1
Fix Version/s: 9.1peur1

Type: Bug Priority: Major
Reporter: gfbugbridge Assignee: rebeccas
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,764

 Description   

*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6614947
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6614947
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description Sbs upgrade in cli mode 8.2 fcs to 9.1_01 b03 fcscould not start nodeagent on remote machine after modifying nodeagent.properties with correct jmx-port as noted in DAS's domain.xml
see bug attachments for logs

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to [3-Medium]not XXXXXX 2007-10-10 00:25:56 GMT

**********READ-ONLY Data from Bugtraq Ends********



 Comments   
Comment by Satish Kumar [ 12/May/08 ]

Reassigning bug to Rebecca who is the current owner of the Upgrade Tool...

Comment by rebeccas [ 12/May/08 ]

Fixed in FCS release

Comment by rebeccas [ 12/May/08 ]

fixed in fcs release





[GLASSFISH-3558] <BT6598297>[REGRESSION](PE to PE upgrade)got CLI128 Password for masterpassword must have 8 or more characters Created: 29/Aug/07  Updated: 12/May/08  Resolved: 12/May/08

Status: Closed
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 9.1pe
Fix Version/s: 9.1pe

Type: Bug Priority: Critical
Reporter: gfbugbridge Assignee: rebeccas
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,558

 Description   

*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6598297
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6598297
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description PE upgrade from 9.0 to 9.1 b58c. I got the following errors during upgrade:
bash-3.00# /opt/inplace3/bin/asupgrade -c

Valid values for source and Target are as follows :

If upgrading from Sun Java System Application Server 8.x or 9.0, specify
domain directory for Source. The target directory should be the domains
root.

Enter the Domain directory of the source: /opt/inplace3/domains/domain1
Enter the Target Domains Root: /opt/inplace3/domains
Enter the Admin User:admin
Enter the Admin Password:
Upgraded domain will be created under developer profile.
Starting Upgrade Harness
Executing command: create-domain --profile "developer" --domaindir
"/opt/inplace3/domains" --adminport 4444 --user admin --passwordfile
"/var/tmp/ugpw6041.tmp" --savemasterpassword=true --instanceport 8080
--domainproperties

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description it also happens for sbs. I guess this error takes place when you invoke upgrade tool manually (e.g. <install>/bin/asupgrade -c)
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description The error also shows up when I choose to launch upgrade tool from installer:

2. Start the Application Server by executing:
/opt/sbs2/bin/asadmin start-domain domain1

3. Start the Admin Console:
http://localhost:4848

Please press any key to launch upgrade tool.
In case there are any errors, invoke upgrade tool manually from <install-
dir>/bin after correcting the errors

{"!" exits}

Valid values for source and Target are as follows :

If upgrading from Sun Java System Application Server 8.x or 9.0, specify domain directory for Source. The target directory should be the domains root.

Enter the Domain directory of the source: /opt/sbs/domains/domain1
Enter the Admin User:admin
Enter the Admin Password:
Upgraded domain will be created under developer profile.
Starting Upgrade Harness
Existing domain in target domains root has been deleted.
Executing command: create-domain --profile "developer" --domaindir "/opt/sbs2/domains" --adminport 4848 --user admin --passwordfile "/var/tmp/ugpw55911.tmp" --savemasterpassword=true --instanceport 8090 --domainproperties http.ssl.port=8081:orb.ssl.port=3830:orb.mutualauth.port=3930:jms.port=7676:orb.listener.port=3700:domain.jmxPort=8696 domain1
An exception occured: Usage: create-domain [--user admin] [--adminport port_number] [--terse=false] [--echo=false] [--interactive=true] [--domaindir domain_directory] [--profile profile_name] [--template domain_template] [--passwordfile filename ] [--instanceport port_number] [--savemasterpassword=false] [--domainproperties (name=value)[:name=value]*] [--portbase portbase] [--savelogin=false] [--checkports=true] domain_name
CLI128 Password for masterpassword must have 8 or more characters.
An exception occured: Error while creating the domain: domain1
Deleting Temporary password files
Deleting temporary files...

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Evaluation internal masterpassword must be set to the appserver default passwd.
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to [3-Medium]not XXXXXX 2007-08-28 19:40:13 GMT

Priority changed from [3-Medium] to [2-High]
All the PE to PE upgrade failed due to this bug. Upgrade this bug to XXXXXX 2007-08-29 00:45:53 GMT

**********READ-ONLY Data from Bugtraq Ends********



 Comments   
Comment by Satish Kumar [ 12/May/08 ]

Reassigning bug to Rebecca who is the current owner of the Upgrade Tool...

Comment by rebeccas [ 12/May/08 ]

Issue resolved in bld b58g

Comment by rebeccas [ 12/May/08 ]

fixed in b58g





[GLASSFISH-3527] <BT6595656>AS91 b58b Solaris: can't migrate domain from AS8.2 ((problem with Broker on port 7676 in logs)) Created: 23/Aug/07  Updated: 10/Sep/08  Resolved: 10/Sep/08

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 9.1pe
Fix Version/s: 9.1pe

Type: Bug Priority: Blocker
Reporter: gfbugbridge Assignee: rebeccas
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,527

 Description   

*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6595656
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6595656
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description I have whole JES5 stack deployed on Solaris 10 sparc in SPARSE root zone.. I want to upgrade AS to AS9.1
I've installed new AS9.1 binaries via Installer.. (I've used b58b-rc3 solaris-sparc-ifr.zip)

Then I've tried to upgrade domain1 via asupgrade, I've triggered issue 6595298, so I replaced appserv-upgrade.jar, but still I'm not able to migrate domain1..

I see errors in server.log of badly migrated domain1, which doesn't want to start, like this:

  • - - - - - - - - - - - - - - - - - - - - - - - -
    [#|2007-08-22T02:17:47.941+0200|SEVERE|sun-appserver9.1|javax.enterprise.resource.resourceadapter|_ThreadID=10;_ThreadName=main;zipFil
    e (/usr/share/lib/imq/imqjmsra.rar) doesn't exist;_RequestID=748ded75-fa58-4dfd-a09b-b7cd65e558d2;|RAR7001 : Upgrading a MQ resource a
    dapter failed : zipFile (/usr/share/lib/imq/imqjmsra.rar) doesn't exist|#] <<< I really don't have it.

[#|2007-08-22T02:17:47.994+0200|INFO|sun-appserver9.1|javax.enterprise.resource.resourceadapter|_ThreadID=10;_ThreadName=main;|JMS Ser
vice Connection URL is :mq://jsc-zone-219:7676/|#]

[#|2007-08-22T02:17:48.052+0200|INFO|sun-appserver9.1|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=10;_ThreadName=main;|MQJMSRA_R
A1101: SJSMQ JMS Resource Adapter starting...|#]

[#|2007-08-22T02:17:48.509+0200|INFO|sun-appserver9.1|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=10;_ThreadName=main;|MQJMSRA_L
B1101: Looking for Broker Running at:localhost:7676|#]

[#|2007-08-22T02:17:48.820+0200|WARNING|sun-appserver9.1|javax.jms|_ThreadID=10;_ThreadName=main;_RequestID=748ded75-fa58-4dfd-a09b-b7
cd65e558d2;|[C4003]: Error occurred on connection creation [localhost:7676]. - cause: java.net.ConnectException: Connection refused|#]

[#|2007-08-22T02:17:49.964+0200|WARNING|sun-appserver9.1|javax.jms|_ThreadID=10;_ThreadName=main;_RequestID=748ded75-fa58-4dfd-a09b-b7
cd65e558d2;|[C4003]: Error occurred on connection creation [localhost:7676]. - cause: java.net.ConnectException: Connection refused|#]

... lot of Connection refuses on port 7676 ...

  • - - - - - - - - - - - - - - - - - - - - - - - -

then there are exceptions that it cannot start Message Queue, and that I should check password in temporary file (it is correct password in there)

Please see attached upgrade.log and server.log

Feel free to ask me about any additional info, you'd appreciate,
Thanks,
Ivan

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Evaluation MQ 4.1(the one not bundled with Java ES 5 U1), cannot be installed under Sparce zone. So ideally an MQ upgrade(from 3.7ur2 in JES5U1 to MQ 4.1 bundled along with AS 9.1 IFR) should have happened by two ways.1). Install MQ 4.1 standalone installer in GZ and upgrade 3.7.x to 4.1
OR
2). Install any one component of AS 9.1 IFR(select sample) in GZ that would also upgrade MQ 4.1 in GZ.

Submitter, please confirm that this is the case. If not then the error is due to missing MQ 4.1 specific files/packages.

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Evaluation Hi Sathyan,
yes, this is the case........

I've run setup in global zone and selected only Sample Applications, what caused Message Queue 4.1 got installed in global zone.

Then I rerun asupgrade in SPARSE zone and migration finished successfully.

Should I close the bug as not a defect ?

Cheers,
Ivan

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Evaluation thanks for verifying this. I am closing this bug. I am in the process of creating a new document covering installation scenarios in all zone types. This document content will be included/referred in our install guide.
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to [1-Very High]Cant' migrate XXXXXX 2007-08-22 00:40:49 GMT

**********READ-ONLY Data from Bugtraq Ends********



 Comments   
Comment by Satish Kumar [ 12/May/08 ]

Reassigning bug to Rebecca who is the current owner of the Upgrade Tool...

Comment by rebeccas [ 10/Sep/08 ]

Bug address. Mark bug to remove from unconf status.





[GLASSFISH-3498] <BT6591668>AS9.1 IFR b58, Linux: Search in Portal stops working after upgrade AS8.2(jes5) -> AS9.1 Created: 11/Aug/07  Updated: 12/May/08  Resolved: 12/May/08

Status: Closed
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 9.1pe
Fix Version/s: 9.1pe

Type: Bug Priority: Major
Reporter: gfbugbridge Assignee: rebeccas
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: All


Issuezilla Id: 3,498

 Description   

*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6591668
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6591668
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description I have whole JES5 deployed on Linux RHEL3, web container is Application Server 8.2.
I've upgraded AS, migrated domain1 and started. Now searching in Portal doesn't work.

There's something wrong with search robot.. When I try to search something searchable, I see it throws two exceptions to Robot's log file:

(/var/opt/sun/portal/searchservers/search1/logs/rdmserver.0.0.log):
---------------------------------------------------------------------------

[#|2007-08-10T15:48:14.649+0200|WARNING|SJS Portal Server|debug.com.sun.portal.search.rdmserver|ThreadID=28; ClassName=co
m.sun.portal.search.db.PartitionedDb; MethodName=exit; |PSSH_CSPSB0087 : Module: 1 - in db exit - bad dbenv count 0|#]

[#|2007-08-10T15:48:14.650+0200|WARNING|SJS Portal Server|debug.com.sun.portal.search.rdmserver|ThreadID=28; ClassName=co
m.sun.portal.search.rdmserver.DatabaseService; MethodName=getSearchResults; |PSSH_CSPSRDMS0019: Module:1 - Cannot access
database.
java.lang.NullPointerException
at com.sun.portal.search.db.PartitionedDb.housekeep(PartitionedDb.java:895)
at com.sun.portal.search.db.PartitionedDb.close(PartitionedDb.java:562)
at com.sun.portal.search.db.DbManager.getRootDbEntry(DbManager.java:87)
at com.sun.portal.search.db.DbManager.dbOpen(DbManager.java:119)
at com.sun.portal.search.rdmserver.DbAccess.writeStart(DbAccess.java:89)
at com.sun.portal.search.rdmserver.DbAccess.readStart(DbAccess.java:63)
at com.sun.portal.search.rdmserver.DatabaseService.getSearchResults(DatabaseService.java:484)
at com.sun.portal.search.rdmserver.DatabaseService.ql_search_service(DatabaseService.java:274)
at com.sun.portal.search.rdmserver.DatabaseService.service(DatabaseService.java:138)
at com.sun.portal.search.rdmserver.RDMServer.service(RDMServer.java:125)
at com.sun.portal.search.rdmserver.RDMServlet.processRDMRequest(RDMServlet.java:279)
at com.sun.portal.search.rdmserver.RDMServlet.doGet(RDMServlet.java:216)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:718)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
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:585)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:276)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:192)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:404)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:290)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:268)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:339)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:261)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:212)
at com.sun.enterprise.web.portunif.PortUnificationPipeline$PUTask.doTask(PortUnificationPipeline.java:361)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)

#]

[#|2007-08-10T15:48:14.652+0200|WARNING|SJS Portal Server|debug.com.sun.portal.search.rdmserver|ThreadID=28; ClassName=co
m.sun.portal.search.rdmserver.RDMServer; MethodName=service; |PSSH_CSPSRDMS0046: Module:1 - Exception: rdm-service.
java.lang.Exception: Cannot access database.
at com.sun.portal.search.rdmserver.DatabaseService.getSearchResults(DatabaseService.java:488)
at com.sun.portal.search.rdmserver.DatabaseService.ql_search_service(DatabaseService.java:274)
at com.sun.portal.search.rdmserver.DatabaseService.service(DatabaseService.java:138)
at com.sun.portal.search.rdmserver.RDMServer.service(RDMServer.java:125)
at com.sun.portal.search.rdmserver.RDMServlet.processRDMRequest(RDMServlet.java:279)
at com.sun.portal.search.rdmserver.RDMServlet.doGet(RDMServlet.java:216)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:718)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
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:585)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:276)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:192)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:404)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:290)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:268)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:339)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:261)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:212)
at com.sun.enterprise.web.portunif.PortUnificationPipeline$PUTask.doTask(PortUnificationPipeline.java:361)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)

#]

I've tried to restart Search Robot by running:
/var/opt/sun/portal/searchservers/search1/StopRobot
/var/opt/sun/portal/searchservers/search1/StartRobot

all seems ok, robot.log and rdmgr.0.0.log shows how it indexed my files and such.. but when I try to search in /portal, that nasty exeptions appears in rdmserver.0.0.log..

Please help.

btw: Login to PS works, PS looks healthy besides that search.

I'm attaching upgrade log and logs/ directory from search RoBoT, please let me know if you need more info,
Thanks,
Ivan

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description Hi Ivan,
If you upgrade to as9.1, portal also needs to be updated to jes5u1 level. Did you upgrade portal also for this test?

Thanks,
Mitesh

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description Hi Mitesh,
No I didn't upgrade portal.

Thanks,
Ivan

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to [1-Very High]Searching is XXXXXX 2007-08-10 16:41:05 GMT

Priority changed from [1-Very High] to [3-Medium]
Downgrading since this is not a XXXXXX 2007-08-10 21:24:10 GMT

**********READ-ONLY Data from Bugtraq Ends********



 Comments   
Comment by Satish Kumar [ 12/May/08 ]

Reassigning the bug to Rebecca who is the current owner of the Upgrade Tool...

Comment by rebeccas [ 12/May/08 ]

Issue resolved in b58g

Comment by rebeccas [ 12/May/08 ]

fixed in b58g





[GLASSFISH-3246] <BT6572307>AS9.1 Beta3 Win [usability] JES5 asupgrade.bat not gives clear reason for "unssuported upgrade path" Created: 22/Jun/07  Updated: 12/May/08  Resolved: 12/May/08

Status: Closed
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 9.1pe
Fix Version/s: 9.1pe

Type: Bug Priority: Major
Reporter: gfbugbridge Assignee: rebeccas
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,246

 Description   

*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6572307
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6572307
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description asupgrade.bat gives "unssuported upgrade path" for manual upgrade when AS9.1 is installed into alternate directory then AS8.x from JES5
In upgrade.log is:

"Upgrade not required from Enterprise Edition to a domain with developer profile"

JES5 don't have nodeagent configured, just domain1 when is instaled in "configure now" mode ?

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description Just would like to verify that you are doing a 8.x EE to 9.1 PE upgrade in which case this is not a supported feature in upgrade tool.
Could you provide the exact the bundle and config you are using for AS 9.1?

Thanks,

– Vella Raman

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Evaluation Hello Vella,
Yes, I this was the case, I was trying to migrate from 8.xEE to PE.

I thing in this case user must get clear reason in both PopUp Winodws and Upgrade Log, like

"Unssuported upgrade path, You can't update EE to PE"

Due this I chage it to P# and refrase Synopsys to:

[usability] JES5 asupgrade.bat not gives clear reason for "unssuported upgrade path"

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Evaluation This issue was fixed for CR# 6567287
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to [2-High]There need to be clear upgrade statement for AS8.x from JES5, when JES5 is instaled in configure now XXXXXX 2007-06-21 12:57:27 GMT

Priority changed from [2-High] to [3-Medium]
This is usability ussuse, not clear error XXXXXX 2007-06-22 12:25:25 GMT

**********READ-ONLY Data from Bugtraq Ends********



 Comments   
Comment by Satish Kumar [ 12/May/08 ]

Reassigning bug to Rebecca who is the current owner of the Upgrade Tool...

Comment by rebeccas [ 12/May/08 ]

Will not fix this. This is user error.

Comment by rebeccas [ 12/May/08 ]

won't fix





[GLASSFISH-3238] <BT6571534>PE->PE (sbs-installer) domain1 startup failure, deployment hang Created: 21/Jun/07  Updated: 12/May/08  Resolved: 12/May/08

Status: Closed
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 9.1pe
Fix Version/s: 9.1pe

Type: Bug Priority: Major
Reporter: gfbugbridge Assignee: rebeccas
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,238

 Description   

*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6571534
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6571534
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description After verifying *********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6571534
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6571534
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description After verifying bug 6541143, I tried to start domain and deploy an app. and could not proceed further

9.0->9.1 upgrade on WinXP: domain1 is not started in the background however output message shows it's running, list-domains shows domain is not running. See attached server.log, upgrade.log

8.2->9.1 upgrade: cause deployment to hang on Solar10sparc

Steps to reproduce:
GUI installation on WinXP
1)Install 9.0 PE fcs build in dir A
2)Install 9.1 PE beta3 b50c in dir B
3)Choose yes to upgrade, start upgrade wizard at the end of 9.1 installation
4)Complete upgrade and try to start domain

C:\>bug-sbs\bin\asadmin start-domain --user admin --passwordfile ./p.txt domain

Starting Domain domain1, please wait.
Log redirected to C:\bug-sbs\domains\domain1\logs\server.log.
Redirecting output to C:/bug-sbs/domains/domain1/logs/server.log
Domain domain1 is ready to receive client requests. Additional services are bei
g started in background.
Domain [domain1] is running [Sun Java System Application Server 9.1 (build b50c
beta3)] with its configuration and logs at: [C:\bug-sbs\domains].
Admin Console is available at http://localhost:4848.
Use the same port [4848] for "asadmin" commands.
User web applications are available at these URLs:
http://localhost:8080 https://localhost:8181.
Following web-contexts are available:
[/web1 /__wstx-services ].
Standard JMX Clients (like JConsole) can connect to JMXServiceURL:
[service:jmx:rmi:///jndi/rmi://easqesvr10:8686/jmxrmi] for domain management pu
poses.
Domain listens on at least following ports for connections:
[8080 8181 4848 3700 3820 3920 8686 ].
Domain does not support application server clusters and other standalone instan
es.

C:\>bug-sbs\bin\asadmin list-domains
domain1 not running
Command list-domains executed successfully.

------------------------------
B. Use same steps mentioned above except during upgrade enter incorrect password then re-enter correct password, upgrade was ok, server startup was ok, however deploy hangs after sbs upgrade

  1. /opt/bug-sbs/bin/asadmin deploy --user admin --passwordfile ./p.txt /export/91/appserver-sqe/common/admincli/apps/goodbye/assemble/goodbye-web.war

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to [2-High]not XXXXXX 2007-06-20 00:26:47 GMT

Priority changed from [2-High] to [3-Medium]
Downgrading to P3 since this is a Pe->PE XXXXXX 2007-06-21 20:45:01 GMT

Upgraded back to P2 since this is a XXXXXX 2007-06-21 21:46:31 GMT

**********READ-ONLY Data from Bugtraq Ends********, I tried to start domain and deploy an app. and could not proceed further

9.0->9.1 upgrade on WinXP: domain1 is not started in the background however output message shows it's running, list-domains shows domain is not running. See attached server.log, upgrade.log

8.2->9.1 upgrade: cause deployment to hang on Solar10sparc

Steps to reproduce:
GUI installation on WinXP
1)Install 9.0 PE fcs build in dir A
2)Install 9.1 PE beta3 b50c in dir B
3)Choose yes to upgrade, start upgrade wizard at the end of 9.1 installation
4)Complete upgrade and try to start domain

C:\>bug-sbs\bin\asadmin start-domain --user admin --passwordfile ./p.txt domain

Starting Domain domain1, please wait.
Log redirected to C:\bug-sbs\domains\domain1\logs\server.log.
Redirecting output to C:/bug-sbs/domains/domain1/logs/server.log
Domain domain1 is ready to receive client requests. Additional services are bei
g started in background.
Domain [domain1] is running [Sun Java System Application Server 9.1 (build b50c
beta3)] with its configuration and logs at: [C:\bug-sbs\domains].
Admin Console is available at http://localhost:4848.
Use the same port [4848] for "asadmin" commands.
User web applications are available at these URLs:
http://localhost:8080 https://localhost:8181.
Following web-contexts are available:
[/web1 /__wstx-services ].
Standard JMX Clients (like JConsole) can connect to JMXServiceURL:
[service:jmx:rmi:///jndi/rmi://easqesvr10:8686/jmxrmi] for domain management pu
poses.
Domain listens on at least following ports for connections:
[8080 8181 4848 3700 3820 3920 8686 ].
Domain does not support application server clusters and other standalone instan
es.

C:\>bug-sbs\bin\asadmin list-domains
domain1 not running
Command list-domains executed successfully.

------------------------------
B. Use same steps mentioned above except during upgrade enter incorrect password then re-enter correct password, upgrade was ok, server startup was ok, however deploy hangs after sbs upgrade

  1. /opt/bug-sbs/bin/asadmin deploy --user admin --passwordfile ./p.txt /export/91/appserver-sqe/common/admincli/apps/goodbye/assemble/goodbye-web.war

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to [2-High]not XXXXXX 2007-06-20 00:26:47 GMT

Priority changed from [2-High] to [3-Medium]
Downgrading to P3 since this is a Pe->PE XXXXXX 2007-06-21 20:45:01 GMT

Upgraded back to P2 since this is a XXXXXX 2007-06-21 21:46:31 GMT

**********READ-ONLY Data from Bugtraq Ends********



 Comments   
Comment by Satish Kumar [ 12/May/08 ]

Reassigning bug to Rebecca who is the current owner of the Upgrade Tool...

Comment by rebeccas [ 12/May/08 ]

Issue resolved in bld b58g.

Comment by rebeccas [ 12/May/08 ]

fixed inf b58g





[GLASSFISH-3232] <BT6571041>[REGRESSION]:Upgrade:PE->PE:unable to access to Admin GUI domain1 after upgrade Created: 20/Jun/07  Updated: 26/Jun/07  Resolved: 26/Jun/07

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 9.1pe
Fix Version/s: 9.1pe

Type: Bug Priority: Critical
Reporter: gfbugbridge Assignee: Satish Kumar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: