<< Back to previous view

[GLASSFISH-16667] [RN]Invoking GF installer on AIX6.1 with JDK6 64 bit gives Warning Created: 17/May/11  Updated: 18/Jan/12

Status: Open
Project: glassfish
Component/s: installation
Affects Version/s: 3.1.1_b05
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Alex Pineda Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

IBM PPC with AIX 6.1 OS, JDK6 64bit, Glassfish build 5.


Tags: 3_1-next_release-note-added 3_1-next_release-notes 3_1_1-scrubbed 3_1_2-exclude
Participants: Alex Pineda, Paul Davies, Rebecca Parks, Romain Grécourt and scatari

 Description   

On this system, JAVA_HOME=/usr/java6_64 which points to the 64bit version of the IBM JDK. When the installer is invoked, the following warning is displayed on the screen.

Warning: Could not detect OS Architecture, falling back to os.arch [Architecture=ppc64]

It's pretty visible and could cause customer calls.



 Comments   
Comment by Alex Pineda [ 17/May/11 02:56 PM ]

The same Warning is displayed when execution "uninstall.sh".

Comment by scatari [ 18/May/11 04:21 PM ]

This would require an update to "OpenInstaller" framework that is very risky to attempt at this stage of the release. Marking it for 3_1-next, this warning is harmless, we could potentially document this in Release Notes.

Comment by scatari [ 05/Jul/11 01:12 AM ]

Adding to the 3.1.1 release note queue.

Comment by Rebecca Parks [ 07/Jul/11 08:26 PM ]

Added the following to the 3.1.1 Release Notes:

Invoking GF installer on AIX 6.1 with JDK6 64 bit gives Warning (16667)

Description

When the GlassFish Server installer is invoked on the AIX 6.1 platform with the 64-bit version of JDK 6, the following warning is displayed on the screen:

Warning: Could not detect OS Architecture, falling back to os.arch [Architecture=ppc64]

Workaround

None. This warning is harmless and can be ignored.

Comment by Paul Davies [ 27/Oct/11 01:32 AM ]

This issue really is an installation issue for which a workaround has been added to the Release Notes. To enable this issue to be tracked for possibly fixing in a future release, I have changed the subcomponent to installation.

Comment by scatari [ 27/Oct/11 04:26 AM ]

We should try to fix this in 3.1.2. I will work with Romain to fix OpenInstaller.





[GLASSFISH-17399] (OI) layout issue with glassfish installer Created: 10/Oct/11  Updated: 06/Mar/12

Status: Reopened
Project: glassfish
Component/s: installation
Affects Version/s: 3.1.2
Fix Version/s: future release

Type: Bug Priority: Critical
Reporter: gmurr Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GLASSFISH-18331 The input fields does not displayed c... Closed
Tags: 3_1_2-exclude
Participants: gmurr, Joe Di Pol, Romain Grécourt and Snjezana Sevo-Zenzerovic

 Description   

The installer has layout issues. The EN messages contain line break at a particular position to break to a new line because the layout component do not resize according to the text width. Sine the translated messages will have the line break at a different position, the text in the localized installer UIs are truncated. We manually fixed this issue in 3.1.1. it is a very tedious process for new releases. We would like this issue to be fixed in 3.1.2 because new translations will be done for this release.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 28/Nov/11 11:01 PM ]

Assigning to Romain, fix is required in Open Installer.

Comment by Romain Grécourt [ 09/Jan/12 10:38 AM ]

The behavior is now the following:

  • ui_*.prefs are now using paragraphs (<p>...</p>). I hope this will reduce the pain to figure out the correct linebreaks for each langage. For next release we can plan to move the paragraph declarations directly to openinstaller so .prefs files would be more readable.

Changes were checked-in with revision #51948. Fixed installers can be downloaded from hudson job (http://gf-hudson.us.oracle.com/hudson/job/gf-3.1.2-build-nightly/156/artifact/bundles/) or you can wait for promoted build #17 and download installers from http://dlc.sun.com.edgesuite.net/glassfish/3.1.2/promoted/.

Comment by Romain Grécourt [ 13/Jan/12 04:40 PM ]

re-open as the changes relied on OpenInstaller 0.9.5.5. (integration in 3.1.2 was reverted).

Comment by Joe Di Pol [ 17/Jan/12 11:35 PM ]

Due to issues with OI integration we won't be able to fix this in 3.1.2. Excluding from that release.





[GLASSFISH-19314] Update jar license: phase 1 Created: 10/Nov/12  Updated: 18/Apr/13

Status: Open
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b60
Fix Version/s: 4.0.1

Type: Bug Priority: Critical
Reporter: Joe Di Pol Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: 0 minutes
Time Spent: 15 minutes
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-19315 Update jar license: phase 2 Open
Tags:
Participants: Joe Di Pol and Romain Grécourt

 Description   

See phase 1 described here:

http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Copyrights+and+Licenses+for+Jar+Files






[GLASSFISH-19425] Nucleus build Created: 10/Dec/12  Updated: 05/Mar/13

Status: Open
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b74
Fix Version/s: 4.0.1

Type: Improvement Priority: Critical
Reporter: Nazrul Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Joe Di Pol, Nazrul and Romain Grécourt

 Description   

We will need to setup Nucleus and GlassFish build such that...
1) We need to be able to branch nucleus source to address concurrent development of multiple releases
2) We need to have a system for versioning nucleus that is both sane and accommodates the limitations of maven versioning
3) We need to re-work the automated builds so that they are flexible and can accommodate building multiple nucleus based distributions

Romain has a proposal for this and working on the issue. So, assigning to him.



 Comments   
Comment by Joe Di Pol [ 05/Mar/13 11:00 PM ]

We likely won't change the GF4 build over to the nucleus pipeline until after Java EE 7 RI/SDK ship, so re-targeting this to 4.0.1





[GLASSFISH-20427] [regression] A distribution's dependencies are not optional Created: 29/Apr/13  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0.1

Type: Bug Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: Romain Grécourt
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-19770 create feature-set pom to contain pac... Open
Tags: 4_0_1-review
Participants: michael.y.chen, Romain Grécourt and Sanjeeb Sahoo

 Description   

See GLASSFISH-17170 where in we had marked all the dependencies of a distribution optional so that one could use a distribution without having to pull in all its dependencies. It seems changes trunk has reverted that fix. Pl fix it for 4.0.



 Comments   
Comment by Romain Grécourt [ 29/Apr/13 02:19 PM ]

I prefer to use intermediate poms, in order to cut the graph at distribution level, but still have a visible graph for inheritance between distributions.
I'm not sure to address that in 4.0

Comment by Romain Grécourt [ 02/May/13 04:04 PM ]

will fix it for 4.0.1

Comment by Sanjeeb Sahoo [ 02/May/13 04:56 PM ]

This should be fixed in 4.0.

Comment by Romain Grécourt [ 06/May/13 04:10 PM ]

Michael, please evaluate. I can come up with a fix for 4.0 if needed.

Comment by michael.y.chen [ 07/May/13 04:02 PM ]

This is a bug, but I don't consider it showstopper.

  • How likely is it that a customer will hit the bug?

Not very likely. This bug is only encountered by maven users consuming glassfish.zip as a maven dependency in their project. It does not impact our download bundles.

  • How severe is the customer impact?

Low. There is no loss of data or functionality. It is annoying that all dependencies are downloaded by maven, but functionally things work.

Is this a regression? Yes, the 3.X glassfish.zip artifact does not have this behavior. But I still claim that customer impact is not severe enough to warrant it being a showstopper.





[GLASSFISH-5744] asadmin list-containers should list the spec version of the container Created: 29/Aug/08  Updated: 28/Jun/13

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: V3
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: abien Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: other
Platform: All


Issuezilla Id: 5,744
Tags:
Participants: abien, km, Romain Grécourt, Sanjeeb Sahoo and Tom Mueller

 Description   

The output of the command asadmin list-containers looks like that in GF 3b20

Container : jpa
properties=(ContractProvider=jpa)
Container : web
properties=(ContractProvider=web)
Container : security
properties=(ContractProvider=security
Container : jruby
properties=(ContractProvider=jruby)

GF 3 is OSGI based, so potentially more than one container could be active at
the same time or activated / deactivated at runtime. There for the spec-version
should be visible in the listing. Otherwise it is hard for real world projects
to rely on certain functionality and e.g. file bugs.

The command should list something like:

Container : jpa [2.0]
properties=(ContractProvider=jpa)



 Comments   
Comment by km [ 08/May/09 12:22 PM ]

Sahoo, the ModuleDefinition currently does not have getSpecVersion and the
MANIFEST.MF does not have Specification-Version attribute. We need to get this
information.

I am assigning this to you so you can decide and update the API so I can call it
from list-containers. Assign it to me when you are done.

Comment by km [ 27/May/09 11:16 AM ]

The right sahoo.

Comment by Tom Mueller [ 25/Jan/11 11:48 AM ]

Cleared the Fix version field since this issue isn't going to be fixed in V3.

Comment by Sanjeeb Sahoo [ 23/Mar/11 01:45 PM ]

It seems like admin folks have to work with build team to have additional metadata in the runtime to provide such information.





[GLASSFISH-13574] asadmin command to tell you where a running Glassfish thinks Java is Created: 22/Sep/10  Updated: 28/Jun/13

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: ljnelson Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 13,574
Tags:
Participants: ljnelson, Romain Grécourt and Tom Mueller

 Description   

It would be nice to type something like

asadmin java

...and have it return the path to the java executable that Glassfish is running
under. Obviously there are many other ways to accomplish this, but for
debugging the (undocumented, required on Windows) manual setting of AS_JAVA in
config\asenv.bat, it would be most helpful. It would also be helpful in blind
installs, i.e. those conducted by a knowledgeable Glassfish person over instant
message with a non-Glassfish-knowledgable operator.



 Comments   
Comment by Tom Mueller [ 22/Sep/10 11:33 AM ]

This doesn't do exactly what is requested, but:

asadmin version --verbose

prints the version of Java that is being used. There is a --local and non-local
version of this so you can get the Java version for both asadmin and for the DAS.

Maybe the path to Java could be added to that if it is available.

Comment by Tom Mueller [ 05/Apr/11 01:10 PM ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-15522] (OI) There are truncation in the left of the install page in es locale Created: 11/Jan/11  Updated: 15/Feb/13

Status: Reopened
Project: glassfish
Component/s: installation
Affects Version/s: 3.1_b35
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: sunny-gui Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Server OS:RHEL 5
Bundle: java_ee_sdk-6u2-b35-jdk-linux-x64-ml.sh


File Attachments: JPEG File truncat_es_install.jpg     JPEG File truncat_install_it.jpg     JPEG File truncat_install_pt.jpg     JPEG File truncat_uninstall_pt.jpg     JPEG File UPDATED_ES_PACKED.jpg     JPEG File UPDATED_FR_PACKED.jpg     JPEG File UPDATED_US_PACKED_EXTREME.jpg    
Tags: 3_1-next 3_1_1-scrubbed 3_1_2-exclude
Participants: Joe Di Pol, Romain Grécourt, scatari, Snjezana Sevo-Zenzerovic and sunny-gui

 Description   

There are truncation in the left of the install page in es locale

Launch the installer program, the installer UI will be displayed. There are truncation in the left of the install page. Please see screen shot for your reference.



 Comments   
Comment by sunny-gui [ 11/Jan/11 12:45 AM ]

This issue also happens in pt_BR, it and fr locales. Please see attached screen shots for this.

Comment by scatari [ 11/Jan/11 11:15 AM ]

This is a known limitation with OpenInstaller framework and fixing it would require changes in OI code base. In fact this issue also applies to "en" locales. Alternatively one could always look at the text/panel header on the right top of this whole screen to find out where they are in the sequence. I am marking this for further evaluation in 3.2 as it does not affect any of installer's functionality.

Comment by scatari [ 17/May/11 08:52 AM ]

Approved for 3.1.1.

Comment by scatari [ 24/May/11 12:26 PM ]

Too late to fix for 3.1.1.

Comment by scatari [ 13/Oct/11 11:08 PM ]

To be considered for 3.1.2.

Comment by Snjezana Sevo-Zenzerovic [ 28/Nov/11 11:05 PM ]

Assigning to Romain, fix required in Open Installer.

Comment by Romain Grécourt [ 09/Jan/12 10:27 AM ]

Fixed with revision #51948. Fixed installers can be downloaded from hudson job (http://gf-hudson.us.oracle.com/hudson/job/gf-3.1.2-build-nightly/156/artifact/bundles/) or you can wait for promoted build #17 and download installers from http://dlc.sun.com.edgesuite.net/glassfish/3.1.2/promoted/.

Comment by Romain Grécourt [ 09/Jan/12 10:28 AM ]

Attaching screenshots to show how it looks now.

Comment by Romain Grécourt [ 13/Jan/12 04:41 PM ]

re-open as the changes relied on OpenInstaller 0.9.5.5. (integration in 3.1.2 was reverted).

Comment by Joe Di Pol [ 18/Jan/12 12:20 AM ]

Excluding bug from 3.1.2 since OI integration had to be rolled back.

Comment by Snjezana Sevo-Zenzerovic [ 15/Feb/13 03:57 PM ]

Moving to future release due to issues with OI codebase and integration.





[GLASSFISH-19651] Include the svn revision(s) in the Version class Created: 07/Feb/13  Updated: 28/Jun/13

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-18582 add information about version source ... Open
is related to GLASSFISH-18525 No profile info in asadmin version ou... Open
Tags:
Participants: Romain Grécourt

 Description   

1)

We should include the svn revision in the Version.class in order to not waste time figuring what was the revision used to produce a build.

This is possible with svn:keyword, see http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.keywords.html

See GlassFish version output

bin/asadmin version
Version = GlassFish Server Open Source Edition  4.0  (build romano-private)
Command version executed successfully.

See svn version output

svn, version 1.6.17 (r1128011)
   compiled Feb  1 2012, 15:04:34

2)
Note that since Nucleus and GlassFish are now distinct projects, GlassFish version might differ from nucleus.
Moreover, Nucleus and GlassFish might someday be in different svn repositories, hence the version command should report two revisions.

How about using HK2 to use more than one Version Class at a time ?

[Local Server]
Location          = /opt/glassfish4/glassfish/lib/client
Nucleus Version   = 4.0  (build 74 - r59854 - 02/10/2012)
GlassFish Version = 4.0  (build 74 - r59854 - 02/10/2012)

[Remote Server]
Location          = localhost:4848
Nucleus Version   = 4.0  (build 74 - r59854 - 02/10/2012)
GlassFish Version = 4.0  (build 74 - r59854 - 02/10/2012)

Also, how about doing separate version for the Command Line, instead of doing Local and Remote ?

[Command Line Client]
Location          = /opt/glassfish4/glassfish/lib/client
Version           = 4.0  (build 74 - r59854 - 02/10/2012)

[Remote Server]
Location          = localhost:4848
Nucleus Version   = 4.0  (build 74 - r59854 - 02/10/2012)
GlassFish Version = 4.0  (build 74 - r59854 - 02/10/2012)





[GLASSFISH-16948] Installer should check for environment (OS, network, etc...) Created: 04/Jul/11  Updated: 08/Dec/11

Status: Open
Project: glassfish
Component/s: installation
Affects Version/s: 3.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Alexis MP Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_2-exclude
Participants: Alexis MP, Romain Grécourt and scatari

 Description   

The installer should warn the user when a non-supported environment (OS/JVM) is used.
It should also check for multicast to be enabled on the machine (probably harder to validate that it is available on the entire network).



 Comments   
Comment by scatari [ 31/Oct/11 06:15 PM ]

Check for multicast becomes irrelevant in 3.1.2 as we have plans to support non-multicast environments also. The other checks should be done and if possible to be extended to performing validation such as required service pack, administration privileges(on windows) etc.,





[GLASSFISH-17004] firefox 5.0 : few icons in the promotion page doesn't display Created: 08/Jul/11  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: other
Affects Version/s: 3.1.1
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: shaline Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: windows 2008 server
Browser : FireFox 5.0


File Attachments: JPEG File ff5-winxp-aix.JPG     JPEG File ff5.jpg     JPEG File mac-ff5.jpg    
Tags: 3_1_1-scrubbed 3_1_2-exclude
Participants: Anissa Lam, Joe Di Pol, lidiam, Romain Grécourt, scatari, shaline and Tom Mueller

 Description   

GF 3.1.1 promoted build 10.

In the common tasks window right bottom frame, the icons for facebook, twitter, youtube etc under "Stay Connected" section are not displayed in firefox 5.0 browser. This is visible in IE, and ff 3.6.
Attached the screen shot for the common tasks window.



 Comments   
Comment by Anissa Lam [ 08/Jul/11 10:51 PM ]

Does this always reproducible ?
It shows up correctly for me on Firefox 5 on my Mac. (see attached mac-ff5.jpg

If you use your browser and go to "http://java.sun.com/glassfish/productmsg.html" directly, does it show up ?

This is not from GUI and there is nothing i can do if it doesn't show up.

Comment by Anissa Lam [ 08/Jul/11 11:46 PM ]

Jason mentioned that he is seeing the problem on FF5. No error in server.log nor firebug console.
I am running 5.0 on my Mac, I cleared cache and restart browser, it works for me though.

Transferring to John since he owns this promotion page.

Comment by lidiam [ 09/Jul/11 02:04 AM ]

I can see the icons fine on FF5 on Windows XP with build ogs-3.1.1-b11-07_07_2011-aix.zip (on AIX).

Comment by lidiam [ 09/Jul/11 02:07 AM ]

Icons displayed in FF5 on Windows XP, Glassfish on AIX.

Comment by shaline [ 12/Jul/11 07:14 PM ]

On the promoted b11, the issue still exists on windows 2008 server. The links like "http://java.sun.com/glassfish/productmsg.html when directly accessed works fine , but the icons in the bottom promotion page are not displayed, in the Common Tasks window.

Comment by scatari [ 02/Nov/11 10:36 PM ]

Look into to see if this is a browser/os specific issue.

Comment by scatari [ 18/Jan/12 10:12 PM ]

Romaine, Could you please look at this issue?

Comment by Joe Di Pol [ 21/Jan/12 12:30 AM ]

Another data point: I tried Firefox 9.0.1 on Windows Server 2008 with a 3.1.2 build and the icons showed up fine.

Comment by Tom Mueller [ 06/Mar/12 09:55 PM ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-17269] Custom Installation crashed when "Configure an existing installation" Created: 02/Sep/11  Updated: 06/Mar/12

Status: Reopened
Project: glassfish
Component/s: installation
Affects Version/s: 3.1.1_b12
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: li.wu Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Bundle: ogs-3.1.1-b12-unix-ml.sh and glassfish-3.1.1-b12-unix-ml.sh
OS: OEL5 x64
locale: en_US


File Attachments: File install_crash_screenshot.rar    
Tags: 3_1_2-release-note-added 3_1_2-release-notes
Participants: Joe Di Pol, li.wu, Rebecca Parks, Romain Grécourt and scatari

 Description   

1. Install the bundle;
2. Choose "Custom Installation" in Installation Type page and then Next;
3. Choose "Install Only" in Installation page and then Next;
4. Click Back in Install Directory page;
5. Choose "Configure an existing installation" in Installation page and Next;
6. Click Next in Install Directory page and then GUI window disappears. Installation crashes.



 Comments   
Comment by scatari [ 13/Oct/11 11:04 PM ]

This is not reproducible with 3.1.1 FCS build, closing.

Comment by li.wu [ 17/Oct/11 08:14 AM ]

This issue occurs in glassfish3.1.2_b05.
Bundle: glassfish-3.1.2-b05-windows-ml.exe
OS: windows7

Please check the pictures attached.
On step2.jpg choose Custom Installation and click Next;
On step3.jpg choose Install Only and click Next;
On step4.jpg click BACK;
On step5.jpg choose Configure an existing installation and click Next;
On step6.jpg click Next. And then Installation GUI exits.

Comment by scatari [ 17/Oct/11 06:42 PM ]

Romain,
Please take a look at this. Send me an email if you need access to a windows m/c.

Thanks

Comment by Romain Grécourt [ 19/Oct/11 04:31 PM ]

I've been able to reproduce the bug with Windows XP SP3.
I could not reproduce the bug on step6 as the installer complained that no GlassFish installation was found under C:\glassfish3.

However, if you go in the "configure an existing installation" panel, and then go back to the "custom installation" panel and try to hit the button "next" of the "install only" panel, the installer will crash.

Comment by Romain Grécourt [ 14/Dec/11 06:55 PM ]

I also reproduced the issue on Linux and Solaris, so this issue is not platform dependent.

Comment by Romain Grécourt [ 09/Jan/12 10:26 AM ]

Fixed with revision #51948. Fixed installers can be downloaded from hudson job (http://gf-hudson.us.oracle.com/hudson/job/gf-3.1.2-build-nightly/156/artifact/bundles/) or you can wait for promoted build #17 and download installers from http://dlc.sun.com.edgesuite.net/glassfish/3.1.2/promoted/.

Comment by li.wu [ 08/Feb/12 02:46 AM ]

This issue reproduces in 3.1.2_b20 for bundle ogs-3.1.2-b20-windows-ml.exe.
I downloaded the bundle from http://javaweb.us.oracle.com/java/re/glassfish/3.1.2/promoted/b20/archive/bundles/

Comment by Joe Di Pol [ 08/Feb/12 09:22 PM ]

I was able to reproduce this using B21 on Solaris 11. The key seems to be going into "Install Only" and then Backing out before choosing "Configure an existing installation". Since this is likely not a common path, this is probably not a 3.1.2 stopper, but we may want to put something in the release notes. I'm tagging for release notes.

The work around is to go directly into "Configure an existing installation" and not into one of the other options first.

Comment by Rebecca Parks [ 09/Feb/12 06:14 PM ]

Added to 3.1.2 Release Notes:

Description

GlassFish Server installation crashes if you perform these steps:

1. Select Custom Installation on the Installation Type page and then Next.
2. Select Install Only on the Installation page and then Next.
3. Select Back on the Install Directory page.
4. Select Configure an Existing Installation on the Installation page and Next.
5. Select Next on the Install Directory page.

Workaround

To configure an existing installation, go directly to this option without selecting a different option first.





[GLASSFISH-17713] Registration screen does not get launched after installation Created: 11/Nov/11  Updated: 05/Apr/12

Status: Reopened
Project: glassfish
Component/s: installation
Affects Version/s: 3.1.2_b09
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Alex Pineda Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

System is running Oracle Enterprise Linux 6-64bit OS, browser is Firefox 3.6, Glassfish 3.1.2 build9. Installation is being done as "hudson" user (non-root).


Tags: 3_1_2-exclude glassfish installer
Participants: Alex Pineda, Joe Di Pol, Romain Grécourt and scatari

 Description   

After installing GF 3.1.2 build 9 on my OEL6-x86_64 system, the Registration page does not get launched in a browser window. In addition, during the installation if I select any of the links on the Install screens, none of the link pages are displayed.

Be aware that my system OEL6 installation is new and perhaps is not configured properly for browser launch, however, when I installed JavaSE, the Registration page for the JDK6 was launched and accessible.

Let me know if you need access to the system.



 Comments   
Comment by scatari [ 06/Dec/11 11:48 PM ]

Alex,
Please give access to this machine to Romain.
Romain, please evaluate the fix for 3.1.2.

Comment by Romain Grécourt [ 13/Dec/11 06:53 PM ]

I've been able to reproduce the issue on both OEL6 and Ubuntu 11.04. Links are not clickable, and no browser is launched after having clicked on the "exit" button at the end of the installation. Nevertheless everything is fine on windows (xp).

Comment by Romain Grécourt [ 20/Dec/11 07:03 PM ]

I guess you are running Gnome. Openinstaller uses "GNOME_DESKTOP_SESSION_ID" to detect Gnome as the runing desktop environment. However this is deprecated since version 2.23.4.1.

Comment by Romain Grécourt [ 09/Jan/12 10:29 AM ]

Fixed with revision #51948. Fixed installers can be downloaded from hudson job (http://gf-hudson.us.oracle.com/hudson/job/gf-3.1.2-build-nightly/156/artifact/bundles/) or you can wait for promoted build #17 and download installers from http://dlc.sun.com.edgesuite.net/glassfish/3.1.2/promoted/.

Comment by Romain Grécourt [ 13/Jan/12 04:41 PM ]

re-open as some of the changes relied on OpenInstaller 0.9.5.5. (integration in 3.1.2 was reverted).
Registration screen will work, but Installer links will not be click-able.

Comment by Joe Di Pol [ 18/Jan/12 12:21 AM ]

Excluding from 3.1.2 since OI integration had to be rolled back.





[GLASSFISH-18340] consolidate packager/nucleus-corba-base module with packager/nucleus-common Created: 08/Feb/12  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: 4.0
Fix Version/s: None

Type: Task Priority: Major
Reporter: Cheng Fang Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-17489 Remove glassfish-naming from nucleus ... Resolved
Tags: nucleus-cleanup
Participants: Cheng Fang and Romain Grécourt

 Description   

Now that glassfish-naming module and its corba dependency have been removed from nucleus, packager/nucleus-corba-base is no longer related to corba. It now handles the packaging of pfl-*.jars. From the discussion with Tom Mueller, we may want to merge the remaining logic in nucleus-corba-base into nucleus-common and remove nucleus-corba-base module.

As of now, the following files reference nucleus-corba-base:
./distributions/nucleus/pom.xml
./packager/nucleus-common/build.xml
./packager/nucleus-common/pom.xml
./packager/nucleus-corba-base/build.xml
./packager/nucleus-corba-base/pom.xml
./packager/pom.xml






[GLASSFISH-18582] add information about version source to version command Created: 30/Mar/12  Updated: 28/Jun/13

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 4.0
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Tom Mueller Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-19651 Include the svn revision(s) in the Ve... Open
Tags: ee7ri_cleanup_deferred
Participants: Romain Grécourt and Tom Mueller

 Description   

A request from Lidia M.:
Could we have the information about what the version command refers to be part of the output? E.g. could we add a line saying something like "Using remotely retrieved version string". It would make things clear to new users and be consistent with the local output.

And from Joe D.:
One option that adds even more information is to have the first line be: "Server version for host.us.oracle.com:4848" and "Local version for /opt/glassfish3/glassfish". This reinforces the exact source of the version information.



 Comments   
Comment by Tom Mueller [ 17/Oct/12 08:19 PM ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-18615] [packager changes] Separate reosurces component from jca component Created: 11/Apr/12  Updated: 11/Apr/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-18614 Separate reosurces component from jca... Open
Tags:
Participants: Jagadish and Romain Grécourt

 Description   

Please refer the issues
GLASSFISH-18614 and GLASSFISH-17657
A new packager module for "resources" (appserver/resources) need to be created.






[GLASSFISH-19315] Update jar license: phase 2 Created: 10/Nov/12  Updated: 01/Apr/13

Status: Open
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b60
Fix Version/s: 4.0.1

Type: Bug Priority: Major
Reporter: Joe Di Pol Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-19314 Update jar license: phase 1 Open
Tags:
Participants: Joe Di Pol and Romain Grécourt

 Description   

See phase 2 described here:

http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Copyrights+and+Licenses+for+Jar+Files

This can be tackled after Java EE 7 RI/SDK






[GLASSFISH-19770] create feature-set pom to contain packager dependencies Created: 05/Mar/13  Updated: 29/Apr/13

Status: Open
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b78
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: 4 hours
Time Spent: Not Specified
Original Estimate: 4 hours

Issue Links:
Dependency
blocks GLASSFISH-20427 [regression] A distribution's depende... Open
Tags: maven build packaging
Participants: Romain Grécourt

 Description   

Create intermediate feature-set poms that should contain packager dependencies.
The purpose of this is to be able to cut the maven graph at distribution level, in order to not force the maven downloading of all distro transitive dependencies (i.e. packages direct dependencies).

Those feature-set poms will have full visibilit on the maven graph and should be re-used for distribution inheritance.
Distribution pom should be used only for direct consumption (i.e. zip).






[GLASSFISH-19771] publish javaee-schemas into maven for binary integration in GlassFish Created: 05/Mar/13  Updated: 05/Mar/13

Status: Open
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b78
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: schemas maven
Participants: Romain Grécourt

 Description   

JavaEE schemas are built here: https://svn.java.net/svn/glassfish~svn/trunk/schemas/javaee7
Spec leads contribute individually.

Currently Hong build scrubs for changes then build and copy updated schemas into GlassFish svn repository.

We would need to agree on the maven coordinates (groupId/artifactId/version) to choose.
Instead of creating a bug zip file, I would prefer to publish each file separately, as a pre-staged zip file or directly as .xsd files

Since this is an ant build, we may convert it to maven (or wrap it to not disrupt anything) in order to version things correctly for maven releases.

Eventually we would split the dtds/schemas into invidual modules instead of most of them under the deployment module.






[GLASSFISH-20071] Asadmin command for listing the versions of all components Created: 27/Mar/13  Updated: 28/Jun/13

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b81
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: myfear Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: Fishcat
Participants: myfear, Romain Grécourt and Tom Mueller

 Description   

It would be great to have something like:

Asadmin --versions

Which lists all the versions of the bundled components (e.g jersey, eclipselink)

That would make testing a lot easier...



 Comments   
Comment by Tom Mueller [ 27/Mar/13 02:18 PM ]

Some commands that are related to this:

pkg list

This lists the versions of all of the GlassFish packages. However, this shows the GlassFish version number, not necessarily the version number of the embedded component.

asadmin osgi lb

This lists a version for each OSGi bundle (JAR) in the system.





[GLASSFISH-20288] Make nucleus compile with Java source=1.7, target=1.7 Created: 11/Apr/13  Updated: 24/Apr/13

Status: Open
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0.1

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: michael.y.chen, Romain Grécourt and Tom Mueller

 Description   

This issue is for changing nucleus to compile with Java source=1.7 and target=1.7.

I've tried this in a private workspace and passed the following test suites:

  • full top-down build of BG and CL
  • nucleus QL and admin devtests
  • GF QL
  • CPAS+BG admin devtests


 Comments   
Comment by michael.y.chen [ 24/Apr/13 04:48 AM ]

Tom, the main goal to enable this is to use the JDK 7 features to enhance performance. Given where we are, I don't think we have time to take advantage of the JDK 7 features now. To reduce risks, I think we should defer this to 4.0.1.

Comment by Tom Mueller [ 24/Apr/13 02:17 PM ]

Actually, this is a low risk fix. However, deferring to 4.0.1.





[GLASSFISH-20431] Need glassfish-all javadocs Created: 29/Apr/13  Updated: 24/Jun/13

Status: Open
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b88_RC4

Type: Bug Priority: Major
Reporter: Joe Di Pol Assignee: Romain Grécourt
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Joe Di Pol and Romain Grécourt

 Description   

For GlassFish 3 we have:

https://glassfish.java.net/docs/v3/api/

we need a version of that for GlassFish 4 (https://glassfish.java.net/docs/4/api/)

The build currently generates only the Java EE 7 API javadocs.



 Comments   
Comment by Joe Di Pol [ 24/Jun/13 05:25 PM ]

Mike says published link should be: http://glassfish.java.net/docs/4/api/





[GLASSFISH-20758] not use distribution-fragment as type to refer to artifacts produced with a distribution-packaging Created: 13/Aug/13  Updated: 13/Aug/13

Status: Open
Project: glassfish
Component/s: None
Affects Version/s: 4.0_b89_RC5
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: maven
Participants: Romain Grécourt

 Description   

distribution-packaging creates zip.It is automatically mapped to zip when using the extension (glassfishbuild-maven-plugin) that contains distribution-fragment, but not when not using any particular extension, e.g. while pulled as part of a transitive tree.

see https://svn.java.net/svn/glassfish~svn/tags/4.0-b89/appserver/jdbc/jdbc-ra/jdbc-ra-distribution/pom.xml






[GLASSFISH-20833] Makes l10n jars, attached artifacts and not separate Maven artifact Created: 30/Sep/13  Updated: 30/Sep/13

Status: Open
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: 1 week
Time Spent: Not Specified
Original Estimate: 1 week

Tags: maven l0n
Participants: Romain Grécourt

 Description   

Instead of having "dummy" poms to generate the l10n jars, those could be created as attached artifact and their workspace (i.e. src/main/resources) merged into their corresponding bundles.
This could allow more "maven automation" for creating l10n distribution based on the dependency graph.

Some other benefits: remove the number of modules in the reactor, remove the fake "sources.jar" and "javadoc.jar" that are created to satisfy the maven central requirement.






[GLASSFISH-20835] hook org.netbeans.external:ddl to glassfish's repackaged Netbeans artifacts Created: 01/Oct/13  Updated: 01/Oct/13

Status: Open
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days

Tags: netbeans maven finsbugs
Participants: Romain Grécourt

 Description   

When running findbugs on the GlassFish workspace, findbugs issues the following messages:

[INFO] ------------------------------------------------------------------------
[INFO] Building ejb-mapping module for cmp 4.0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- findbugs-maven-plugin:2.5.2:findbugs (default-cli) @ cmp-ejb-mapping ---
     [java] The following classes needed for analysis were missing:
     [java]   org.netbeans.lib.ddl.impl.DriverSpecification
     [java] Missing classes: 1

The missing class can be found in org.netbeans.exterrnal:ddl, however those artifacts are not in Maven central but in Netbeans repository http://bits.netbeans.org/maven2/.
Since this is only related to findbugs and an extra repository may affect the build, the correct workaround would be as follow:

    <!--
        Findbugs needs org.netbeans.external:ddl,
        we isolate it in a profile as it requires a separate repository definition.
    -->
    <profiles>
        <profile>
            <id>findbugs</id>
            <repositories>
                <repository>
                    <id>netbeans</id>
                    <releases>
                        <enabled>true</enabled>
                    </releases>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                    <url>http://bits.netbeans.org/maven2</url>
                </repository>
            </repositories>
            <dependencies>
                <dependency>
                    <groupId>org.netbeans.external</groupId>
                    <artifactId>ddl</artifactId>
                    <version>RELEASE65</version>
                </dependency>
            </dependencies>
        </profile>
    </profiles>

This may be due to our repackaged version of the NetBeans artifacts that may not reflect the dependencies correctly.
The proper way would be to republish the corresponding repackaged artifacts to add the dependency.

org.netbeans.external.ddl should be repackaged and published to maven central to avoid the extra repository definition.






[GLASSFISH-20834] Make the logging-annotation-processor a maven plugin Created: 01/Oct/13  Updated: 01/Oct/13

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: 4.0
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Tags: logging-annotation-processor maven logging findbugs
Participants: Romain Grécourt

 Description   

In GlassFish, the logging-annotation-processor is used as a regular dependency.

The artifact contains a META-INF/services/javax.annotation.processing.processor file which triggers the pre-compilation.
IIRC, we couldn't let the dependency be exposed (i.e transitive dependency) as there were some errors when the logging annotation(s) weren't used.

 <dependency>
    <groupId>org.glassfish</dependency>
    <artifactId>logging-annotation-processor</artifactId>
    <optional>true</optional>
 </dependency>

Also, some build logic has been added to the processor to support incremental builds. (see https://java.net/jira/browse/GLASSFISH-18862)

Findbugs expect all the class required for its analysis to be present in the dependency graph, however we are not exposing the logging-annotation-processor for the reasons explained above.
It would be awkward to re-define the logging annotation processor (just to satisfy findbugs) for modules produced in the GlassFish workspace. It would also trigger an un-necessary run of the processor.

Instead, it should be a maven plugin, and hooked in the GlassFish build via the "glassfish-jar- lifecycle, like the hk2 plugins or the command security maven plugin.
The META-INF/services/javax.annotation.processing.processor would also have to be removed.






[GLASSFISH-20838] Move 3rd party repackaged OSGi bundles out of the GlassFish workspace / build Created: 01/Oct/13  Updated: 15/Oct/13

Status: Open
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days

Tags: maven 3rdparty osgi packaging
Participants: Romain Grécourt

 Description   

The non OSGied 3rd party artifacts are repackaged in the packager/external modules (main/nucleus/packager/external and main/appserver/packager/external).

Those 3party artifacts don't change often, but are part of the GlassFish build and hence published as part of every published build of GlassFish.
Also, there is no easy way to figure out what version of the 3rd party is used as the GlassFish version is used.

Instead, we should release those modules separately.

This would allow us to binary integrate those repackaged osgi bundles in the build, removing a bunch of modules from the build and the confusion around the version.
I'd suggest we put them in https://svn.java.net/svn/glassfish~svn/trunk/external/modules/, and provide a release.sh script for each module (see https://svn.java.net/svn/glassfish~svn/trunk/api/javaee-api/javax.annotation/release.sh) to facilitate the release process.

Also, we could provide a standard wiki page that describes how to setup the "maven release" environment.

Here is a list of the involved modules:

  • antlr
  • j-interop
  • jmxremote_optional
  • ldapbp
  • trilead-ssh2
  • vboxjws
  • ant
  • dbschema
  • javadb
  • jaxr_ra
  • jmsra
  • libpam4j
  • schema2beans

Some of the repackaged artifacts are not issued from Maven workspace, hence their dependency graph maybe incorrect (or inexistant).
We can leverage that to remove some workarounds present in the GlassFish workspace:

  • findbugs needs org.netbeans.external:ddl when introspecting code that uses either dbschema or schema2beans
  • antlr maven plugin expect the original antlr dependency in the graph, however it's not provided by our repackaged artifact, hence we have to add the original antlr dependency just to satisfy the plugin. (see ./appserver/persistence/cmp/support-sqlstore/pom.xml)





[GLASSFISH-21030] CDI failures with 4.0.1-b05-SNAPSHOT Created: 03/Apr/14  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: jax-rs
Affects Version/s: None
Fix Version/s: 4.0.1

Type: Bug Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JERSEY-2461 Jersey CDI extension causes CDI deplo... Open
Tags: cdi jersey glassfish 4_0_1-review
Participants: Romain Grécourt

 Description   

Here is what the error looks like:

org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001409 Ambiguous dependencies for type [Logger] with qualifiers [@Default] at injection point [[BackedAnnotatedField] @Inject private transient TestServlet.log]. Possible dependencies:
 - org.glassfish.jersey.gf.cdi.internal.CdiComponentProvider$Hk2Bean@2cb100f,
 - Producer Method [Logger] with qualifiers [@Any @Default] declared as [[BackedAnnotatedMethod] @Produces public TestLoggerProducer.getLogger()]

We are investigating a workaround to use before the next jersey integration. (basically bundle org.glassfish.jersey.containers.glassfish:jersey-gf-cdi-ban-custom-hk2-binding:2.7).






[GLASSFISH-20977] gf-client-module.jar is an OSGi bundle, but should not be Created: 10/Feb/14  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0
Fix Version/s: 4.0.1

Type: Bug Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: build osgi 4_0_1-review
Participants: Romain Grécourt

 Description   

Caused by: org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.main.appclient.gf-client-module [67]: Unable to resolve 67.0: missing requirement [67.0] osgi.wiring.package; (osgi.wiring.package=org.jboss.weld.environment.se)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3974)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2037)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:210)






[GLASSFISH-20855] move and mavenize major developer tests from glassfish v2 repository to trunk/appserver/tests Created: 15/Oct/13  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: build_system, test
Affects Version/s: 4.0
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: 2 weeks
Time Spent: Not Specified
Original Estimate: 2 weeks
Environment:

any


Tags: test maven glassfish devtest
Participants: Romain Grécourt

 Description   
  • Current developer test suite are documented here: https://wikis.oracle.com/display/glassfish/DeveloperTestDashboard
  • Those test suites are owned by particular developer, they are responsible for monitoring the test results.
  • They can take some time to run, hence they are not required for every checkin but depending on the changes (owner will likely request it)

The codeline comes from GlassFish 2.x, the test codebase is still located in the v2 svn repository: https://svn.java.net/svn/glassfish~v2/trunk/appserv-tests/devtests/

Those tests suite are still developed, and are used to test the current GlassFish codeline.

  • They are using the infrastructure that is provided by the old workspace
  • It is based on ant and is sometime platform dependent (i.e, can't work on windows).
  • It requires shell environment configuration to run (PATH and environment variables used by the tests)

This improvement is about mavenizing some of those devtests with as few changes as possible, in order to provide the following:

  • No change in the source code
  • Only maven / jdk required, everything else is downloaded and configured on the fly via maven
  • A pom.xml wrapping the tests scenario (e.g. with profiles)
  • Test workspace nested under appserver/tests, in order to be tagged be each release

Some things nice to have:

  • Windows / UNIX profiles to help sorting the suite that supports windows or not.
  • Generation of standard junit/testng report for easier CI
  • Test coverage infra (with cobertura)

Here are the in-scope test suites:

  • deployment
  • ejb
  • security
  • admin
  • webtier

Eventually, some documentation should be written under appserver/tests to guide developers.






[GLASSFISH-14384] Extra character in default install directory Created: 03/Nov/10  Updated: 05/Apr/12

Status: Open
Project: glassfish
Component/s: installation
Affects Version/s: 3.1
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: Alex Pineda Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 14,384
Tags: glassfish installer
Participants: Alex Pineda, Romain Grécourt and scatari

 Description   

On build 26, ogs distribution, and while installing on a Solaris machine, the
default directory on the page has an extra "/" when I install using "Typical"
installation. For example and in my case, the following is displayed

Installation Directory /export/sqe//glassfish3

The correct path should be: /export/sqe/glassfish3



 Comments   
Comment by scatari [ 03/Nov/10 11:41 AM ]

The installer generates this value based on $HOME environment variable. If the variable's value contains a
"/" at the end, then one would get such generated paths. Closing as not a bug. Please feel free to reopen if
$HOME does not have a "/" at the end.

Comment by Alex Pineda [ 03/Nov/10 11:54 AM ]

I just tried on 4 different platforms. All use the bash shell and all share the
same .bashrc file. In none of the systems, the variable $HOME is set in the
local directory. On MacOS, RHEL 5, OEL5 when I do echo $HOME, I get
/export/sqe, but on Solaris, I get /export/sqe/, which based on your explanation
it's why I see the extra "/" in my Solaris system. So, any possibility you
could add some conditional logic to add or not to add a "/" to the default path?
I know we're running out of time.

Comment by scatari [ 03/Nov/10 12:01 PM ]

Even with the two "/" s, it should create the directory with the correct path i,e $HOME/glassfish3 and not
$HOME//glassfish3. Please let me know if this is not happening, then this is a serious issue.

Comment by Alex Pineda [ 03/Nov/10 12:09 PM ]

No. Is not creating a directory with the two "/"'s. Is just a display issue.

Comment by scatari [ 03/Nov/10 12:13 PM ]

Targeting this for 3.2, just a display issue.





[GLASSFISH-15927] [installer] Error and could not run installer when using this syntax ". ./ogs-3.1-b41-unix.sh" Created: 09/Feb/11  Updated: 05/Apr/12

Status: Open
Project: glassfish
Component/s: installation
Affects Version/s: 3.1_b41
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: Homer Yau Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RedHat Enterprise Linux 5 with promoted build b41


Tags: 3_1 glassfish installer
Participants: Homer Yau, Romain Grécourt and scatari

 Description   

[installer] Error and could not run installer when using this syntax ". ./ogs-3.1-b41-unix.sh"

It just crash the installer and close the terminal window.

1) Download ogs-3.1-b41-unix.sh
2) From command line type . ./ogs-3.1-b41-unix.sh
3) Then the installer try to extract the package
4) then it just stop and exit the windows.

workaround

When I use the syntax "sh ./ogs-3.1-b41-unix.sh", the installer GUI comes up.

Below is the error before the installation exit.

[root@bigapp-opteron-11 downloads]# . ./ogs-3.1-b41-unix.sh
Extracting the installer archive...
tail: cannot open `bash' for reading: No such file or directory
Extracting the installer runtime...
java.io.FileNotFoundException: ./Product/Packages/Engine.zip (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at java.io.FileInputStream.<init>(FileInputStream.java:66)
at sun.tools.jar.Main.run(Main.java:238)
at sun.tools.jar.Main.main(Main.java:1149)
Extracting the installer resources...
java.io.FileNotFoundException: ./Product/Packages/Resources.zip (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at java.io.FileInputStream.<init>(FileInputStream.java:66)
at sun.tools.jar.Main.run(Main.java:238)
at sun.tools.jar.Main.main(Main.java:1149)
Extracting the installer metadata...
java.io.FileNotFoundException: ./Product/Packages/metadata.zip (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at java.io.FileInputStream.<init>(FileInputStream.java:66)
at sun.tools.jar.Main.run(Main.java:238)
at sun.tools.jar.Main.main(Main.java:1149)
rm: remove regular empty file `tmp.jar'?

Workaround I use different syntax to launch the installer.

Below is the standard output.
[root@bigapp-opteron-11 downloads]# sh ./ogs-3.1-b41-unix.sh
Extracting the installer archive...
Extracting the installer runtime...
Extracting the installer resources...
Extracting the installer metadata...

Welcome to GlassFish V3 installer

Using the user defined JAVA_HOME : /usr
Entering setup...
SwixML 1.5 (#144)

Then the install first Panel comes up.



 Comments   
Comment by scatari [ 10/Feb/11 09:16 AM ]

This is due to the difference in launching shell environment and the one supported by the launch script. The installation guide clearly documents the usage as "sh <install bundle>". I am retargeting this for 3.2.

Comment by Romain Grécourt [ 05/Apr/12 09:31 AM ]

I reproduced the issue with 3.1.2-release-unix.sh

Extracting the installer archive...
usage: tail [-F | -f | -r] [-q] [-b # | -c # | -n #] [file ...]
Extracting the installer runtime...
java.io.FileNotFoundException: ./Product/Packages/Engine.zip (No such file or directory)
	at java.io.FileInputStream.open(Native Method)
	at java.io.FileInputStream.<init>(FileInputStream.java:120)
	at java.io.FileInputStream.<init>(FileInputStream.java:79)
	at sun.tools.jar.Main.run(Main.java:238)
	at sun.tools.jar.Main.main(Main.java:1149)
Extracting the installer resources...
java.io.FileNotFoundException: ./Product/Packages/Resources.zip (No such file or directory)
	at java.io.FileInputStream.open(Native Method)
	at java.io.FileInputStream.<init>(FileInputStream.java:120)
	at java.io.FileInputStream.<init>(FileInputStream.java:79)
	at sun.tools.jar.Main.run(Main.java:238)
	at sun.tools.jar.Main.main(Main.java:1149)
Extracting the installer metadata...
java.io.FileNotFoundException: ./Product/Packages/metadata.zip (No such file or directory)
	at java.io.FileInputStream.open(Native Method)
	at java.io.FileInputStream.<init>(FileInputStream.java:120)
	at java.io.FileInputStream.<init>(FileInputStream.java:79)
	at sun.tools.jar.Main.run(Main.java:238)
	at sun.tools.jar.Main.main(Main.java:1149)
chmod: product-installer.sh: No such file or directory
chmod: install/bin/engine-wrapper: No such file or directory
sh: product-installer.sh: No such file or directory

The zip archive is not extracted from the script (since tail failed). I need to investigate to see if this can be fixed.





[GLASSFISH-19535] provide a command like list-containers so user can see what is installed. Created: 15/Jan/13  Updated: 28/Jun/13

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: 4.0.1

Type: New Feature Priority: Minor
Reporter: Anissa Lam Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-17631 support list-containers Open
Tags:
Participants: Anissa Lam and Romain Grécourt

 Description   

This is one of the request from the community some time back. I don't have much details on exactly what should be provided to the user. I am filing this so that we may give some thought on this after 4.0.






[GLASSFISH-11389] javax:javaee-api:6.0 and javax.jvaee-web-api:6.0 are missing source jars Created: 05/Jan/10  Updated: 14/Mar/14

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: kohsuke Assignee: Romain Grécourt
Resolution: Unresolved Votes: 16
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 11,389
Tags:
Participants: aplossystems, Darious3, kithouna, kohsuke, ludo, Romain Grécourt, Tom Mueller and wsalembi

 Description   

Those jars in the Maven repository should have their corresponding source jar
files to assist developers.



 Comments   
Comment by ludo [ 05/Jan/10 12:53 PM ]

To assist developers to do what?
The corresponding JARs are stripped (no bytecode for methods) and are meant to
be used only for compilation. IDEs like NB or Eclipse bundle a zip for the javadoc.
What other use case do you need to get the src? Debugging? In this case, these
jars are not used for execution so also not for debugging. In the case of
debugging, I think there is a complete GF src somewhere to step into the real
code you execute from the real non stripped gf jars.

Comment by kohsuke [ 05/Jan/10 03:09 PM ]

Use case 1: javadoc lookup
Maven-aware IDEs don't suddenly notice that the dependency I have is JavaEE API
and switch to the right javadoc. This is certainly true for Eclipse and IDEA,
and I suspect it to be the same with NetBeans Maven support.

In those IDEs, if I'm writing my code and wanted to quickly check the javadoc of
those APIs, they need the accompanied source jar to be able to display them.
Ditto for figuring out the default parameter names when implementing/overriding
methods defined in the spec. IDEs don't use the bytecode for this, but instead
they do this by parsing the source files.

Use case 2: step executing inside spec classes
Some of the classes in JavaEE API have methods that are often worth executing.
When the debugger steps into those code, it needs the source files to be able to
display what's being executed. For this purpose, it's OK that javaee-api.jar can
be stripped — the debugger executes actual classes in the app server — but
you do need to have the source files.

The whole point of providing source jars is so that the necessary association
happens automatically. It's true that the user can get the complete GlassFish
source bundle and tell their IDEs to do the right thing, but the reason Maven
users use Maven is so that those grunt work can be handled by a program, instead
of using precious human time.

Comment by ludo [ 05/Jan/10 03:12 PM ]

But these jars are stripped: no byte code for method
For javadoc, both Eclipse and NB bundles have the ee 6 doc inline embedded.

Comment by kohsuke [ 05/Jan/10 03:33 PM ]

As I wrote, it doesn't matter if the actual jar file has executable byte code in
it or not; IDE doesn't use them.

Even if your IDE has the EE6 docs bundled, I doubt if it kicks in when importing
a Maven project. Those javadocs are presumably associated with system-defined
"JavaEE" library, but when I load my Maven project, it doesn't use those as
dependencies; it just depends on ~/.m2/repository/javax/javaee-api/6.0/javaee-
api-6.0.jar as a library, and IDE won't have any javadoc nor the source code for
that.

Comment by ludo [ 05/Jan/10 04:07 PM ]

Make sense:=)

Comment by ludo [ 07/Oct/10 08:18 PM ]

Legal aspect issue, not for 3.1. Moving to P4

Comment by Tom Mueller [ 06/Mar/12 09:56 PM ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by Darious3 [ 20/Dec/12 10:46 AM ]

Any progress here? I know legal aspects take a long time to resolve, but has any of the legal work been started 2 years ago?

Comment by Romain Grécourt [ 20/Dec/12 10:51 AM ]

Fixing this for ee6 is not a priority.
However it will be done correctly for ee7.

Comment by Darious3 [ 20/Dec/12 12:58 PM ]

Romain, that is great news! Thanks!

It would be even better if it was done for Java EE 6 as well, but as EE 7 is the way forward anyway that's good enough for me.

If it isn't done for EE 6 though, shouldn't this issue be either closed or renamed?

Comment by Tom Mueller [ 07/Feb/13 04:07 PM ]

Reassigning to Romain since Ludo is no longer on the project.

Comment by aplossystems [ 28/Jun/13 06:22 PM ]

This has massively ruined my day. I'm moving from Glassfish and my JSF tutorial isn't printed out the bean value to the view. I just wanted to debug the FaceServlet init method to make sure it was being loaded. Normally a 10 second job but looks like it's going to be another few hours down the pan.

Comment by kithouna [ 26/Sep/13 01:05 PM ]

What's the status of this now that Java EE 7 has been released?

Comment by wsalembi [ 14/Mar/14 07:11 AM ]

Any chances that the source code will ever be released on the java maven repository?

http://download.java.net/maven/2/javax/javaee-api/6.0/
http://download.java.net/maven/2/javax/javaee-web-api/6.0/





Generated at Sun Apr 20 09:47:13 UTC 2014 using JIRA 4.0.2#472.