<< Back to previous view

[GLASSFISH-21028] CLONE -Deployment from Web Console: temporary files are not deleted Created: 02/Apr/14  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 9.1peur2
Fix Version/s: future release

Type: Bug Priority: Blocker
Reporter: T-Gergely Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 7,180
Tags:
Participants: Anissa Lam and T-Gergely

 Description   

When anything (war or ear) is deployed from the web console, a temporary file of
the archive is not deleted. It never happens if the same archive is deployed
with command line or remotely from NetBeans IDE.

This is quite a problem, because in this case application server must be
periodically cleaned manually, especially if deployment is very frequent and
applications are not so small.

Example:
Original file: Foo.war
Deployed on server: /tmp/Foo28436.war



 Comments   
Comment by T-Gergely [ 02/Apr/14 11:45 AM ]

The same issue is still present in GlassFish Server Open Source Edition 4.0 (build 89).





[GLASSFISH-20951] support a known xml test format for deployment devtests results Created: 13/Jan/14  Updated: 13/Jan/14

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

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

Tags: deployment devtests
Participants: Hong Zhang and Romain Grécourt

 Description   

Currently the deployment devtests generates a report format that is not known by Hudson.
This create binary results (either passed or failed), making it difficult to track tests from Hudson.
The idea is to have Hudson track the result and turn jobs to "UNSTABLE" when there are test failures.

I scrubbed the various scripts and it seems that there are some tests written using JUnit, other using Testng, however I didn't find a way to generate a junit report for all the tests of the suite.
It'd be nice to be able to have SQE xml reports (like ejb and admin devtests), or anything like testng/junit or javatest.

Here is the current workaround I'm using

# the test report is not a known by hudson (not junit, testng, javatest nor sqe format)
# generating a dummy report to track test failures from hudson
# TODO generate a classname that has some meaning, not just dummy.class.Name all the time

# insert new lines where needed
sed -e 's/<test /\'$'\n <test /g' \
    -e 's/<\/test>/\'$'\n <\/test>/g' \
    -e 's/<result /\'$'\n  <result /g' \
    appserv-tests/devtests/deployment/tests-results.xml > appserv-tests/devtests/deployment/tests-results-h.xml

# dummy convertion
sed -e s@'<tests>'@'<testsuites><testsuite>'@g \
    -e s@'</tests>'@'</testsuite></testsuites>'@g \
    -e s@'description=\".*\"'@@g \
    -e s@'<test '@'<testcase classname="dummy.class.Name" '@g \
    -e s@'</test>'@'</testcase>'@g \
    -e s@'<result status="PASSED".*\/>'@@g \
    -e s@'<result status="FAILED".*\/>'@'<failure type="testfailure"/>'@g \
    appserv-tests/devtests/deployment/tests-h.xml > appserv-tests/devtests/deployment/tests-results-junit.xml


 Comments   
Comment by Romain Grécourt [ 13/Jan/14 02:48 PM ]

update the script snippet I'm using currently





[GLASSFISH-20931] UnsupportedCharsetException is not handled properly Created: 17/Dec/13  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: xianwu Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

« Hide

OS
Windows 7 Enterprise (Service Pack 1)

JDK
java version "1.7.0_11"
Java(TM) SE Runtime Environment (build 1.7.0_11-b21) Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)

GlassFish build: glassfish-4.0.1-b02-07_22_2013


Tags:
Participants: Anissa Lam and xianwu

 Description   

Reproducible operational steps:

1) set an invalid http.uri-encoding to admin-listener
asadmin set server.network-config.protocols.protocol.admin-listener.http.uri-encoding=testtest
server.network-config.protocols.protocol.admin-listener.http.uri-encoding=testtest
Command set executed successfully.

2) restart domain
asadmin restart-domain domain1
Successfully restarted the domain
Command restart-domain executed successfully.

3) access admin console (IE or FireFox)
http://localhost:4848/common/index.jsf

got page fault
HTPP Status 500-

Detailed logging from server.log

[2013-12-17T12:27:06.753+1100] [glassfish 4.0] [WARNING] [NCLS-CORE-00090] [javax.enterprise.system.core] [tid: _ThreadID=41 _ThreadName=admin-listener(3)] [timeMillis: 1387243626753] [levelValue: 900] [[
Internal Server error: /common/index.jsf
java.nio.charset.UnsupportedCharsetException: testtest
at java.nio.charset.Charset.forName(Charset.java:543)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:246)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:496)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:175)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:187)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:837)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:722)

4) similar issue if set invalid uri-encoding to http-listener-*
For example,
asadmin set server.network-config.protocols.protocol.http-listener-1.http.uri-encoding=testtest
server.network-config.protocols.protocol.http-listener-1.http.uri-encoding=testtest
Command set executed successfully.

It will cause 500 page fault to an application page with similar logging in server.log

5) Suggestion
It should handle UnsupportedCharsetException properly to avoid throwing it to the top level and create 500 page fault






[GLASSFISH-20907] Admin Console stops working when an application bundled with jersey-1.x.jar and classloader set to delegate false Created: 21/Nov/13  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui, classloader
Affects Version/s: 4.0_b89_RC5
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: iesen Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: admin-gui
Participants: Anissa Lam, iesen and Sanjeeb Sahoo

 Description   

A web application bundled with its own Jersey implementation (which is 1.x) crashes admin console after server restart. The application has glassfish-web.xml config file for classloading settings (delegate=false).

Exception is :
java.lang.AbstractMethodError: javax.ws.rs.core.UriBuilder.uri(Ljava/lang/String;)Ljavax/ws/rs/core/UriBuilder;

Looking at the verbose classloading output (-verbose:classes), admin console application grab Jersey 1.x classes from deployed application in applications folder. Manually deleting jersey 1.x jar from application's folder solves the exception and admin console starts. But is it not possible to deploy a Jersey 1.x application to Glassfish4?



 Comments   
Comment by Anissa Lam [ 21/Nov/13 04:23 PM ]

Assign to Sahoo for initial evaluation regarding class loading. Not sure console can do much on this.





[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-20848] There is overlap between Browse button and Location field in the Deploy page Created: 10/Oct/13  Updated: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: sunny-gui Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Windows 8 JA x64
Browser&Locale: FF24.0&fr-fr
Bundle: java_ee_sdk-7-b89b-jdk7-windows-ml.exe
JDK: jdk1.7.0_21 x86


File Attachments: JPEG File overlap_application_browseButton.jpg    
Tags:
Participants: Anissa Lam, Jeremy_Lv and sunny-gui

 Description   

To Reproduce:
1. Install & configure GF successfully.
2. Access Admin Console through access http://localhost:4848
3. Go to Application, and click on Deploy button.

Results:
There is overlap between Browse button and Location field in the Deploy page.

Attached screen shot for your reference.



 Comments   
Comment by Jeremy_Lv [ 21/Oct/13 03:41 AM ]

I think this is the Firefox's issue. the same issue can be reproduced when it comes to glassfish v3 and using the latest firefox. However, if you tried to use the IE, the same issue can't reproduced.

In my option, I don't think this is a bug to admin console as it doesn't cause any confusions or regressions for the Glassfish v4's admin console.





[GLASSFISH-20844] Glassfish 4 refresh taking up to 1 minute Created: 03/Oct/13  Updated: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: vaughnmb Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Server 2008 r2, 24 GB ram, 16 cores


Tags:
Participants: Anissa Lam and vaughnmb

 Description   

After I have deployed around 20 applications to Glassfish 4, the refresh screen time takes up to 1 minute. Glassfish 3 was around 10 seconds for 80 applications. I'm not talking about the deployment screen. I'm talking about the "white-out" screen when the page is trying to refresh.



 Comments   
Comment by vaughnmb [ 09/Oct/13 03:52 PM ]

I have performed more testing. I take a fresh install of glassfish 3.1.2.2 and glassfish 4 build 89 and autodeploy the same 80 applications to each server. Glassfish 3 can deploy the 81st application in 2-3 seconds. Glassfish 4 deploys the 81st application in 29 seconds. These applications are small CDI beans that inject an EJB. There is no database requirements or anything like that.

I will attach the files. The python file creates 80 new ear files of the same application. Just put the GlassfishTest.ear file and python file in the same folder and run the python file.

Comment by vaughnmb [ 09/Oct/13 03:53 PM ]

How do you attach files?

Comment by Anissa Lam [ 09/Oct/13 03:58 PM ]

The attachment feature has been taken away from JIRA. You can put that somewhere and give us the pointer.
Are you saying deployment is slow in the console ? What if you use CLI to deploy, do you experience the same ?

Comment by vaughnmb [ 09/Oct/13 04:20 PM ]

http://www.hvacworld.biz/downloads/GLASSFISH-20844.zip

Deployment was slow through the console, but it was fast through CLI.

Comment by vaughnmb [ 14/Oct/13 02:28 PM ]

Could you duplicate the problem? Is there anything else you need me to do?

Comment by vaughnmb [ 09/Dec/13 01:51 PM ]

I'm guessing this problem is being ignored or couldn't be duplicated? Any feedback would be nice so I can make some organizational decisions.





[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-20837] Glassfish admin listener thread failure trying to login due to NPE Created: 01/Oct/13  Updated: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: arie_golos Assignee: Anissa Lam
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux SUSE 11.3, JDK 1.7.0_25 64 bit, Glassfish4.0
I believe this also happened on my windows 7 machine


Tags: 4_0_1-review admin-gui
Participants: Anissa Lam and arie_golos

 Description   

[2013-10-01T11:07:19.750-0400] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=197 _ThreadName=admin-listener(16)] [timeMillis: 1380640039750] [levelValue: 900] [[
StandardWrapperValve[FacesServlet]: Servlet.service() for servlet FacesServlet threw exception
java.lang.NullPointerException
at org.glassfish.admingui.common.util.GuiUtil.genId(GuiUtil.java:343)
at org.glassfish.admingui.common.handlers.UtilHandlers.encodeId(UtilHandlers.java:1011)
at sun.reflect.GeneratedMethodAccessor684.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:551)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:590)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:590)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:590)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:254)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:678)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:724)






[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-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-20806] Provide embedded Glassfish as POM with dependencies as addition to or instead of the current ueber jar Created: 10/Sep/13  Updated: 15/Apr/14

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

Type: Improvement Priority: Major
Reporter: obfischer Assignee: Bhavanishankar
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Bhavanishankar and obfischer

 Description   

The embedded Glassfish is provided as huge uber jar. But wouldn't it be possible to provide it as POM with all required dependencies? This approach would allow to avoid dependency problems as I am facing them now. Sometimes the version of classes contained in embedded Glassfish differ from the dependecies required or provided by other libraries.

SLF4J, ASM, and Joda time are some examples. The POM approach would at least allow to analyse the dependencies of embedded Glassfish and to exclude some dependencies if the collide with other dependencies.






[GLASSFISH-20763] No confirmation message is displayed when Enable/Disable action is successfully performed Created: 15/Aug/13  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: xianwu Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS
Windows 7 Enterprise (Service Pack 1)

JDK
java version "1.7.0_11"
Java(TM) SE Runtime Environment (build 1.7.0_11-b21) Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)


Tags:
Participants: Anissa Lam and xianwu

 Description   

Reproducible operational steps:

No confirmation message is displayed at Application Targets screen for Enable/Disable action
1) Open GlassFish Admin console
2) Deploy any application (e.g. cart256)
3) Click Applications->cart256, then select Target tab
4) select all targets
5) select Enable from More Actions list
6) No confirmation message is displayed.

No confirmation message is displayed at Resource Targets screen for Enable/Disable action
1) Open GlassFish Admin console
2) Create a jdbc resource (e.g. jdbc/_TimerPool)
3) Click JDBC->JDBC Resources->jdbc/_TimerPool, then select Target tab
4) select all targets
5) click Enable button
6) No confirmation message is displayed.

However, confirmation message is displayed at JDBC Resources screen for Enable/Disable action
1) Open GlassFish Admin console
2) Create a jdbc resource (e.g. jdbc/_TimerPool)
3) Click JDBC->JDBC Resources
4) select all targets
5) click Enable button
6) Confirmation message "Selected resource(s) has been enabled" is displayed.



 Comments   
Comment by xianwu [ 15/Aug/13 06:25 AM ]

Hi Anissa

I have captured the screens (https://www.dropbox.com/s/51cjzhz8f06u1b8/Screens.xls) for your reference.

Regards, Xianwu





[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-20682] Custom JNDI Resources Not Saving Description Field Created: 06/Jul/13  Updated: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: fishsticks87 Assignee: Chris Kasso
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Tags: jndi custom_resource description
Participants: Chris Kasso and fishsticks87

 Description   

Using GF Admin, I created a custom JNDI resource of type java.util.Properties. I can successfully add and save the name and value columns in the Additional Properties table but the description column is not retained when saving. I also tried going into the domain.xml file and adding a description attribute to the <property> tag but it just gets wiped away again when I go back into the admin area and save it again.

The description field for each property should be saved and it is not getting saved.






[GLASSFISH-20658] @WebService and @Stateless not showing endpoint in GlassFish 4.0 admin console Created: 24/Jun/13  Updated: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Antonio Goncalves Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: admin-gui stateless webservice
Participants: Anissa Lam, Antonio Goncalves and Bruno Borges

 Description   

I wrote two very basic SOAP Web Services (https://github.com/agoncal/agoncal-sample-jaxws/tree/master/01-EndPoints) : one using a servlet endpoint and another one using an EJB endpoint :

@WebService
public class HelloServletEndpoint {

    public String saySomethingServlet(String something) {
        return "The HelloServletEndpoint is saying : " + something;
    }
}
@WebService
@Stateless
public class HelloEJBEndpoint {

    public String saySomethingEJB(String something) {
        return "The HelloEJBEndpoint is saying : " + something;
    }
}

I've packaged them in a war file and deployed the war into a GlassFish 4.0 instance (a full profile). When I check the admin console, I can view the servlet endpoint (test it and see the generated WSDL) but it does not work with the EJB endpoint (see the attached image). Both WSDLs are available though on the following URLs :

Looks like this is a bug in the UI



 Comments   
Comment by Bruno Borges [ 05/Feb/14 04:16 AM ]

Hi Antonio,

The reason to have <EJBName> as context-root for the @Stateless @WebService is for the case when they are deployed inside EJB modules in EAR files (Java EE 5), where there's no Web access (and so, no context-root).

I wonder though if there's anything in the specification of Java EE 6 that clarifies how the context-root of the EJB WebService should behave in the case it is deployed inside a single WAR instead of an EJB module.

Which specification should we be looking at? EJB or JAX-WS?





[GLASSFISH-20592] Need better error msg when trying to bring up console with javaee-ri distribution, which doesn't include GUI Created: 30/May/13  Updated: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: pbelbin Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows


Tags: fishcat
Participants: Anissa Lam, pbelbin and Snjezana Sevo-Zenzerovic

 Description   

downloaded the javaee-ri (date 28May) from the release directory and tried to start it using jdk 7u21 x64 on windows 7, and, even though I had set the JAVA_HOME and updated PATH, the response on the stdout appeared to indicate glassfish had started.

however, using a browser (IE10) all it does is show the spinning thing and shows the status as the adminconsole application is loaded.

it does not progress beyond that.

the default web page at port 8080 does appear and seems normal.

just seems impossible to bring up the admin console.



 Comments   
Comment by pbelbin [ 30/May/13 02:47 AM ]

in the server.log, I do see this:

[2013-05-29T21:46:31.982-0500] [glassfish 4.0] [SEVERE] [NCLS-CORE-00043] [javax.enterprise.system.core] [tid: _ThreadID=106 _ThreadName=Thread-10] [timeMillis: 1369881991982] [levelValue: 1000] [[
Application previously deployed is not at its original location any more: file:/G:/archives/glassfish-4.0/glassfish4/glassfish//lib/install/applications/__admingui]]

I checked the location mentioned, and, indeed, there is no directory __admingui at that directory (which does exist).

Comment by Snjezana Sevo-Zenzerovic [ 30/May/13 09:45 AM ]

FWIW, RI distribution is Java EE reference implementation and and not full GlassFish distribution. As such it does not contain Admin console functionality.

Leaving the issue open to see whether we need to enhance something in the future release to get more graceful behavior since the message about admin console loading is rather misleading.

Comment by Anissa Lam [ 30/May/13 06:16 PM ]

As Snjezana pointed out, console is not include/supported for RI. It should give proper/better message so user can realize that, instead of hidden in the server.log. Don't think this should be classified as a blocker. Downgrading the priority.

This is similar to GLASSFISH-17324, where the same thing occurs when user tries to bring up the console with the nucleus distribution.
We will address both at the same time.

Comment by Anissa Lam [ 30/May/13 06:19 PM ]

edit subject to better describe the issue.





[GLASSFISH-20578] App client deployment/download/launch should support --libraries option on deploy command Created: 23/May/13  Updated: 28/May/13

Status: Open
Project: glassfish
Component/s: standalone_client
Affects Version/s: V3, 3.1, 3.1.1, 3.1.2, 3.1.2.2, 4.0_b89_RC5
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Tim Quinn Assignee: Tim Quinn
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-13144 appclient with Extension-List manifes... Resolved
Tags: 4_0-exclude
Participants: Tim Quinn

 Description   

GLASSFISH-13144 describes the needs for app client deployments to support the --libraries option.

This issue captures that need separately. If this is still a need we'll track it with this issue.



 Comments   
Comment by Tim Quinn [ 23/May/13 09:59 PM ]

Linking to the original issue





[GLASSFISH-20559] The drop-down list could not displayed correctly under Connectors in Windows Created: 20/May/13  Updated: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: sunny-gui Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Server OS: Windows 2008 R2 ENT x64 zh_TW Native
Bundle: java_ee_sdk-7-web-b88-windows-ml.exe
Locale: zh_TW
JDK: 1.7.0_13 x64


File Attachments: JPEG File adminObjectResource_dropdownList.jpg     JPEG File connectorConnectionPool_dropdownList.jpg     JPEG File workSecurity_dropdownList.jpg    
Tags:
Participants: Anissa Lam and sunny-gui

 Description   

[To reproduce]
1. Install GF with bundle mentioned above.
2. In the Admin Console, go to Connectors > Work Security Maps, and click on New button.

In the New Work Security Map page, the drop-down list of Resource Adapter is not displayed correctly.

It is also reproducible in following pages.
1. Connectors > Connector Resources > New
2. Connectors > Connector Connection Pools > New
3. Connectors > Admin Object Resources > New

Attached screen shots for your reference.

I checked with 'java_ee_sdk-7-b87-jdk7-linux-x64-ml.sh' on OEL6 x64 en_US.UTF-8 & ja_JP.UTF-8, could not reproduce this issue.






[GLASSFISH-20503] NLS: THE LINK DOES NOT WORK IN THE UPDATE TOOL PAGE DURING INSTALL GF Created: 10/May/13  Updated: 27/Sep/13

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

Type: Bug Priority: Major
Reporter: sunny-gui Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Server OS: OEL 6 x64
Bundle: java_ee_sdk-7-b87-jdk7-linux-x64-ml.sh
Locale: ko_KR.UTF-8
JDK: 1.7.0_13 x64


File Attachments: JPEG File updateTool_link.jpg    
Tags:
Participants: Snjezana Sevo-Zenzerovic and sunny-gui

 Description   

[To reproduce]
1. Launch the installation program, click on Next to go the Update Tool page.

[Result]
The link 'GlassFish Usage Metrics' does not work in this page.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 10/May/13 09:22 AM ]

This is somewhat expected. Installer framework browser launch support is limited when it comes to different platforms and installed browsers and that is why we also provide explicit URL which can be copied and pasted by the user in order to access usage document.

Deferring to future release since it requires significant changes in openInstaller.

Comment by sunny-gui [ 27/Sep/13 08:59 AM ]

It is reproducible in the build b89b. Here are detailed env.

OS: OEL6 x64 ko_KR.UTF-8
Bundle: java_ee_sdk-7-web-b89b-jdk7-linux-x64-ml.sh
JDK: jdk1.7.0_25 x64





[GLASSFISH-20468] Can't send a JMS message from WebSocket's onMessage Created: 05/May/13  Updated: 18/Jun/13

Status: Reopened
Project: glassfish
Component/s: web_socket
Affects Version/s: 4.0_b86_RC2
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Bruno Borges Assignee: dannycoward
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Bruno Borges, dannycoward and jjsnyder83

 Description   

The following code fails to send an incoming WebSocket message to a JMS queue:

@ServerEndpoint("/websocket")
public class SampleWebSocket implements Serializable {

    @Resource(mappedName = "jms/myQueue")
    private Queue myQueue;
    @Inject
    private JMSContext jmsContext;

    @OnMessage
    public void onMessage(String message, Session client) {
        try {
            jmsContext.createProducer().send(myQueue, message);
            Logger.getLogger(getClass().getName()).log(Level.SEVERE, "message sent to queue");
        } catch (RuntimeException ex) {
            Logger.getLogger(getClass().getName()).log(Level.SEVERE, "RE on websocket.onMessage", ex);
        }
    }
}

This is the exception (not logged by GF due to GLASSFISH-20467)

SEVERE:   RE on websocket.onMessage
org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped
	at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:667)
	at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:74)
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)
	at org.glassfish.jms.injection.RequestedJMSContextManager$Proxy$_$$_WeldClientProxy.getType(Unknown Source)
	at org.glassfish.jms.injection.InjectableJMSContext.delegate(InjectableJMSContext.java:126)
	at org.glassfish.jms.injection.ForwardingJMSContext.createProducer(ForwardingJMSContext.java:61)
	at org.glassfish.javaee7wsjms.SampleWebSocket.onMessage(SampleWebSocket.java:65)

Because JMSContext is @RequestScoped, and a WebSocket message has the same behaviour as an HTTP request, it should be possible to use the injected JMSContext to send a message to a Queue from WebSocket.onMessage method.

The following code works fine:

@ServerEndpoint("/websocket")
public class SampleWebSocket implements Serializable {

    @Resource(mappedName = "jms/myQueue")
    private Queue myQueue;
    @Resource(lookup = "java:comp/DefaultJMSConnectionFactory")
    private ConnectionFactory defaultConnectionFactory;

    @OnMessage
    public void onMessage(String message, Session client) {
        try (JMSContext context = defaultConnectionFactory.createContext();) {
            context.createProducer().send(myQueue, message);
            Logger.getLogger(getClass().getName()).log(Level.SEVERE, "message sent to queue");
        } catch (RuntimeException ex) {
            Logger.getLogger(getClass().getName()).log(Level.SEVERE, "websocket.onMessage", ex);
        }
    }
}

This issue is also related to GLASSFISH-20371 (and it might influence JMS_SPEC-100)



 Comments   
Comment by jjsnyder83 [ 06/May/13 12:06 PM ]

The @Resource works because it's a resource injection of an object that is in JNDI. It is not a CDI-scoped injected object.

The @Inject fails for the same reason as: https://java.net/jira/browse/GLASSFISH-20371

Comment by jjsnyder83 [ 08/May/13 01:24 PM ]

This will require a CDI spec change. See https://issues.jboss.org/browse/CDI-370

Comment by jjsnyder83 [ 18/Jun/13 03:46 PM ]

This issue really is a usage issue of the JMSContext. The JMSContext requires a global Transaction or an active CDI request context. At the time the injected JMSContext is being used there is no global transaction and no active CDI request context and so the exception is thrown.

There is ongoing discussions on whether the CDI request context can be expanded to account for WebSocket and if WebSocket needs to create its own CDI scope. In any case this issue is a usage issue irt how WebSocket uses the JMSContext.





[GLASSFISH-20462] DAS is slow to stop if JMX RMI bind URL is no longer reachable when stop-domain is run Created: 03/May/13  Updated: 03/May/13

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

Type: Bug Priority: Minor
Reporter: Tom Mueller Assignee: prasads
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: prasads and Tom Mueller

 Description   

Occasionally, the asadmin stop-domain command fails to stop the server. It times out after 60 seconds waiting for the DAS to stop:

$ asadmin stop-domain
Waiting for the domain to stop ........................................................
Timed out (60 seconds) waiting for the domain to stop.
Command stop-domain failed.

Here is some of the jstack output from the DAS after this occurs:

The problem appears to be in the thread the is running the stop-domain command:

"Thread-22" daemon prio=5 tid=0x00007fcbf92b2000 nid=0xd233 runnable [0x000000013d324000]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)

  • locked <0x000000012cd628d0> (a java.net.SocksSocketImpl)
    at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
    at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
    at java.net.Socket.connect(Socket.java:579)
    at java.net.Socket.connect(Socket.java:528)
    at java.net.Socket.<init>(Socket.java:425)
    at java.net.Socket.<init>(Socket.java:208)
    at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
    at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:146)
    at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
    at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
    at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
    at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:340)
    at sun.rmi.registry.RegistryImpl_Stub.unbind(Unknown Source)
    at com.sun.jndi.rmi.registry.RegistryContext.unbind(RegistryContext.java:173)
    at com.sun.jndi.toolkit.url.GenericURLContext.unbind(GenericURLContext.java:272)
    at javax.naming.InitialContext.unbind(InitialContext.java:435)
    at javax.naming.InitialContext.unbind(InitialContext.java:435)
    at javax.management.remote.rmi.RMIConnectorServer.stop(RMIConnectorServer.java:561)
    at org.glassfish.admin.mbeanserver.ConnectorStarter.stop(ConnectorStarter.java:125)
  • locked <0x0000000118b93bf8> (a org.glassfish.admin.mbeanserver.RMIConnectorStarter)
    at org.glassfish.admin.mbeanserver.RMIConnectorStarter.stopAndUnexport(RMIConnectorStarter.java:310)
    at org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread.shutdown(JMXStartupService.java:245)
    at org.glassfish.admin.mbeanserver.JMXStartupService.shutdown(JMXStartupService.java:193)
  • locked <0x00000001184d4ca0> (a org.glassfish.admin.mbeanserver.JMXStartupService)
    at org.glassfish.admin.mbeanserver.JMXStartupService.access$000(JMXStartupService.java:96)
    at org.glassfish.admin.mbeanserver.JMXStartupService$ShutdownListener.event(JMXStartupService.java:163)
    at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
    at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:478)
  • locked <0x0000000118773f38> (a com.sun.enterprise.v3.server.AppServerStartup)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
  • locked <0x00000001187835f8> (a com.sun.enterprise.glassfish.bootstrap.GlassFishImpl)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.stop(GlassFishDecorator.java:68)
    at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.stop(EmbeddedOSGiGlassFishImpl.java:82)
    at com.sun.enterprise.v3.admin.StopServer.doExecute(StopServer.java:79)
    at com.sun.enterprise.v3.admin.StopDomainCommand.execute(StopDomainCommand.java:96)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:356)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
    at org.glassfish.api.AsyncImpl$1$1.run(AsyncImpl.java:76)

This problem seems to occur after the server has been up for a while (for example overnight).



 Comments   
Comment by Tom Mueller [ 03/May/13 03:12 PM ]

In this situation, eventually the DAS does exit. Apparently, the Socket.connect call eventually times out and the server finishes exiting. So the mystery here is why is javax.naming.InitialContext.unbind making a socket connection during shutdown.

Comment by Tom Mueller [ 03/May/13 06:18 PM ]

To reproduce this problem, start the server while connected to VPN (so the hostname/IP address of the server is set). While the server is running, disconnect from VPN so the IP address is no longer associated with the host. Then run stop-domain. (This sometimes causes the problem).

The JMX unbind request is being done on a URL like this:

"rmi://192.168.0.16:8686/jmxrmi"

or sometimes, like this:

"rmi://dhcp-adc-twvpn-3-vpnpool-10-154-105-156.vpn.oracle.com:8686/jmxrmi"

In the first case, the URL uses the IP address of my host on the local LAN. In the second case, it uses the VPN hostname of the VPN address. If the JMX URL is of this latter kind, and the host is disconnected from the VPN at the time stop-domain is run, the unbind request will attempt to connect to the URL and it will fail but with a long timeout. This causes the DAS exit to take a long time so the stop-domain times out.

Comment by Tom Mueller [ 03/May/13 06:20 PM ]

Lowering the priority, deferring to a future release and changing the component to AMX.





[GLASSFISH-20436] Provide command to identify the http port for a clustered instance independent of whether it uses the default cluster config Created: 29/Apr/13  Updated: 22/May/13

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

Type: Improvement Priority: Major
Reporter: marina vatkina Assignee: kumara
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: kumara, marina vatkina and Tom Mueller

 Description   

There is no asadmin command to identify http port of the 1st instance in cluster. The currently available work around of 'asadmin get configs.config.<cluster-name>-config.system-property.HTTP_LISTENER_PORT.value' returns the default value, not the actual value of the assigned port in case the default port was not available at the time of the instance creation.



 Comments   
Comment by Tom Mueller [ 30/Apr/13 02:47 PM ]

Try the following get command for a server named "i1":

$ asadmin get servers.server.i1.system-property.HTTP_LISTENER_PORT.value

If the server is using the default value from the cluster, then you get this output:

remote failure: Dotted name path servers.server.i1.system-property.HTTP_LISTENER_PORT.value not found.
Command get failed.

If the server is using its own value, then you get this output:

servers.server.i1.system-property.HTTP_LISTENER_PORT.value=28081
Command get executed successfully.

Comment by Tom Mueller [ 30/Apr/13 02:48 PM ]

Marking this as resolved since there is a command sequence that provides this information.

If the desire is for a single command that provides this information, then we can reopen this issue and change it to be an RFE.

Comment by marina vatkina [ 30/Apr/13 04:44 PM ]

will change it to RFE





[GLASSFISH-20417] ability to have asadmin emit output that can then be scripted back as create statements Created: 26/Apr/13  Updated: 29/Apr/13

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

Type: New Feature Priority: Major
Reporter: pbelbin Assignee: Masoud Kalali
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Masoud Kalali, pbelbin and Tom Mueller

 Description   

as much as asadmin's export-sync-bundle will snapshot an entire domain's configuration, and allow that entire config to be used elsewhere, this is not so good if you only need to move bits and pieces of a config, as might be the case when you want to update an existing production config with the new jdbc resources from the development platform.

it would be great if the list or export commands could be told what to list, and have them effectively generate the asadmin commands one would then use on the other system for those resources to create them.



 Comments   
Comment by Tom Mueller [ 29/Apr/13 02:09 PM ]

Request for clarification - are you looking for the ability to record commands that have been run as they are run, so that they can be replayed later? Or are you looking for a backup/restore type capability that can be used for test-to-production except that it only transfers a part of the configuration, no matter now the configuration was modified?

The former is available to a certain extent using the AS_LOGFILE environment variable. When set, this produces a file like the following:

04/29/2013 09:00:17 EXIT: 0 asadmin start-domain
04/29/2013 09:00:22 EXIT: 0 asadmin deploy apps/helloworld.war
04/29/2013 09:00:26 EXIT: 0 asadmin create-jvm-options -Da=b
04/29/2013 09:00:34 EXIT: 0 asadmin create-cluster c1

The timestamp and exit code have to be removed, but this provides a list of commands that were executed.
However, this does not reproduce configuration that was accomplished via the GUI interface or any other means.

Another alternative would be something like the backup-domain and restore-domain commands. The backup-domain command allows the complete configuration of a domain to be saved into a backup file, and then the restore-domain command can use that file to recreate the domain. The restore-command creates a brand new domain; it does not apply configuration changes that were made to the domain to an existing domain. If the restore capability were modified to allow only parts of the configuration to be restored, then that might meet this need.

Comment by Tom Mueller [ 29/Apr/13 04:49 PM ]

If any change is going to be done for this, it will be in a future release (not 4.0), so marking the fix version as future-release. Still waiting for feedback as to determine what is actually desired here.

Comment by pbelbin [ 29/Apr/13 05:14 PM ]

I'm looking for something that we can use to 'extract' a portion of the config in a way that can then be used to push that portion to another instance.

eg: code on lab server requires a new JMS config, or JDBC connection & pool be defined.

it would be very useful to allow the existing lab config to be pulled, then modified where/if needed, in text form, then, use that information via asadmin to create the same resource on the production platform.

I don't want to move the entire glassfish config from lab to production. just a portion, with the ability to edit the details to account for differences between lab and production server names etc.

seems odd that we can push config commands, but we can't get something out, that we can then use to push against another instance.

Comment by Tom Mueller [ 29/Apr/13 06:03 PM ]

So it looks like this is more than just using asadmin log file output. It might be related to the backup worked, but with the requirement to edit the configuration in between, it is different than that. This might be related to get-active-module-config, however, there is no way to use the output from that command to input the configuration into another service.

Comment by pbelbin [ 29/Apr/13 06:44 PM ]

another good example of what I'm looking for is this:

I manually created a JNDI Custom Resource using java.util.properties.

I have created it with perhaps a dozen distinct properties.

Now, I want to do 2 things:

1. create a copy of this, but with some minor tweaks, as a new custom resource.
2. save this, from my development environment, and then install it in a different environment altogether.

using the existing asadmin command, I believe (with some difficulty perhaps) I can create the resource, but there's no way to extract the current values, allow me to change them, and then push them back into the glassfish instance (or another instance).

it's not symmetrical. I can push, but I can not pull.





[GLASSFISH-20310] JAVA EE 7 SDK : GUI installer will not come up on MAC OS if you do not set "AWT_TOOLKIT=XToolkit" . Created: 15/Apr/13  Updated: 17/Apr/13

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

Type: Bug Priority: Major
Reporter: bhavya_h_s Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OS


Tags:
Participants: bhavya_h_s and Snjezana Sevo-Zenzerovic

 Description   

Trigger java ee 7 sdk installer on Mac OS , installation fails with below error.

$sh java_ee_sdk-7-b83-jdk7-macosx.sh
Extracting the installer archive...
Extracting the installer runtime...
Extracting the installer resources...
Extracting the installer metadata...

Welcome to GlassFish installer

Using the user defined JAVA_HOME : /Library/Java/JavaVirtualMachines/jdk1.7.0_15.jdk/Contents/Home
Entering setup...
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.

Workaround :
------------
Set "AWT_TOOLKIT=XToolkit" and then start the installation



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 15/Apr/13 01:27 PM ]

Could you please provide following information given that this was run on the hosted system (we apparently don't run into this issue if installation is done locally on MacOS system):

  • did you use some sort of remote desktop client software and if so, which one
  • if the installation was done by simply setting the DISPLAY value to local display, what was the OS and version of the display system

I did some preliminary investigation on the issue and it seems that this happens if someone uses Linux or Solaris system for display.

Comment by bhavya_h_s [ 16/Apr/13 05:48 AM ]

Yes I triggered the installation by setting DISPLAY variable. I was using OEL6 operating system.

Comment by Snjezana Sevo-Zenzerovic [ 17/Apr/13 12:15 AM ]

This is not very common usage scenario so targeted to future release. Will evaluate whether we need to release note the workaround.





[GLASSFISH-20260] ADMINGUI : view raw log information not described in online help document Created: 10/Apr/13  Updated: 10/Apr/13

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

Type: Bug Priority: Major
Reporter: RameshT Assignee: Mike Fitch
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

WIN7 FF19 IE


Tags: raw log admingui docs
Participants: Mike Fitch and RameshT

 Description   

view raw log button information not described in the help document.

=========================
help document :
The General Information page contains the following information.

Stop Button

Click the Stop button to stop the GlassFish Server.
Restart Button

Click the Restart button to restart the GlassFish Server.
View Log Files Button

Click the View Log Files button to view log files for a GlassFish Server instance or cluster.
Rotate Log Button

Click the Rotate Log button to rotate the log file for the Admin Server (named server).
Recover Transaction Button

Click the Recover Transaction button to recover transactions for the Admin Server (named server) on the Recover Transactions page.
Secure Administration Button

Click the Secure Administration button to enable or disable secure administration on the Secure Administration page.
======================

In the above help document "View Raw Log" button not described.



 Comments   
Comment by Mike Fitch [ 10/Apr/13 05:15 PM ]

The problem mentioned in this issue predates GlassFish 4.0. According to Anissa, this button has been in the GUI since 3.1.2.

Moving this to "Future Release" because the final online help for GlassFish 4.0 has already been committed and is in translation.





[GLASSFISH-20259] AdminGUI : log viewer - search criteria - description Created: 10/Apr/13  Updated: 10/Apr/13

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

Type: Bug Priority: Major
Reporter: RameshT Assignee: Mike Fitch
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7 FF19 , IE


Tags: log viewer admingui search
Participants: Mike Fitch and RameshT

 Description   

server-> general -> view log files

In online help document.

Issue 1 :
Search criteria is given as :
The Search Criteria area contains the following options.

Advanced Search

Clicking this link opens an area that allows you to make additional refinements to the log viewer.

In the search criteria "Advanced Search" will not come. "Advanced Search" is an another topic. This has to be given in Advanced search section.

Issue 2 :
Here in search criteria the "text search" has not been explained.



 Comments   
Comment by Mike Fitch [ 10/Apr/13 04:00 PM ]

The two problems mentioned in this issue predate GlassFish 4.0. They were evident in GlassFish 3.x releases as well.

Moving this to "Future Release" because the final online help for GlassFish 4.0 has already been committed and is in translation.





missing max save post size bytes under network-confg/protocols/http-listener-1/http. (GLASSFISH-20164)

[GLASSFISH-20166] OLH: need to add this attribute to the help page Created: 04/Apr/13  Updated: 04/Apr/13

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

Type: Sub-task Priority: Major
Reporter: Anissa Lam Assignee: Mike Fitch
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Anissa Lam and Mike Fitch

 Description   

Refer to main task.



 Comments   
Comment by Mike Fitch [ 04/Apr/13 05:02 PM ]

Moving this to "Future Release". The final online help has already been committed and is in translation. If this issue is deemed a release blocker, please update its priority.





[GLASSFISH-20074] severe message about not cleaning threadlocal after accessing console and then shutdown server Created: 27/Mar/13  Updated: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Hong Zhang Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GLASSFISH-20538 Stop domain throws severe message Resolved
Related
is related to GLASSFISH-20056 Failed to load admin console, when re... Resolved
Tags:
Participants: Anissa Lam, Hong Zhang and Shing Wai Chan

 Description   

Start domain, go to localhost:4848 to access console (this will trigger the console application to be loaded), stop domain, and there are following severe messages:

[2013-03-27T09:02:41.566-0700] [glassfish 4.0] [SEVERE] [] [javax.enterprise.web.util] [tid: _ThreadID=132 _ThreadName=Thread-24] [timeMillis: 1364400161566] [levelValue: 1000] [[
The web application [] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@3f30c487]) and a value of type [org.glassfish.admingui.theme.AdminguiThemeContext] (value [org.glassfish.admingui.theme.AdminguiThemeContext@1ab69b7a]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.]]

[2013-03-27T09:02:41.569-0700] [glassfish 4.0] [SEVERE] [] [javax.enterprise.web.util] [tid: _ThreadID=132 _ThreadName=Thread-24] [timeMillis: 1364400161569] [levelValue: 1000] [[
The web application [] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@3f30c487]) and a value of type [org.glassfish.admingui.theme.AdminguiThemeContext] (value [org.glassfish.admingui.theme.AdminguiThemeContext@1ab69b7a]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.]]

Not sure if the messages are of any significance, or if the console team should be the one to take a look. Assign to web team for initial evaluation.



 Comments   
Comment by Shing Wai Chan [ 27/Mar/13 05:10 PM ]

The above message indicates that the ThreadLocal object is not cleanup.

Comment by Anissa Lam [ 29/Mar/13 12:05 AM ]

AdminguiThemeContext is created when console launch and plugged in either the community theme or the orcale branded one.
The actual creation of ThreadLocal is in the Woodstock code.
We are not seeing any ill effect, the msg occurs during domain shutdown and since this is in woodstock code, I am deferring this to 4.0.1.





[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-20039] Support of custom protocol in the codebase for EE policy and restricted polict for EE application packaged permission Created: 25/Mar/13  Updated: 28/Mar/13

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

Type: Bug Priority: Major
Reporter: spei Assignee: michael.y.chen
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: michael.y.chen and spei

 Description   

In the check in of revision 60776, the code base for EE module in a javaee.server.policy or restrict.server.policy we use following code base

file:/module/Ejb
file:/moduleWeb
etc.

Ideally, we should use a custom protocol here to avoid any confusion. Something like

aspc://module/Ejb
aspc://module/Web

or some protocol name better than 'aspc',






[GLASSFISH-20037] Investigate the Restricted Permissions vs Allowed Permissions (or Not restricted policy) for Application Packaged Permission feature Created: 25/Mar/13  Updated: 28/Mar/13

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

Type: Bug Priority: Major
Reporter: spei Assignee: spei
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: spei

 Description   

In the current commuted code (revision 60776), the domain restriction is through the restrict.server.policy file, this has following issues:

1) the AllPermission in restriction list means that the app declared permission can not include AllPermission, and does not mean the application can not declare other permissions. This is an exception compared to other entries in the restriction file, i.e., other entries are checked against the declared permissions by "imply" call.

2) By restriction list, the admin knows what he wants to restrict, but still has no full picture of what the application may get. An configured allowed list can limit the applications to have permissions exist on the allowed list, but the list might be long since an exhaustive list is needed. A metafile policy approach for the allowed list (or not-restricted policy) may be able to define restriction by following some syntax. A declared permission can be granted only if it is implied by a permission on the not restricted list. When the Not restricted list/collection is empty, no declared permission can be declared; including AllPermission.

We need to investigate this further from the points of security completeness, and also useability point of view.






[GLASSFISH-20035] Revise ASURLClassLoader and WebappClassLoader to allow pass in of permissions through the class constructor Created: 25/Mar/13  Updated: 27/Mar/13

Status: Open
Project: glassfish
Component/s: classloader, deployment
Affects Version/s: None
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: spei Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Sanjeeb Sahoo and spei

 Description   

ASURLClassLoader and WebappClassLoader have methods addDeclaredPermmissions and addEEPermissions(). Currently code based permission check are used to protect these two methods, so application code can not directly call them.

As discussed with Ron, a better/clean approach would be to refactor the ASURLClassLoader (and its derived classes) and WebappClassLoader constructors to allow the pass in of permissions.

Also, Module Handler.getClassLoader() needs a new overloaded version to allow pass permissions to the classloader.

The permissions to be passed in include two PermissionCollection sets. Maybe, just include com.sun.enterprise.security.integration.PermsHolder in the constructor, and in the getClassloader method.

After this bug is fixed, then I can refactor the addDeclaredPermmissions and addEEPermissions methods.



 Comments   
Comment by Sanjeeb Sahoo [ 27/Mar/13 04:40 AM ]

Too late to fix in 4.0





[GLASSFISH-19999] gf-client-module.jar isn't an OSGi module but it is in glassfish/modules Created: 22/Mar/13  Updated: 11/Apr/13

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

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

Tags: devx_web
Participants: Tim Quinn and Tom Mueller

 Description   

Every JAR file in the glassfish/modules directory adds to the overhead of server startup. So JAR files that are not OSGi modules should not be in that directory.

This issue is for moving gf-client-module.jar out of glassfish/modules, possibly to the glassfish/lib/appclient directory.

It is unclear how much of a performance gain would result from this. Since this bundle is in the "Installed" state, it isn't actually loaded into the server. So this is a low priority item as far as startup performance time improvement goes.



 Comments   
Comment by Tim Quinn [ 11/Apr/13 04:38 AM ]

The gf-client-module.jar is in fact an OSGi module, but it does not need to be used as such by the server.

The server does need access to it - it reads a class from it as a resource when an app client is deployed as part of generating a JAR for download to client systems. So moving the gf-client-module.jar to another directory where it will not be visible to the OSGi loading process is certainly feasible.

Some other parts of the system (the package_appclient utility) will also need to change to adjust to the file's new location.

All in all we should do this but not for 4.0, given the probably small payoff and numerous places we'd have to touch.





[GLASSFISH-19979] OSGi Console Requests Basic Login even if Server is Running with No Password Created: 21/Mar/13  Updated: 26/Mar/13

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

Type: Bug Priority: Major
Reporter: myfear Assignee: TangYong
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish Server Open Source Edition 4.0 (build 80)


Tags: fishcat
Participants: Anissa Lam, myfear, Sanjeeb Sahoo and TangYong

 Description   

Click on server(Admin Server)
Click on OSGi Console

Basic Auth Challenge:

"A username and password are being requested by http://localhost:8080. The site says: "GlassFish Server""

Server is running with no password.



 Comments   
Comment by TangYong [ 21/Mar/13 05:35 AM ]

Sahoo, Anissa,

In current trunk, OSGi Console has been removed from admin-gui, and that is to say, while clicking on server(Admin Server), "OSGi Console" does not exist.

So, for FishCat testing, whether the issue is valid or not?

If being invalid, whether needing to make an more clear description for FishCat testers about using which versions and which features needs to be tested?

Thanks
--Tang

Comment by Anissa Lam [ 25/Mar/13 03:06 PM ]

I am not aware of any plan of integrating OSGi console to admin console for GlassFish 4.0.
Transfer to Sahoo

Comment by Sanjeeb Sahoo [ 25/Mar/13 03:17 PM ]

Tang,

I don't understand what you mean by "In current trunk, OSGi Console has been removed from admin-gui." OSGi console extension was never part of default distribution in previous releases. It was always distributed via update centre as an extension.

The issue is valid, but I don't know how to fix. May be Anissa can tell us how they fix the login issue in admin console. Do they attempt to login without password when the first request is made?

Anyway, I am defering this issue to future release. It's not very important to be fixed in 4.0.

Sahoo

Comment by TangYong [ 26/Mar/13 01:32 AM ]

Sahoo

Maybe I have made a mistake that I saw the "OSGi Console" in my env because previously I downloaded OSGi Console from update center. So, I said "current ....".

Just as you said, the issue is not important for 4.0 release.

Tang

Comment by Sanjeeb Sahoo [ 26/Mar/13 08:11 AM ]

The behavior of the GlassFish when there is only one administrative user in the system is explained in [1] like this:

If the domain contains exactly one valid administrative account, then GlassFish considers that account to be the default admin account. If at any time there are at least two admin accounts, GlassFish treats no admin account as the default.

When you install GlassFish or create a new domain, GlassFish creates a default admin account, with default username "admin" and an empty default password. So suppose you have just installed GlassFish. If you send an admin request to the DAS with no username, the DAS will act as if your request had actually specified "admin" for the username. Specifying no password is equivalent to giving an empty password - which conveniently is the password for the out-of-the-box default admin account.

All this means that you can run asadmin commands – or use the admin console or submit REST requests – without having to specify an admin username or password. This is consistent with past releases of GlassFish.

So, we can try something like this in our Felix WebConsole Extension where we have implemented the security feature of OSGi console. We can try asking the system for default user name and use that along with an empty password. If we fail, we can prompt user with a password.

Anyway, we shall attempt it in a future release.

[1] https://blogs.oracle.com/quinn/entry/securing_adminstration_in_glassfish_server

Comment by TangYong [ 26/Mar/13 08:31 AM ]

Assigned to me to implement the issue in the future release.





[GLASSFISH-19889] [508] Foreground/background colour luminosity ratio is below 4:5:1 in GF 4.0 Created: 15/Mar/13  Updated: 31/May/13

Status: Reopened
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b78
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: RameshT Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

508 Windows 7 / FireFox 19.0 , GF 4.0 b78


Issue Links:
Duplicate
duplicates GLASSFISH-18053 [508] foreground/background colour lu... Resolved
Tags: admin-gui gf-4-0-508
Participants: Alex Pineda, Anissa Lam and RameshT

 Description   

OGHAG color contrast analyser testing reported more issues in the color.

Failures got in managed scheduled executor services is :

"16.36:1*. The Background Color of this element comes from a repeating background image. The contrast must be checked manually.The Text is small so target ratio is 4.5:1"

Received many failures like above on Context services, Managed thread factories and Managed executor services modules. Each modules has new and edit screens and in both the screen it is found.



 Comments   
Comment by Anissa Lam [ 20/Mar/13 05:25 PM ]

I believe this is already reported in GLASSFISH-18053
Andriy already analysis it and close it.
Marking as duplicate.

Comment by RameshT [ 08/Apr/13 01:27 PM ]

May be that is reported for other screen. As we are testing concurrency pages. We need to check the standards are available for concurrency pages.

Hence reopening the issue.

Comment by Anissa Lam [ 09/Apr/13 10:09 PM ]

Please send the report or screenshot to me as you cannot attach it here.
Since all the pages are using the same color, theme and styles, I don't want to open up 1 issue for each screen. The concurrency pages are very typical pages like other pages.

We will not be making changes to color, font size etc for this release. Marking this for future release.

Comment by Alex Pineda [ 31/May/13 05:26 PM ]

Changed the Synopsis description of the bug at the request of the Accessibility office.





[GLASSFISH-19888] [508] Empty and Multiple labels in Form Elements Created: 15/Mar/13  Updated: 11/Apr/13

Status: Reopened
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b78
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: RameshT Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

508 Windows 7 / FireFox 19.0 , GF 4.0 b78


Issue Links:
Duplicate
duplicates GLASSFISH-18164 [508] Duplicate labels in Form Elements Open
Tags: admin-gui gf-4-0-508
Participants: Anissa Lam and RameshT

 Description   

concurrency screen dont have lables for many text boxes. Also checkboxes has multiple lables for one single item. Error got in OGHAG is :
"ERROR: Multiple Labels found: Long running tasks: Enabled "
and
" text ERROR: Missing or Empty Label"



 Comments   
Comment by Anissa Lam [ 20/Mar/13 05:12 PM ]

This is described in GLASSFISH-18164. Marking as duplicate.

Comment by RameshT [ 08/Apr/13 01:22 PM ]

Here the bug is raised for the concurrency screen for the "missing lable". In GLASSFISH-18164 is raised due to duplicate labels are given on some other forms. According to the standard all the labels should contain the names and has to be fixed.

Hence I am reopening the issue.





[GLASSFISH-19873] investigate the use of generic CRUD command for resources, specifically those in the concurrent module Created: 14/Mar/13  Updated: 22/May/13

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

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

Tags:
Participants: kumara and Tom Mueller

 Description   

The concurrent module uses hand coded create/delete/list commands for its resources (config beans). The system provides generic CRUD commands that can reduce the amount of code needed and provide greater uniformity for the commands. However, the @Create, @Delete, and @Listing annotations have to be used on the container element, in this case <resources>. Since <resources> is an element defined by Nucleus and the concurrent resources are defined in appserver, it isn't possible to put these annotations on the Resources config bean, so the generic CRUD commands cannot currently be used.

This issue is for investigating if there is a way that the hand coded commands for resources could be replaced with generic CRUD commands.






[GLASSFISH-19864] schema-generation to drop table during undeploy Created: 13/Mar/13  Updated: 21/Mar/13

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.0_b79
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: sherryshen Assignee: Mitesh Meswani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHL6.2 and JDK1.7.0_10


Tags:
Participants: Mitesh Meswani and sherryshen

 Description   

glassfish-4.0-b79.zip
How to use schema-generation to drop table during undeploy.
Users can use eclipselink.ddl-generation to do so.
It is convenient for users.
I will provide examples next.



 Comments   
Comment by sherryshen [ 13/Mar/13 10:10 PM ]

Tests about drop table

1) With schema-generation property, the tabe is dropped, then created during deploy app.
After app is undeployed, the table is left in database.

appserver-sqe/pe/ejb/jpa20/war/schemageneration
persistence.xml has
<property name="javax.persistence.schema-generation.database.action" value="create-and-drop"/>
Do "ant all" to run tests and check the table SG_PROJ is left in database.
If other app has the same table name with different column or constraint, it
may have a problem to drop the table during deploy.

2) With EclipseLink properties, tables are dropped after undeploy.

appserver-sqe /pe/ ejb/jpa20/war/bvcallbackbmt/
persistence.xml has
<property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
Do "ant all" to run tests, the tables are dropped after undeploy.

Comment by Mitesh Meswani [ 21/Mar/13 01:38 AM ]

The current behavior is as defined by JPA 2.1 spec. I will request the spec lead to add support for "drop-tables-on-emf-close". Deferring this for future.





[GLASSFISH-19822] Multiple ClassNotFoundExceptions at server startup Created: 11/Mar/13  Updated: 04/Jul/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.2.2
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Architect.SoftWeb.ISD Assignee: Daniel
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

a. OS Windows7/ AIX5.3
b. java6 Oracle/IBM implementations


Tags:
Participants: Architect.SoftWeb.ISD and Daniel

 Description   

GF Multiple ClassNotFoundExceptions
1. Context

1. ISS-SWP-1353SC Migration To GlassFish
2. Description of software
a. OS Windows7/ AIX5.3
b. java6 Oracle/IBM implementations
c. GF 3.1.2.2
d. There is ear with 5 wars within.
i. 3 wars which includes JSF 1.2 (MyFaces1.2+RichFaces3.3.1) and custom jsf -components.
ii. The jsf-oriented wars have the following glassfish-web.xml

iii. The wars have the following amount of classes and interfaces (excluding third-party ones):
1. Jsf-oriented war1 - 1411 classes and interfaces
2. Jsf-oriented war2 - 2500 classes and interfaces
3. Jsf-oriented war3 - 1200 classes and interfaces
iv. jsf-oriented war3 along with JSF contains 22 JSP pages.
v. There are 2 non-jsf wars and one of them uses jersey1.14 which packaged within it.

2. Problem

2.1 Brief Description

1. There are multiple ClassNotFoundException (about SWP classes) exceptions which lead to creation of multiple gf server log files and at the end there are several GF threads blocked with java.util.logging.ConsoleHandler.
2. The multiple exceptions and their consequent logging slowdown start of ear application (which under WLS starts in 3 minutes) to 9 minutes and time to time it simply hangs.
3. GF has correspondent issues assigned (and still unresolved):
a. JSF oriented http://java.net/jira/browse/JAVASERVERFACES-1995
b. Jersey oriented http://java.net/jira/browse/GLASSFISH-16937
c. Another one http://java.net/jira/browse/GLASSFISH-19017
4. As workaround to the issue we up level of javax.enterprise.system.container.web logger level to SEVERE.

2.2 Complete Description

1. During researching of the problem by debugging/performance measurement correspondent GF sources the following facts were identified (see figure below):
a. ClassNotFoundException is result of asking WebappClassLoader to load class which belongs to other WebappClassLoader - but it is impossimble by javaee spec.
b. Wrong request to load unreachable class to WebappClassLoader is result of sharing by certain instance of org.glassfish.hk2.classmodel.reflect.Type knowledge (instances of org.glassfish.hk2.classmodel.reflect.ClassModel) about classes which belongs to different WebappClassLoader.
c. The steps which lead to the issue are part of GF internal activity to identify managed beans (JSF-Components, Jersey-Components and so on) of certain server initializers. The org.glassfish.web.loader.ServletContainerInitializerUtil class is part of the GF internal activity.
d. The Log Record 4 (see Appendix 3.1 chapter) shows that JSF-Components were searching even in context of non-jsf wars (all jsf-oriented wars contain RichFaces within their WEB-INF\lib).
e. Each cycle of "failed class loading and then logging" takes ~0.0006sec but amount of "failed" cycles is about hundred thousand times and in turn leads to losing of minutes (see some details here (see Appendix 3.2 chapter)).

3. Appendix
3.1 Examples of WEB9052 log records

1. [#|2013-03-05T10:29:43.180+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=17;_ThreadName=Thread-2;|WEB9052: Unable to load class com.softcomputer.softweb.pl.webuipl.softweb.component.sdc.businessobject.requisitiondetailseditor.impl.RequisitionDetailsEditorModelViewConverter$BillingMethodConverter, reason: java.lang.ClassNotFoundException: com.softcomputer.softweb.pl.webuipl.softweb.component.sdc.businessobject.requisitiondetailseditor.impl.RequisitionDetailsEditorModelViewConverter$BillingMethodConverter|#]

2. [#|2013-03-05T10:29:43.463+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=17;_ThreadName=Thread-2;|WEB9052: Unable to load class com.softcomputer.softweb.pl.webuipl.softweb.component.renderkit.standard.sdc.businessobject.authenticationeditor.impl.AuthenticationEditorUIComponentRenderer, reason: java.lang.ClassNotFoundException: com.softcomputer.softweb.pl.webuipl.softweb.component.renderkit.standard.sdc.businessobject.authenticationeditor.impl.AuthenticationEditorUIComponentRenderer|#]

3. [#|2013-03-05T10:29:44.393+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=17;_ThreadName=Thread-2;|WEB9052: Unable to load class com.softcomputer.softweb.pl.webuipl.softweb.component.sdc.businessobject.collectspecimenseditor.impl.CollectSpecimensEditorUIComponent, reason: java.lang.ClassNotFoundException: com.softcomputer.softweb.pl.webuipl.softweb.component.sdc.businessobject.collectspecimenseditor.impl.CollectSpecimensEditorUIComponent|#]

4. [#|2013-03-06T11:50:39.123+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=17;_ThreadName=Thread-2;|WEB9052: Unable to load class org.richfaces.component.html.HtmlDataFilterSlider, reason: java.lang.ClassNotFoundException: org.richfaces.component.html.HtmlDataFilterSlider|#]

3.2 Cycle of "failed class loading and then logging" performance measurement

The table depicts time consumption by related to "GF Multiple ClassNotFoundExceptions " issue code.
Note1: the measurement is done till the moment the GF hangs.
Note2: the table does not show all details of the measurement but depicts integral view and several rows of basic measurement:

ID of checkAgainst
InterestList() call ID of Fail within checkAgainst
InterestList() method Total Duration for failed class loading, (nsec) Total Duration for the fail Logging, (nsec) Total Duration spent for fail class loading and then logging, (nsec) Amount of failed class loading iterations
32,676,850,933 24,956,173,812 57,633,024,745 139,056
3 92787 299347 61439
3 92788 278525 68266
3 92789 285352 46079
3 92790 409938 64852
3 92791 316754 62122
3 92792 301735 45056
3 92793 250536 38912
3 92794 323240 55978
3 92795 264873 42666
3 92796 249512 40277
3 92797 262141 43690
3 92798 250195 40960
3 92799 237224 39595
3 92800 231080 39936
3 92801 218793 38570
3 92802 242003 38570
3 92803 255656 39253
3 92804 238590 39253
3 92805 232105 38229
3 92806 237224 38912



 Comments   
Comment by Architect.SoftWeb.ISD [ 11/Mar/13 03:32 PM ]

1. Pls give me correspondent permissions in order to attach:
1.1. description picture
1.2. test case for the issue (sample ear with several wars)

Comment by Daniel [ 25/Jun/13 11:13 PM ]

You should be able to attach files to this issue, there are several operation links on the left side.
If you still can not, please let me know.

BTW, if you are running on GF4, remember to update web.xml, use org.glassfish.jersey.servlet.ServletContainer API instead.

Comment by Architect.SoftWeb.ISD [ 01/Jul/13 09:51 AM ]

It looks like I can't still attach the files.
All that I see on the left side in section "Operations" are "Go to Planning Board", "Go to Task Board", "Clone this issue", "Comment on this issue", "Create sub-task", "Voting", "Watching" and last "You don't have permission to work on this issue."
I suppose there should present something like "Attach file to this issue" but I don't see it unfortunately.

Comment by Daniel [ 01/Jul/13 05:48 PM ]

Could you please send me by email?
daniel.guo@oracle.com

Thanks

Comment by Daniel [ 03/Jul/13 11:03 PM ]

I got the ear file you sent to me. And trying to deploy on GF4. I got some SEVERE logging message during deployment. Did you get those? Since this is not mentioned in your issue description.

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

[2013-07-03T11:59:13.863-0700] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1372877953863] [levelValue: 1000] [[
log4j:WARN No appenders could be found for logger (org.apache.myfaces.shared_impl.webapp.webxml.WebXmlParser).]]

[2013-07-03T11:59:13.863-0700] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1372877953863] [levelValue: 1000] [[
log4j:WARN Please initialize the log4j system properly.]]

[2013-07-03T11:59:14.182-0700] [glassfish 4.0] [SEVERE] [] [javax.faces] [tid: _ThreadID=40 _ThreadName=admin-listener(1)] [timeMillis: 1372877954182] [levelValue: 1000] [[
Unable to obtain InjectionProvider from init time FacesContext. Does this container implement the Mojarra Injection SPI?]]

[2013-07-03T11:59:14.192-0700] [glassfish 4.0] [SEVERE] [] [javax.faces] [tid: _ThreadID=40 _ThreadName=admin-listener(1)] [timeMillis: 1372877954192] [levelValue: 1000] [[
Unable to inject org.springframework.faces.webflow.FlowApplicationFactory@60e5618f because no InjectionProvider can be found. Does this container implement the Mojarra Injection SPI?]]

[2013-07-03T11:59:14.216-0700] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=40 _ThreadName=admin-listener(1)] [timeMillis: 1372877954216] [levelValue: 800] [[
Loading application gf_multipleCNFEs#jsf-oriented1.war at [/jsf-oriented1]]]

[2013-07-03T11:59:14.665-0700] [glassfish 4.0] [SEVERE] [] [javax.faces] [tid: _ThreadID=40 _ThreadName=admin-listener(1)] [timeMillis: 1372877954665] [levelValue: 1000] [[
Unable to obtain InjectionProvider from init time FacesContext. Does this container implement the Mojarra Injection SPI?]]

[2013-07-03T11:59:14.672-0700] [glassfish 4.0] [SEVERE] [] [javax.faces] [tid: _ThreadID=40 _ThreadName=admin-listener(1)] [timeMillis: 1372877954672] [levelValue: 1000] [[
Unable to inject org.springframework.faces.webflow.FlowApplicationFactory@9bde349 because no InjectionProvider can be found. Does this container implement the Mojarra Injection SPI?]]

Comment by Architect.SoftWeb.ISD [ 04/Jul/13 09:25 AM ]

We did not try to start the ear under GF4 unfortunately.
Even starting of our product under GF3 was a big challenge for us because we had a lot of non-recent libs like MyFaces 1.2.6 (implementation of JSF 1.2) and because of inability to use something like <prefer-application-packages> from weblogic-application.xml like in case of WebLogic to replace default implementation of JSF with ours.

Concerning the messages I have such supposals:
1).No appenders could be found for logger
It looks like log4j need to be configured.
We usually set system variable -Dlog4j.configuration
I tried to start the ear under GF3.1.2 without log4j configured and got similar traces
[#|2013-07-04T12:35:01.979+0300|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-2;|log4j:WARN No appenders could be found for logger (org.apache.myfaces.shared_impl.webapp.webxml.WebXmlParser).|#]
[#|2013-07-04T12:35:01.980+0300|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-2;|log4j:WARN Please initialize the log4j system properly.|#]

2)."Does this container implement the Mojarra Injection SPI" and "Unable to inject org.springframework.faces.webflow.FlowApplicationFactory"
I suppose these messages concern usage of MyFaces 1.2.6 (JSF 1.2) inside the ear and so the conflict with Mojarra implementation of JSF provided with GF.
These ones do not appear under GF3.1.2.

So in case "ClassNotFoundException" messages appear anyway and deployment does not fail I suppose the ones stated by you may be ignored.





[GLASSFISH-19816] Package jline separately Created: 10/Mar/13  Updated: 10/Mar/13

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

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Sanjeeb Sahoo and Snjezana Sevo-Zenzerovic

 Description   

GLASSFISH-19124 introduces jline library in glassfish, but it packages it inside osgi-cli-interactive.jar. In future consider making available jline for subsystems to use by packaging it as a standalone bundle.






[GLASSFISH-19812] Prevent usage of proprietary API" warnings issued by java compiler during maven build, using compiler option Created: 08/Mar/13  Updated: 05/Mar/14

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

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

Issue Links:
Dependency
depends on GLASSFISH-20980 Convert private JDK API usage to new ... Resolved
depends on GLASSFISH-19811 usage of internal proprietary API in... Open
depends on GLASSFISH-19806 usage of internal proprietary API in... Open
depends on GLASSFISH-19809 usage of internal proprietary API in... Open
depends on GLASSFISH-19805 usage of internal proprietary API in... Open
depends on GLASSFISH-19801 usage of internal proprietary API in... Open
depends on GLASSFISH-19799 usage of internal proprietary API in... Open
depends on GLASSFISH-19798 usage of internal proprietary API in ... Open
depends on GLASSFISH-19804 usage of internal proprietary API in... Open
depends on GLASSFISH-19802 usage of internal proprietary API in... Open
depends on GLASSFISH-19803 usage of internal proprietary API in... Open
depends on GLASSFISH-19810 usage of internal proprietary API in... Resolved
depends on GLASSFISH-19808 usage of internal proprietary API in... Resolved
Related
is related to GLASSFISH-2888 Try to use standard JDK classes only Resolved
Tags: maven build warning proprietary-api
Participants: Joe Di Pol, Romain Grécourt and Tim Quinn

 Description   

Get rid of all the warning "is internal proprietary API and may be removed in a future release" echoed by the java compiler during the maven build.

Then we can enforce a compiler flag to prevent the introduction of any new warning.



 Comments   
Comment by Romain Grécourt [ 08/Mar/13 05:58 PM ]

linking separate issues

Comment by Tim Quinn [ 13/Feb/14 04:14 PM ]

Adding link to another issue for a private API usage





[GLASSFISH-19811] usage of internal proprietary API in nucleus/common/common-util Created: 08/Mar/13  Updated: 08/Mar/13

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

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

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: common-util maven build warning proprietary-api
Participants: Byron Nevins, Romain Grécourt and Tom Mueller

 Description   
[WARNING]  nucleus/common/common-util/src/main/java/com/sun/enterprise/universal/GFBase64Decoder.java:[50,45] BASE64Decoder is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/common/common-util/src/main/java/com/sun/enterprise/universal/GFBase64Encoder.java:[50,46] BASE64Encoder is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/common/common-util/src/main/java/com/sun/enterprise/universal/GFBase64Decoder.java:[50,45] BASE64Decoder is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/common/common-util/src/main/java/com/sun/enterprise/universal/GFBase64Encoder.java:[50,46] BASE64Encoder is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/common/common-util/src/main/java/com/sun/enterprise/universal/GFBase64Decoder.java:[50,45] BASE64Decoder is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/common/common-util/src/main/java/com/sun/enterprise/universal/GFBase64Encoder.java:[50,46] BASE64Encoder is internal proprietary API and may be removed in a future release

Tests:

[WARNING]  nucleus/common/common-util/src/test/java/com/sun/enterprise/universal/BASE64DecoderTest.java:[82,16] BASE64Decoder is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/common/common-util/src/test/java/com/sun/enterprise/universal/BASE64DecoderTest.java:[82,56] BASE64Decoder is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/common/common-util/src/test/java/com/sun/enterprise/universal/BASE64DecoderTest.java:[83,16] BASE64Encoder is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/common/common-util/src/test/java/com/sun/enterprise/universal/BASE64DecoderTest.java:[83,56] BASE64Encoder is internal proprietary API and may be removed in a future release


 Comments   
Comment by Romain Grécourt [ 08/Mar/13 05:47 PM ]

Tom, I was not able to find the right component.
Please forward this to the right component / assignee.

Thanks.

Comment by Tom Mueller [ 08/Mar/13 08:02 PM ]

Assigning to Byron since he was the last to modify this file.





[GLASSFISH-19809] usage of internal proprietary API in nucleus/security/core Created: 08/Mar/13  Updated: 08/Mar/13

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

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

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: security maven build warning proprietary-api
Participants: JeffTancill and Romain Grécourt

 Description   
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[53,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/realm/certificate/CertificateRealm.java:[63,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[70,24] ContentInfo is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[71,24] PKCS7 is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[72,24] SignerInfo is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[73,24] AlgorithmId is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[74,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/realm/ldap/LDAPRealm.java:[69,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[252,30] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[504,18] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[504,42] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[686,12] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[686,33] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[686,66] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/realm/certificate/CertificateRealm.java:[286,46] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/common/iiop/security/GSSUPName.java:[45,27] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/common/iiop/security/GSSUtilsContract.java:[56,29] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/common/iiop/security/GSSUtilsContract.java:[58,37] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/common/iiop/security/GSSUtilsContract.java:[60,11] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[213,12] PKCS7 is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[213,30] PKCS7 is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[214,24] AlgorithmId is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[214,38] AlgorithmId is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[215,24] ContentInfo is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[217,24] SignerInfo is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[217,41] SignerInfo is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[218,25] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[220,24] AlgorithmId is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[221,24] AlgorithmId is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/realm/ldap/LDAPRealm.java:[368,12] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/realm/ldap/LDAPRealm.java:[368,32] X500Name is internal proprietary API and may be removed in a future release





[GLASSFISH-19806] usage of internal proprietary API in appserver/common/glassfish-ee-api Created: 08/Mar/13  Updated: 08/Mar/13

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

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

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: common maven build warning proprietary-api
Participants: Romain Grécourt, Sanjeeb Sahoo and Tom Mueller

 Description   
{nofomat}
[WARNING] appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/ClassLoaderUtil.java:[54,15] URLClassPath is internal proprietary API and may be removed in a future release
[WARNING] appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/ClassLoaderUtil.java:[114,32] URLClassPath is internal proprietary API and may be removed in a future release
[WARNING] appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/ClassLoaderUtil.java:[115,29] URLClassPath is internal proprietary API and may be removed in a future release
[WARNING] appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/ClassLoaderUtil.java:[116,29] URLClassPath is internal proprietary API and may be removed in a future release
[WARNING] appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/ClassLoaderUtil.java:[118,44] URLClassPath is internal proprietary API and may be removed in a future release
[WARNING] appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/ClassLoaderUtil.java:[200,12] URLClassPath is internal proprietary API and may be removed in a future release
[WARNING] appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/ClassLoaderUtil.java:[200,32] URLClassPath is internal proprietary API and may be removed in a future release{nofomat}

 Comments   
Comment by Romain Grécourt [ 08/Mar/13 05:33 PM ]

Tom, I was not able to find a component for this.
Can you please forward this to the right person ?

Thanks.

Comment by Tom Mueller [ 08/Mar/13 08:48 PM ]

Guessing at the category (since ClassLoader is in the name of the class).





[GLASSFISH-19805] usage of internal proprietary API in appserver/security/webintegration Created: 08/Mar/13  Updated: 08/Mar/13

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

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

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: security maven build warning proprietary-api
Participants: JeffTancill and Romain Grécourt

 Description   
[WARNING]  appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java:[75,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java:[596,16] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java:[596,37] X500Name is internal proprietary API and may be removed in a future release





[GLASSFISH-19804] usage of internal proprietary API in appserver/persistence/cmp/enhancer Created: 08/Mar/13  Updated: 08/Mar/13

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

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

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: cmp maven build warning proprietary-api
Participants: Mitesh Meswani and Romain Grécourt

 Description   
[WARNING]  appserver/persistence/cmp/enhancer/src/main/java/com/sun/jdo/api/persistence/enhancer/EnhancerClassLoader.java:[60,15] Resource is internal proprietary API and may be removed in a future release
[WARNING]  appserver/persistence/cmp/enhancer/src/main/java/com/sun/jdo/api/persistence/enhancer/EnhancerClassLoader.java:[61,15] URLClassPath is internal proprietary API and may be removed in a future release
[WARNING]  appserver/persistence/cmp/enhancer/src/main/java/com/sun/jdo/api/persistence/enhancer/EnhancerClassLoader.java:[109,15] URLClassPath is internal proprietary API and may be removed in a future release
[WARNING]  appserver/persistence/cmp/enhancer/src/main/java/com/sun/jdo/api/persistence/enhancer/EnhancerClassLoader.java:[124,18] URLClassPath is internal proprietary API and may be removed in a future release
[WARNING]  appserver/persistence/cmp/enhancer/src/main/java/com/sun/jdo/api/persistence/enhancer/EnhancerClassLoader.java:[160,18] URLClassPath is internal proprietary API and may be removed in a future release
[WARNING]  appserver/persistence/cmp/enhancer/src/main/java/com/sun/jdo/api/persistence/enhancer/EnhancerClassLoader.java:[173,18] URLClassPath is internal proprietary API and may be removed in a future release
[WARNING]  appserver/persistence/cmp/enhancer/src/main/java/com/sun/jdo/api/persistence/enhancer/EnhancerClassLoader.java:[539,20] Resource is internal proprietary API and may be removed in a future release
[WARNING]  appserver/persistence/cmp/enhancer/src/main/java/com/sun/jdo/api/persistence/enhancer/EnhancerClassLoader.java:[570,43] Resource is internal proprietary API and may be removed in a future release





[GLASSFISH-19803] usage of internal proprietary API in appserver/orb/org-iiop Created: 08/Mar/13  Updated: 08/Mar/13

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

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

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: orb maven build warning proprietary-api
Participants: Harshad Vilekar and Romain Grécourt

 Description   
[WARNING]  appserver/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/RoundRobinPolicy.java:[45,29] IiopUrl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/RoundRobinPolicy.java:[45,29] IiopUrl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/RoundRobinPolicy.java:[45,29] IiopUrl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/RoundRobinPolicy.java:[295,22] IiopUrl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/RoundRobinPolicy.java:[295,48] IiopUrl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/RoundRobinPolicy.java:[403,44] IiopUrl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/RoundRobinPolicy.java:[405,8] IiopUrl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/RoundRobinPolicy.java:[406,17] IiopUrl is internal proprietary API and may be removed in a future release





[GLASSFISH-19802] usage of internal proprietary API in appserver/ejb/ejb.security Created: 08/Mar/13  Updated: 08/Mar/13

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

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: michael.y.chen
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: ejb security maven build warning proprietary-api
Participants: michael.y.chen and Romain Grécourt

 Description   
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecurityMechanismSelector.java:[81,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[67,24] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[68,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[69,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtilsService.java:[48,24] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[65,24] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[66,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[68,24] X509CertImpl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[69,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[45,24] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[46,24] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[47,24] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecurityMechanismSelector.java:[81,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[67,24] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[68,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[69,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtilsService.java:[48,24] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[65,24] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[66,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[68,24] X509CertImpl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[69,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[45,24] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[46,24] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[47,24] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecurityMechanismSelector.java:[81,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[67,24] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[68,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[69,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtilsService.java:[48,24] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[65,24] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[66,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[68,24] X509CertImpl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[69,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[45,24] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[46,24] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[47,24] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecurityMechanismSelector.java:[950,39] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecurityMechanismSelector.java:[951,35] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecurityMechanismSelector.java:[1533,16] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecurityMechanismSelector.java:[1533,37] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecurityMechanismSelector.java:[1536,31] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[187,8] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[187,34] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[188,8] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[193,12] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[195,12] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[195,33] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[207,25] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[209,32] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtilsService.java:[62,29] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtilsService.java:[66,37] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtilsService.java:[70,11] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[265,12] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[265,33] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[271,26] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[289,12] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[289,37] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[295,12] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[297,28] X509CertImpl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[308,35] X509CertImpl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[69,24] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[71,24] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[76,24] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[83,8] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[89,20] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[98,20] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[107,20] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[152,36] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[181,8] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[209,40] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[239,8] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[263,44] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[305,32] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[312,1] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[312,27] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[331,19] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[334,9] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[334,34] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[335,9] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[361,44] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[397,38] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[431,41] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[459,8] ObjectIdentifier is internal proprietary API and may be removed in a future release





[GLASSFISH-19801] usage of internal proprietary API in appserver/verifier/verifier-impl Created: 08/Mar/13  Updated: 08/Mar/13

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

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

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: verifier maven build warning proprietary-api
Participants: Romain Grécourt and Sanjeeb Sahoo

 Description   

[INFO] Compiling 652 source files to appserver/verifier/verifier-impl/target/classes
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/VerifierTest.java:[65,40] XPathAPI is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/VerifierTest.java:[66,40] NodeSet is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/VerifierTest.java:[67,44] PrefixResolver is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/VerifierTest.java:[71,48] XObject is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/XpathPrefixResolver.java:[45,44] PrefixResolverDefault is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/XpathPrefixResolver.java:[47,41] PrefixResolverDefault is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELClassFile.java:[61,49] ClassParser is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELClassFile.java:[62,49] ConstantClass is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELClassFile.java:[63,49] DescendingVisitor is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELClassFile.java:[64,49] EmptyVisitor is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELClassFile.java:[65,49] Field is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELClassFile.java:[66,49] JavaClass is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELClassFile.java:[67,49] Method is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELClassFile.java:[250,34] EmptyVisitor is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELClassFileLoader1.java:[53,44] ClassPath is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/VerifierTest.java:[413,12] XObject is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/VerifierTest.java:[414,30] PrefixResolver is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/VerifierTest.java:[413,29] XPathAPI is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/VerifierTest.java:[437,26] XPathAPI is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/VerifierTest.java:[460,12] NodeSet is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/VerifierTest.java:[460,29] NodeSet is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/VerifierTest.java:[460,37] XPathAPI is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/VerifierTest.java:[474,12] XObject is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/VerifierTest.java:[475,30] PrefixResolver is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/VerifierTest.java:[474,29] XPathAPI is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/VerifierTest.java:[477,12] NodeSet is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/VerifierTest.java:[477,29] NodeSet is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELClassFile.java:[80,12] JavaClass is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELClassFile.java:[106,17] ClassParser is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELClassFile.java:[116,17] ClassParser is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELClassFile.java:[127,26] DescendingVisitor is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELClassFile.java:[259,39] ConstantClass is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELClassFile.java:[273,31] Field is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELClassFile.java:[282,45] Method is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELMethod.java:[54,54] Method is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELMethod.java:[59,64] Method is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELClassFileLoader1.java:[70,12] ClassPath is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/apiscan/classfile/BCELClassFileLoader1.java:[84,17] ClassPath is internal proprietary API and may be removed in a future release
[WARNING] appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/util/VerifierFormatter.java:[58,35] GetPropertyAction is internal proprietary API and may be removed in a future release






[GLASSFISH-19800] usage of internal proprietary API in appserver/security/inmemory.jacc.provider Created: 08/Mar/13  Updated: 08/Mar/13

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

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

Tags: security maven build warning proprietary-api
Participants: JeffTancill and Romain Grécourt

 Description   
[WARNING] appserver/security/inmemory.jacc.provider/src/main/java/com/sun/enterprise/security/jacc/provider/SimplePolicyProvider.java:[86,50] PolicyFile is internal proprietary API and may be removed in a future release





[GLASSFISH-19799] usage of internal proprietary API in appserver/security/appclient.security Created: 08/Mar/13  Updated: 08/Mar/13

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

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

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: appclient security build warning proprietary-api
Participants: JeffTancill and Romain Grécourt

 Description   
[WARNING] main/appserver/security/appclient.security/src/main/java/com/sun/enterprise/security/appclient/ConfigXMLParser.java:[59,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] main/appserver/security/appclient.security/src/main/java/com/sun/enterprise/security/appclient/ConfigXMLParser.java:[59,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] main/appserver/security/appclient.security/src/main/java/com/sun/enterprise/security/appclient/ConfigXMLParser.java:[59,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] main/appserver/security/appclient.security/src/main/java/com/sun/enterprise/security/appclient/ConfigXMLParser.java:[174,28] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] main/appserver/security/appclient.security/src/main/java/com/sun/enterprise/security/appclient/ConfigXMLParser.java:[177,38] PropertyExpander is internal proprietary API and may be removed in a future release


 Comments   
Comment by Romain Grécourt [ 08/Mar/13 05:18 PM ]

update affect version





[GLASSFISH-19798] usage of internal proprietary API in appserver/security/core-ee Created: 08/Mar/13  Updated: 08/Mar/13

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

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

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: build warning security proprietary-api
Participants: JeffTancill and Romain Grécourt

 Description   
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[53,24] Debug is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[54,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[55,24] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java:[54,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[105,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyUtil.java:[48,18] ParseUtil is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyUtil.java:[49,24] Debug is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyUtil.java:[50,24] Password is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/config/ConfigDomainParser.java:[68,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/config/ConfigDomainParser.java:[69,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/config/ConfigDomainParser.java:[69,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[116,25] Debug is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[116,39] Debug is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[127,8] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[133,8] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[138,12] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[233,32] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[264,10] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[299,10] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[372,3] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[385,3] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[435,7] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[443,7] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[462,7] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[505,5] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[529,11] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[543,20] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[557,11] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[568,23] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[607,10] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[621,39] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[671,23] ParseUtil is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[742,11] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[746,13] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[824,7] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[827,29] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[995,33] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[1222,3] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[1230,44] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyConfigurationImpl.java:[798,37] PolicyFile is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyConfigurationImpl.java:[870,17] ParseUtil is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java:[158,56] PolicyFile is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java:[561,20] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java:[569,26] ParseUtil is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java:[599,25] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java:[615,25] ParseUtil is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[433,20] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[433,45] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[434,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[435,20] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[435,45] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[436,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyWrapper.java:[75,56] PolicyFile is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyUtil.java:[77,12] ParseUtil is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyUtil.java:[94,2] Debug is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyUtil.java:[146,35] Password is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/config/ConfigDomainParser.java:[213,4] PropertyExpander is internal proprietary API and may be removed in a future release


 Comments   
Comment by Romain Grécourt [ 08/Mar/13 05:12 PM ]

change fix version





[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-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-19759] Support binding to OSGi services at deploy-time Created: 01/Mar/13  Updated: 25/Mar/13

Status: Open
Project: glassfish
Component/s: cdi, OSGi-JavaEE
Affects Version/s: None
Fix Version/s: future release

Type: Improvement Priority: Minor
Reporter: Sivakumar Thyagarajan Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: osgi-cdi osgi-javaee future-release
Participants: Sivakumar Thyagarajan and TangYong

 Description   

Today the osgi-cdi portable extension supports the injection of OSGi Services into injection points marked with a custom OSGi Qualifier @OSGiService. Unfortunately this binds application components that reference these Services at deployment time to OSGi. There could be scenarios where the determination that a Service being injected is an OSGi Service, can be made at deployment-time based on the environment that the application component is part of. It would be good if we have the ability for a client of an OSGi Service to indicate that the Service is an OSGi Service at deploy-time.



 Comments   
Comment by Sivakumar Thyagarajan [ 01/Mar/13 09:15 AM ]

One approach to consider is providing a capability to a deployer (through a custom deployment-descriptor) to specify that a particular injection point is an OSGi Service injection point, and have the osgi-cdi portable extension read this descriptor and automatically add the @OSGiService qualifier at runtime.

Comment by TangYong [ 01/Mar/13 10:02 AM ]

Siva,

The capability is very important while combining PaaS model, and in PaaS, ServiceType can be extended into OSGi Service, then, an user can specify an OSGi Service as some PaaS Service in liking glassfish-services.xml.

Then, by discovering OSGi Service engine(to be implemented in the future), these OSGi Services meeting the user's requirements will be injected into client at runtime.

Tang

Comment by TangYong [ 25/Mar/13 01:56 PM ]

Seeing siva's said carefully, Siva's means should be following,

[Current OSGi/CDI portable extension]
Class A{ @OSGiService B b ... }

The issue should wish to remove @OSGiService instead still using @Inject and adding some way to tell deployment to automatically determinate b is a OSGi Service.

Then, if using a custom deployment-descriptor, this is similar to Declarative Services, OK, let us to see this will bring what advantage?

Imaging a scene that some user has written a application which uses common cdi with well-designed interface, however, while he/she wants to switch another B's implementation and does not change any consumer's source, by this feature, he/she should implement.

Comment by Sivakumar Thyagarajan [ 25/Mar/13 04:19 PM ]

Yes, Tang.

The idea is to support the following:

  • Allow the development of POJOs and dependency injection not knowing during development time that a particular injection point would be satisfied through an OSGi Service. So in the above example, the application includes a POJO
    Class A { @Inject StockQuoteService b; }
  • At deployment time, we should allow the deployer to override the injection and indicate that the injection point A.b is an OSGi Service injection and provide the details through a custom deployment-descriptor. For instance here is a rough idea on how a deployer could state that the injectin point A.b is an OSGi Service.
    glassfish-osgi-cdi.xml:
    <osgi-service dynamic="true">
    <managed-bean name="A">
    <attribute name ="b"/>
    </managed-bean>
    </osgi-service>
  • The osgi-cdi portable extension must read this optional custom deployment-descriptor, and automatically at deployment time, make A.b have a qualified @OSGiService.

Does this help? All the above details are just ideas at this point in time. Let us evaluate how best to resolve this.





[GLASSFISH-19737] Provide default properties in create-jms-resource for admin gui Created: 28/Feb/13  Updated: 28/Feb/13

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

Type: Improvement Priority: Major
Reporter: David Zhao Assignee: David Zhao
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: David Zhao

 Description   

Currently when creating new jms connection factory via the admin gui, it makes REST calls to create-connector-connection-pool and create-connector-resource separately. It is expected to be changed to call create-jms-resource REST service. But now the REST service of create-jms-resource doesn't return all the default values of create-connector-connection-pool and create-connector-resource. We need find a way to allow it for the admin gui use.






[GLASSFISH-19691] Remove FighterFishStartupService and remove the org.glassfish.api.Startup interface Created: 18/Feb/13  Updated: 22/Apr/13

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

Type: Improvement Priority: Major
Reporter: jwells Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: jwells and Sanjeeb Sahoo

 Description   

FighterFishStartupService was added and the Startup interface was kept so that the org.glassfish.osgijpa.extension.JPAStartupService in FighterFish could continue to work. However, the Startup interface has been deprecated and the mechanism behind it has been removed. Instead the JPAStartupService should use the new startup mechanism with the new RunLevelService.



 Comments   
Comment by jwells [ 25/Feb/13 09:26 PM ]

Since you have changed fighterfish to work only on GlassFish 4, you can do a couple things:

1. You can run the hk2-inhabitant-generator directly rather than hard-coding the locator file
2. You can remove the Startup interface
3. You can change the JPAStartupService to be in the properly RunLevel context

Comment by Sanjeeb Sahoo [ 26/Feb/13 12:19 AM ]

No, we have not changed fighterfish to work only with GF 4.0. We had to treat osgi-ee-resources module as an exception because we had specifically agreed with them at 3.x time.





[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-19635] appclient.bat fails when 8.3 support is disabled Created: 04/Feb/13  Updated: 14/Feb/13

Status: Open
Project: glassfish
Component/s: standalone_client
Affects Version/s: 3.1.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: mkarg Assignee: Tim Quinn
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7 Pro 64 Bit
8.3 support is disabled


Tags:
Participants: mkarg and Tim Quinn

 Description   

For backwards compatibility, Windows is able to provide a 8.3-shortened name for each file and folder. As most people do not need that (most software is able to deal with longer paths), some administrators switch off this support. As a result, commands like DIR /X (which depend on 8.3 support) do not work anymore.

One consequence is that the GlassFish batches will not work anymore, as it uses commands like "%%~sa%" in e. g. appclient.bat. The used option (~s) is dependend of enabled 8.3 support.

As GlassFish is not really dependend on 8.3 files but simply uses ~s as a trick (8.3 guarantees to have no blanks in paths) this should be fixed in a future release. It makes no sense to force Windows administrators to keep 8.3 support enabled, just because some batch programmers did not find another way to deal with blanks in paths (tip: Use Java instead of batch).



 Comments   
Comment by Tim Quinn [ 14/Feb/13 04:08 PM ]

Marking this for fix in a future release, because it does not affect the SDK.





[GLASSFISH-19612] Disabling SSL key generation for faster domain creation Created: 01/Feb/13  Updated: 22/May/13

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

Type: New Feature Priority: Major
Reporter: abien Assignee: kumara
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Tags: asadmin
Participants: abien, kumara, Tim Quinn and Tom Mueller

 Description   

asadmin create-domain --portbase ... creates a fully functional domain, even with SSL support. This command runs in my environment on each push / commit so the performance is crucial. SSL key generation seems to talk the major portion of the entire time. It would be nice to disable SSL key in test environments.

e.g. asadmin create-domain --portbase 5300 --nossl



 Comments   
Comment by Tom Mueller [ 01/Feb/13 02:14 PM ]

Seems like a good idea. We'd need to handle the clustering case, because clustering administration always uses SSL now.

Comment by abien [ 02/Feb/13 05:39 AM ]

Clustering is usually not important for local testing. I'm trying to create a new domain as quickly as possible from checked-in configuration, perform the tests and then destroy the domain again.

Comment by Tom Mueller [ 05/Feb/13 02:21 PM ]

Another possibility might be to ship the self-signed certificates in the domain template (creating it at build time) rather than creating them during the create-domain command.

Comment by Tim Quinn [ 05/Feb/13 03:47 PM ]

I do not think the certs should always be part of the domain template. That would mean that all domains created by every user would have the same certs. As it is today, the certs created during domain creation are unique.

We could consider adding an option to create-domain to suppress the cert creation and to use certs present in the template, but the default behavior should remain as it is for security reasons.

Comment by Tom Mueller [ 05/Feb/13 03:53 PM ]

Today, when a user unzips glassfish.zip on multiple hosts, all of those hosts have the same certs in the domain1 domain that is in glassfish.zip. How is that security issue any different? The same rationale for not shipping certs in the default domain template would also justify not shipping a pre-created "domain1" domain in glassfish.zip.

The certs that are created by default by create-domain use "localhost" in the CN and are not secure anyway since they are self-signed.

Comment by Tim Quinn [ 05/Feb/13 04:04 PM ]

The create-domain command, by default, uses the current system's host name, not localhost. Only the template certs (e.g., in the unzipped domain1) use localhost.

Check the output of the create-domain command and use keytool to inspect the certs in the keystore of the unzipped and you should see the difference.

Comment by abien [ 05/Feb/13 05:30 PM ]

> I do not think the certs should always be part of the domain template. That would mean that all domains created by every user would have the same certs. As it is today, the certs created during domain creation are unique.
>
> We could consider adding an option to create-domain to suppress the cert creation and to use certs present in the template, but the default behavior should remain as it is for security reasons.

Great! An additional flag for faster generation would help projects to create GF domains quickly in development, but would prevent accidental omission of SSL at the same time.





[GLASSFISH-19602] BootAMX error logged during shutdown, even though shutdown completes Created: 29/Jan/13  Updated: 29/Jan/13

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 3.1.2.2
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: Tim Quinn Assignee: prasads
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-18878 AMX errors prevent stopping (and remo... Resolved
Tags:
Participants: prasads and Tim Quinn

 Description   

Sometimes during shutdown the server logs a BootAMX error. I have pasted Luis's comments from his forum posting here, as well as his stack trace.

Hi gentlemen,

We keep finding this exception every time we stop/restart any instance

  • > "AMXStartupServiceNew.loadAMXMBeans:
    java.lang.IllegalStateException: BootAMX listener was not called"

After doing some digging I believe that the instance is properly shut down.
However, there seem to be some other processes happening right after that
which cause the exception.

I have browsed the web finding similar issues with no results. Hence I come
here.

This stack trace is coming from the instance's log file:

[#|2013-01-21T15:37:12.692-0700|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin.cluster|_ThreadID=47;_ThreadName=Thread-2;|Server
shutdown initiated|#]

[#|2013-01-21T15:37:14.821-0700|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=47;_ThreadName=Thread-2;|2013-01-21
15:37:14,821 PWAssessment[-1] INFO MessagingDispatcher.java:233
MessagingDispatcher - Shutting down transport LoopbackTransport
|#]

[#|2013-01-21T15:37:14.823-0700|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=47;_ThreadName=Thread-2;|2013-01-21
15:37:14,823 PWAssessment[-1] INFO MessagingDispatcher.java:233
MessagingDispatcher - Shutting down transport JMSTransport
|#]

[#|2013-01-21T15:37:14.832-0700|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=47;_ThreadName=Thread-2;|2013-01-21
15:37:14,831 PWAssessment[-1] INFO MessagingDispatcher.java:233
MessagingDispatcher - Shutting down transport HTTPTransport
|#]

[#|2013-01-21T15:37:14.870-0700|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=47;_ThreadName=Thread-2;|2013-01-21
15:37:14,870 PWBClinician[-1] INFO MessagingDispatcher.java:233
MessagingDispatcher - Shutting down transport LoopbackTransport
|#]

[#|2013-01-21T15:37:14.874-0700|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=47;_ThreadName=Thread-2;|2013-01-21
15:37:14,874 PWBClinician[-1] INFO MessagingDispatcher.java:233
MessagingDispatcher - Shutting down transport JMSTransport
|#]

[#|2013-01-21T15:37:14.881-0700|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=47;_ThreadName=Thread-2;|2013-01-21
15:37:14,881 PWBClinician[-1] INFO MessagingDispatcher.java:233
MessagingDispatcher - Shutting down transport HTTPTransport
|#]

[#|2013-01-21T15:37:14.928-0700|INFO|glassfish3.1.2|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=48;_ThreadName=Thread-2;|MQJMSRA_RA1101:
GlassFish MQ JMS Resource Adapter stopping...|#]

[#|2013-01-21T15:37:14.929-0700|INFO|glassfish3.1.2|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=48;_ThreadName=Thread-2;|MQJMSRA_RA1101:
GlassFish MQ JMS Resource Adapter stopped.|#]

[#|2013-01-21T15:37:14.929-0700|INFO|glassfish3.1.2|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service|_ThreadID=49;_ThreadName=Thread-2;|RAR7094:
jmsra shutdown successful.|#]

[#|2013-01-21T15:37:16.722-0700|INFO|glassfish3.1.2|javax.org.glassfish.gms.org.glassfish.gms|_ThreadID=47;_ThreadName=Thread-2;|GMSAD1008:
GMSAdapter for member: APOC-Assessment-n03x01 group: APOC-Assessment
received GlassfishEventType: server_shutdown|#]

[#|2013-01-21T15:37:16.724-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=47;_ThreadName=Thread-2;|GMS1096:
member: APOC-Assessment-n03x01 is leaving group: APOC-Assessment|#]

[#|2013-01-21T15:37:16.725-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=47;_ThreadName=Thread-2;|GMS1010:
Leaving GMS group: APOC-Assessment with shutdown type set to
InstanceShutdown|#]

[#|2013-01-21T15:37:16.729-0700|CONFIG|glassfish3.1.2|ShoalLogger|_ThreadID=50;_ThreadName=Thread-2;|GMS1065:
Completed processing outstanding master node messages for member:
APOC-Assessment-n03x01 group: APOC-Assessment outstandingMessages to
process: 0|#]

[#|2013-01-21T15:37:16.732-0700|INFO|glassfish3.1.2|ShoalLogger.monitor|_ThreadID=47;_ThreadName=Thread-2;|BlockingIOMulicastSender
monitoring stats: received: 30813 core poolsize:10 largest pool size:10
task count:30813 max queue size:0 rejected execution:0|#]

[#|2013-01-21T15:37:16.732-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=51;_ThreadName=Thread-2;|GMS1110:
Thread IP Multicast Listener for /228.9.158.231:13386 has completed.|#]

[#|2013-01-21T15:37:16.894-0700|INFO|glassfish3.1.2|ShoalLogger.monitor|_ThreadID=47;_ThreadName=Thread-2;|GMS1115:
router signal queue high water mark: 0 signal queue capacity: 600|#]

[#|2013-01-21T15:37:16.893-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=52;_ThreadName=Thread-2;|GMS1088:
MessageWindow thread for group: APOC-Assessment terminated due to shutdown
notification|#]

[#|2013-01-21T15:37:16.893-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=12;_ThreadName=Thread-2;|GMS1091:
View Window event processing thread for group: APOC-Assessment terminated
normally|#]

[#|2013-01-21T15:37:16.894-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=53;_ThreadName=Thread-2;|GMS1107:
SignalHandler task named GMS SignalHandler for Group-APOC-Assessment thread
exiting|#]

[#|2013-01-21T15:37:16.987-0700|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=47;_ThreadName=Thread-2;|Initialized
AMXStartupServiceNew in 27 ms, registered as
amx-support:type=amx-loader,name=startup|#]

[#|2013-01-21T15:37:17.096-0700|INFO|glassfish3.1.2|javax.enterprise.system.amx.org.glassfish.admin.amx.impl.mbean|_ThreadID=47;_ThreadName=Thread-2;|AMX024:
Register children for instance name APOC-Assessment-n03x01|#]

[#|2013-01-21T15:37:17.110-0700|INFO|glassfish3.1.2|javax.enterprise.system.amx.org.glassfish.admin.amx.impl.mbean|_ThreadID=47;_ThreadName=Thread-2;|AMX020:
AMX ComplianceMonitor: ValidationLevel = full, UnregisterNonCompliant =
false, LogInaccessibleAttributes = true|#]

[#|2013-01-21T15:37:17.147-0700|INFO|glassfish3.1.2|javax.enterprise.system.amx.org.glassfish.admin.amx.impl.config|_ThreadID=54;_ThreadName=Thread-2;|AMX012:
In AMXConfigLoader : Loading null|#]

[#|2013-01-21T15:37:18.089-0700|INFO|glassfish3.1.2|javax.enterprise.system.amx.org.glassfish.admin.amx.impl.config|_ThreadID=54;_ThreadName=Thread-2;|AMX013:
AMX domain config registered as amx:pp=/,type=domain|#]

[#|2013-01-21T15:37:18.346-0700|INFO|glassfish3.1.2|javax.enterprise.system.amx.org.glassfish.admin.amx.impl.j2ee.loader|_ThreadID=55;_ThreadName=Thread-2;|AMX014:
J2EEDomain registered at
amx:pp=/,type=J2EEDomain,j2eeType=J2EEDomain,name=amx|#]

[#|2013-01-21T15:37:18.349-0700|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=47;_ThreadName=Thread-2;|AMXStartupServiceNew:
AMX ready for use, DomainRoot = amx:pp=,type=domain-root|#]

[#|2013-01-21T15:37:18.350-0700|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=47;_ThreadName=Thread-2;|AMXStartupServiceNew.loadAMXMBeans:
java.lang.IllegalStateException: BootAMX listener was not called|#]

[#|2013-01-21T15:37:18.352-0700|WARNING|glassfish3.1.2|javax.enterprise.system.core.org.glassfish.kernel.event|_ThreadID=47;_ThreadName=Thread-2;|Exception
while dispatching an event
javax.management.RuntimeMBeanException: java.lang.RuntimeException:
java.lang.IllegalStateException: BootAMX listener was not called
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrow(DefaultMBeanServerInterceptor.java:856)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrowMaybeMBeanException(DefaultMBeanServerInterceptor.java:869)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:838)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at org.glassfish.admin.mbeanserver.BootAMX.bootAMX(BootAMX.java:163)
at
org.glassfish.admin.mbeanserver.AdminAuthorizedMBeanServer$Handler.amxDomain(AdminAuthorizedMBeanServer.java:154)
at
org.glassfish.admin.mbeanserver.AdminAuthorizedMBeanServer$Handler.isAMX(AdminAuthorizedMBeanServer.java:149)
at
org.glassfish.admin.mbeanserver.AdminAuthorizedMBeanServer$Handler.isAMX(AdminAuthorizedMBeanServer.java:142)
at
org.glassfish.admin.mbeanserver.AdminAuthorizedMBeanServer$Handler.isAllowed(AdminAuthorizedMBeanServer.java:136)
at
org.glassfish.admin.mbeanserver.AdminAuthorizedMBeanServer$Handler.invoke(AdminAuthorizedMBeanServer.java:101)
at $Proxy185.unregisterMBean(Unknown Source)
at
org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread.shutdown(JMXStartupService.java:239)
at
org.glassfish.admin.mbeanserver.JMXStartupService.shutdown(JMXStartupService.java:160)
at
org.glassfish.admin.mbeanserver.JMXStartupService.access$000(JMXStartupService.java:94)
at
org.glassfish.admin.mbeanserver.JMXStartupService$ShutdownListener.event(JMXStartupService.java:128)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at
com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:439)
at
com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
at
com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.stop(GlassFishDecorator.java:68)
at com.sun.enterprise.v3.admin.StopServer.doExecute(StopServer.java:70)
at
com.sun.enterprise.v3.admin.cluster.StopInstanceInstanceCommand.execute(StopInstanceInstanceCommand.java:94)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$2.run(CommandRunnerImpl.java:377)
Caused by: java.lang.RuntimeException: java.lang.IllegalStateException:
BootAMX listener was not called
at
org.glassfish.admin.amx.impl.AMXStartupService.loadAMXMBeans(AMXStartupService.java:247)
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.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27)
at
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
at javax.management.StandardMBean.invoke(StandardMBean.java:391)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
... 20 more
Caused by: java.lang.IllegalStateException: BootAMX listener was not called
at
org.glassfish.admin.amx.impl.AMXStartupService._loadAMXMBeans(AMXStartupService.java:376)
at
org.glassfish.admin.amx.impl.AMXStartupService.loadAMXMBeans(AMXStartupService.java:244)
... 31 more
|#]

[#|2013-01-21T15:37:18.355-0700|INFO|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=47;_ThreadName=Thread-2;|Shutdown
procedure finished|#]

This stack trace is coming from the domain's log file:

[#|2013-01-21T15:37:12.598-0700|INFO|glassfish3.1.2|org.glassfish.admingui|_ThreadID=121;_ThreadName=Thread-2;|
https://localhost:4848/management/domain/servers/server/APOC-Assessment-n03x01/stop-instance|#
]

[#|2013-01-21T15:37:12.608-0700|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin.cluster|_ThreadID=122;_ThreadName=Thread-2;|Instance
APOC-Assessment-n03x01 shutdown initiated|#]

[#|2013-01-21T15:37:16.720-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=25;_ThreadName=Thread-2;|GMS1092:
GMS View Change Received for group: APOC-Assessment : Members in view for
PEER_STOP_EVENT(before change analysis) are :
1: MemberId: APOC-Assessment-n01x01, MemberType: CORE, Address:
192.168.10.81:9140:228.9.158.231:13386
:APOC-Assessment:APOC-Assessment-n01x01
2: MemberId: APOC-Assessment-n02x01, MemberType: CORE, Address:
192.168.10.82:9200:228.9.158.231:13386
:APOC-Assessment:APOC-Assessment-n02x01
3: MemberId: server, MemberType: SPECTATOR, Address: 192.168.10.81:9119
:228.9.158.231:13386:APOC-Assessment:server
|#]

[#|2013-01-21T15:37:16.720-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=25;_ThreadName=Thread-2;|GMS1016:
Analyzing new membership snapshot received as part of event:
PEER_STOP_EVENT for member: APOC-Assessment-n03x01 of group:
APOC-Assessment|#]

[#|2013-01-21T15:37:16.720-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=25;_ThreadName=Thread-2;|GMS1017:
Received PlannedShutdownEvent Announcement from member:
APOC-Assessment-n03x01 with shutdown type: INSTANCE_SHUTDOWN of group:
APOC-Assessment|#]

[#|2013-01-21T15:37:16.720-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=111;_ThreadName=Thread-2;|GMS1008:
Sending PlannedShutdownSignals to registered Actions for shutdownType
INSTANCE_SHUTDOWN member: APOC-Assessment-n03x01 ...|#]


 Comments   
Comment by Tim Quinn [ 29/Jan/13 05:44 PM ]

This is related to part of 18878, a partial fix to which seemed to improve things a bit at least.

Comment by Tim Quinn [ 29/Jan/13 05:46 PM ]

A partial fix to 18878 made some improvement in this. Linking to that issue in case it's helpful.





[GLASSFISH-19582] Move AccessLog support on Grizzly level instead of WebContainer Created: 24/Jan/13  Updated: 24/Jan/13

Status: Open
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.0_b70
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: oleksiys Assignee: oleksiys
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-18244 Web Service calls are not logged on s... Open
Tags:
Participants: oleksiys

 Description   

Some HTTP based services (WebServices/EJB, appclient), which are using Grizzly HttpServer directly also require access log support.






[GLASSFISH-19554] EJB module is visible to every module Created: 18/Jan/13  Updated: 08/Feb/13

Status: Open
Project: glassfish
Component/s: classloader, deployment
Affects Version/s: None
Fix Version/s: future release

Type: Improvement Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Hong Zhang and Sanjeeb Sahoo

 Description   

My ear has following structure:
app.ear
ejb.jar (Contains ejb1/FooEjb.class)
web.war (Contains WEB-INF/classes/web1/FooServlet.class)

There is a Servlet in web.war which is able to load FooEjb.class using thread context class loader.

I believe this is because of the following lines of code in EarHandler.java:

if (md.getModuleType().equals(DOLUtils.ejbType())) {
// for ejb module, we just add the ejb urls
// to EarClassLoader and use that to load
// ejb module
URL[] moduleURLs =
((URLClassLoader)subCl).getURLs();
for (URL moduleURL : moduleURLs) { cl.addURL(moduleURL); }



 Comments   
Comment by Hong Zhang [ 08/Feb/13 09:38 PM ]

Have talked with Sahoo briefly about this, this is the expected behavior with the current implenmentation (the current behavior does not violate the EE spec, though does not implement the recommended behavior by the EE spec). There were previous efforts put in trying to follow the spec recommendation but it was discovered fairly hard to achieve with the current code base. Sahoo and I plan to revisit it and discuss in more details to see if it's possible to implement the spec's recommendation in a future release.





[GLASSFISH-19553] glassfish 3.1.2.2 logs severe messages with hibernate Created: 18/Jan/13  Updated: 09/Feb/13

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 3.1.2.2
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: esejfi Assignee: Mitesh Meswani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish Server Open Source Edition 3.1.2.2 (build 5)
Open Suse 11.4
Hibernate 3.6.7


Tags: glassfish glassfish-3-1-2-2 severe hibernate
Participants: esejfi, Hong Zhang and Mitesh Meswani

 Description   

When i start my ear and war project, i got lot of severe messages from Glassfish 3.1.2.2 :

[#|2013-01-15T13:18:28.536+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=63;_ThreadName=Thread-2;|179
[admin-thread-pool-8148(3)] INFO org.hibernate.cfg.Environment -
hibernate.properties not found

#]

[#|2013-01-15T13:18:28.539+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=63;_ThreadName=Thread-2;|182
[admin-thread-pool-8148(3)] INFO org.hibernate.cfg.Environment - Bytecode
provider name : javassist

#]

[#|2013-01-15T13:18:28.544+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=63;_ThreadName=Thread-2;|187
[admin-thread-pool-8148(3)] INFO org.hibernate.cfg.Environment - using JDK 1.4
java.sql.Timestamp handling

#]

[#|2013-01-15T13:18:28.634+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=63;_ThreadName=Thread-2;|277
[admin-thread-pool-8148(3)] INFO org.hibernate.ejb.Version - Hibernate
EntityManager 3.6.7.Final

#]

... a lot of severe messages mores



 Comments   
Comment by Hong Zhang [ 18/Jan/13 02:11 PM ]

Assign to Mitesh for initial evaluation as it's related to entity persistence.

Comment by esejfi [ 18/Jan/13 02:16 PM ]

I forgot to mention that the application works fine. I have got only these messages during startup/deployment





[GLASSFISH-19542] Out of the box OSGi JPA support as per the 4.3 Compendium Specification Created: 16/Jan/13  Updated: 11/Mar/13

Status: Open
Project: glassfish
Component/s: entity-persistence, OSGi, OSGi-JavaEE
Affects Version/s: 4.0_b70
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: aaronjwhiteside Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: aaronjwhiteside, Mitesh Meswani, mkeith and Sanjeeb Sahoo

 Description   

Out of the box OSGi JPA support as per the 4.3 Compendium Specification (http://www.osgi.org/download/r4v43/osgi.cmpn-4.3.0.pdf).

The upcoming release of JBoss 7.2 will have full native support for JPA in OSGi as per the 4.3 Compendium Specification.

Glassfish 4.0 should come with support out of the box.

I would recommend against using Gemini JPA as it's not really maintained (check the last release date) and does not provide support for JTA transactions or looking up JTA data sources.



 Comments   
Comment by Mitesh Meswani [ 16/Jan/13 07:48 PM ]

Assigning to Sahoo...

Comment by mkeith [ 17/Jan/13 02:45 PM ]

OSGi JPA support, as per the OSGi 4.3 Compendium Spec, does NOT include support for JTA transactions.

Many people have found Gemini JPA to be the best point OSGi JPA solution, in the spirit of what OSGi JPA tried to accomplish. In fact, there are very few actual bugs; the ones that are there are generally feature requests. The last 1.1 release included some advanced features that no other solution provides.

I also have to take issue with your incorrect statement that Gemini JPA is "not really maintained". 1.1 was released on Nov 15, 2012, only 2 months ago! The next one will be released in the June time frame.

Comment by aaronjwhiteside [ 17/Jan/13 03:22 PM ]

I understand the spec does not include support for JTA, I forgot to mention that this is an important feature for me.

I apologize for my incorrect statement, I swear I checked the release date and thought I saw that 1.1 was in 2010.

I think I am tainted by my previous experience with it, about a year ago with Glassfish 3.1.2, it just didn't work.

And if everyone thinks this is the best option, I still think it should be bundled with Glassfish 4.0.





[GLASSFISH-19512] Support setting JVM options without knowing the current setting Created: 09/Jan/13  Updated: 22/May/13

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

Type: Improvement Priority: Major
Reporter: ljnelson Assignee: kumara
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: asadmin create-jvm-options delete-jvm-options list-jvm-options
Participants: kumara and ljnelson

 Description   

asadmin provides exactly three commands to affect the JVM options that apply to GlassFish: create-jvm-options, delete-jvm-options and list-jvm-options.

Because of the nature of JVM options, some of which are unary and some of which take arguments, there are some common adjustments that are difficult to make.

For example, given a GlassFish with a current (hypothetical) maximum heap size setting of 256m, there is no way to change it to, say, 512m without first knowing that its current value is 256m.

In other words, to change this value one must do:

asadmin delete-jvm-options '-Xmx256m' # have to know it's 256m
asadmin create-jvm-options '-Xmx512m'

Maybe there needs to be an asadmin change-jvm-option command? Something like:

asadmin change-jvm-option -Xmx 512m # two operands: option and value

The behavior would be: change it if it's there, create it if it's not.

Correspondingly (or maybe alternatively) there would need to be an alteration made to delete-jvm-options so that one could specify the option name only and have all occurrences of that option (regardless of operand/value) deleted.



 Comments   
Comment by ljnelson [ 09/Jan/13 09:08 PM ]

What, you didn't like my description?





[OSGi/CDI] CDI + OSGi event admin (GLASSFISH-15365)

[GLASSFISH-19358] Adding fighterfish test cases Created: 19/Nov/12  Updated: 22/Nov/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: future release

Type: Sub-task Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Sanjeeb Sahoo and TangYong

 Description   

Currently, An implementation has been finished, and Needing to add fighterfish test cases:

[Test Requirements]
Adding 4 bundles, called FooInf, FooBean1,
FooBean2, BarInf, BarBean, the dependency relationships are as following:

1) FooInf and BarInf are pure OSGi bundles
2) FooBean1 is an implementation of FooInf, and FooBean2 is another implementation of FooInf.
3) BarBean is an implementation of BarInf.
4) FooBean1 and FooBean2 are registered as OSGi Services using @Publish
5) BarBean uses FooInf as @OSGiService.
6) BarBean has a OnServiceRegistered event callback method liking the following:
public void OnServiceRegistered(@Observes @ServiceContract(FooInf.class) ServiceRegistered event){ .... //Call FooBean2's method }

Firstly, we deploy FooInf and BarInf, then deploy FooBean1, deploy BarBean, finally we deploy FooBean2, if anything is ok, we should see that OnServiceRegistered can be called successfully and CDI/OSGi integration can notify BarBean that FooBean2 has been registered.

Of course, we can also deploy FooBean1 only and undeploy FooBean1, then deploy FooBean1 again, in this way, BarBean can be notified that an implementation of FooInf has been available.



 Comments   
Comment by TangYong [ 22/Nov/12 02:30 PM ]

Test cases need to add WAB scene(seeing GLASSFISH-19359)





[GLASSFISH-19266] list-applications command interface does not look correct Created: 31/Oct/12  Updated: 05/Mar/13

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

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Hong Zhang and Sanjeeb Sahoo

 Description   

Syntax of list-applications is shown below:
NAME
list-applications - lists deployed applications

SYNOPSIS
list-applications [--help]
[--long={false|true}] [--resources] [--subcomponents]
[--type type] [target]

When I look at acceptable values for --type, it looks to me that it is not same as what is allowed in --type argument in deploy command. This needs to be fixed. It should be in sync with deploy command.

Secondly, should --subcomponents not be renamed to --components? The man page refers to a non-existent command called list-sub-components which I think should be list-components.



 Comments   
Comment by Hong Zhang [ 31/Oct/12 03:00 PM ]

There is a asadmin list-sub-components command (the source code locates at main/appserver/deployment/javaee-core/src/main/java/org/glassfish/javaee/core/deployment). This command was there since very earlier time probably 8.*?

Yes, it might make sense to synch the --type values with deploy --type, but need to address the backward compatibility issue at the same time (the syntax for the --type was carried over from very eariler releases also)..

Comment by Sanjeeb Sahoo [ 02/Nov/12 05:24 PM ]

The problem is list-applications is a nucleus command where as list-sub-components is an appserver command, so if one is just using nucleus, the man page is referring to a non-existent command.

Comment by Hong Zhang [ 02/Nov/12 05:46 PM ]

I see. We would need to fix the man page for this.

Comment by Hong Zhang [ 05/Mar/13 02:04 PM ]

Based on discussions with Sahoo/Tom, we don't plan to do anything for this in this release. For doc part, the GlassFish distribution will include list-sub-components command so the link will still work. For synching the type option part, the semantics of the type option of deploy command and list-applications command are actually different (one is archive type which is one per application, the other is sniffer type which could be one or more per application). We will revisit this issue in later release to see if there is anything we want to do that time.





[GLASSFISH-19206] Improved Credential and SSL Configuration Created: 22/Oct/12  Updated: 14/Nov/12

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

Type: New Feature Priority: Major
Reporter: JeffTancill Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Remaining Estimate: 5 weeks
Time Spent: Not Specified
Original Estimate: 5 weeks

Tags:
Participants: JeffTancill

 Description   

SSL, trust stores, keystores and credential repositories are generally difficult areas to configure for Java EE environments. The configuration and management interfaces are vendor specific and non-standard.

In order to make application archives portable , we need to unify and simplify the approach to this configuration and provisioning. Standardizing the ability to provision keystores and metadata (as necessary) by bundling them with an application at deployment time will provide portability of this configuration.



 Comments   
Comment by JeffTancill [ 14/Nov/12 04:53 PM ]

Deferred for consideration in EE 8





[GLASSFISH-19203] Password Aliasing Created: 22/Oct/12  Updated: 19/Mar/13

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

Type: New Feature Priority: Major
Reporter: JeffTancill Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Remaining Estimate: 6 weeks
Time Spent: Not Specified
Original Estimate: 6 weeks

Tags: ee7platspec
Participants: JeffTancill

 Description   

Best practices and common enterprise security policies dictate that we not store any passwords in clear text on the filesystem. There are a number of places where passwords are required in configuration, annotations and possibly even application code.
Password aliasing or indirection is a mechanism for storing and referencing a moniker or token instead of an actual clear text password. Resolving the token into an actual password for use at runtime is protected and only available to trusted code.
In order to support this in a portable way, Java EE 7 is standardizing a number of aspects of the solution. At the same time, the standard will not dictate the runtime implementation details for this support.

See http://java.net/downloads/javaee-spec/password-aliasing-ee7-proposal.pdf






[GLASSFISH-19202] JAX-RS and Servlet Constraint Overlap (Support for Multiple Auth Mechanisms) Created: 22/Oct/12  Updated: 19/Mar/13

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

Type: New Feature Priority: Major
Reporter: JeffTancill Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Remaining Estimate: 3 weeks
Time Spent: Not Specified
Original Estimate: 3 weeks

Tags:
Participants: JeffTancill

 Description   

Currently, due to the JAX-RS reliance on the servlet container's authentication mechanism, it is possible to define a security constraint with an URL pattern that encompasses a JAX-RS endpoint as well as other servlets within the application.

When the configured authentication method within web.xml is FORM or any other method that ultimately assumes that there is a user and browser to interact with, the JAX-RS client is presented with a challenge for credentials that it is unable to deal with - such as form based login. Additionally, the URL pattern matching model does not include enough fidelity to differentiate between the underlying JAX-RS resources. JAX-RS was an unique requirement to want provide varying authentication mechanisms for the same URL based upon the nature of the client. Therefore, the URL pattern based constraints are not well suited for indicating resource level constraints.






[GLASSFISH-19186] ORB Test Coverage improvements Created: 18/Oct/12  Updated: 18/Oct/12

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

Type: Improvement Priority: Major
Reporter: Harshad Vilekar Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-11941 Improve CORBA testing Resolved
Tags:
Participants: Harshad Vilekar

 Description   

Tracking issue for ORB test coverage / code coverage improvements:

  • Add unit tests and bug verification tests to dev test suite.
  • Automate performance testing with ability to identify performance regressions.
  • Automate ORB CTS tests on dev builds.
  • Dev integration of Corba SQE tests.
  • Improve dev test execution framework result reporting. Complete port to Junit/testNG.
  • StandardTest, Maribor
    Related issue: GLASSFISH-11941





[GLASSFISH-18995] EJBRefFO16_restart test failed on modified-attribute Created: 12/Aug/12  Updated: 21/Mar/13

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

Type: Bug Priority: Major
Reporter: sherryshen Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Solaris 11 and JDK1.6.0_30


File Attachments: Zip Archive test.zip     Zip Archive test4.zip    
Tags:
Participants: Alex Pineda, Mahesh Kannan and sherryshen

 Description   

EJBRefFO16_restart test failed on modified attribute
ogs-4.0-b49.zip

Failover of session with form-based authentication and authorization for Stateless Session Bean
EJBRefFO16_restart is a test case in this suite, and failed on b49 with modified attribute, but passed with other two persistence scope.
I will provide test details next.



 Comments   
Comment by sherryshen [ 12/Aug/12 10:54 PM ]

[1] Test Spec
16 Failover of session with form-based authentication and authorization for Stateless Session Bean
http://asqe-sblade-6.us.oracle.com:1080/job/sherry-svn-failed/ws/as-qa/ha-paas-tests/trunk/ha/functional/http/docs/2003FailoverEJBRef.html

[2] Test Results
2.1 Full run: Only 1 failure in http module (~270 tests) , i.e. EJBRefFO16_restart on modified-attribute
http://javaweb.us.oracle.com/net/asqe-logs.us.oracle.com/export1/4.0/Results/build49/ha/sol/summary/overall-summary.html

2.2 Debug run:
http://javaweb.us.oracle.com/net/asqe-logs.us.oracle.com/export1/4.0/Results/build49/ha/18995/r1/summary/overall-summary.html
asadmin set-log-levels --target st-cluster org.shoal.ha.cache=FINE
EJBRefFO16_restart with 2 persistence scope, session (passed) and modified-attributes (failed).

2.3 For modified-attribute, it asks to relogin in the third request/reponse.
(The zero JSESSIONIDVERSION is observed.)

http://javaweb.us.oracle.com/net/asqe-logs.us.oracle.com/export1/4.0/Results/build49/ha/18995/r1/http-modified-attribute/com.sun.dft.glassfish.http.failover.ejbref.EJBRefFO16_restart/EJBRefFO16Test1_restart/logs/framework.log

2.4 For full-session, it doesn't ask to relogin in the third request/response
http://javaweb.us.oracle.com/net/asqe-logs.us.oracle.com/export1/4.0/Results/build49/ha/18995/r1/http-session/com.sun.dft.glassfish.http.failover.ejbref.EJBRefFO16_restart/EJBRefFO16Test1_restart/logs/framework.log

where the test got expected results as shown results
http://javaweb.us.oracle.com/net/asqe-logs.us.oracle.com/export1/4.0/Results/build49/ha/18995/r1/http-session/com.sun.dft.glassfish.http.failover.ejbref.EJBRefFO16_restart/html/suite1_test1_results.html

  • Sending Request to Webserver asqe-sblade-6:80> /SSOFormWeb/SSOServlet
  • Sending Request to Webserver asqe-sblade-6:80> /SSOFormWeb/j_security_check?j_username=j2ee&j_password=secret
  • Serving Instance (1st Request): instance101
  • Killing serving instance...
  • Starting serving instance...
  • Sending Request to Webserver asqe-sblade-6:80> /SSOFormWeb/SSOServlet
  • Serving Instance (2nd Request): instance101
  • Session data contains EJBRef and works with SSO! true

2.5 server.log has exception for full session or modified attribute, e.g.
Error occurred
java.lang.NoSuchMethodException: org.glassfish.web.deployment.runtime.Cache.setDefaultHelper(org.glassfish.web.deployment.runtime.WebProperty)
at java.lang.Class.getMethod(Class.java:1605)
which seems not related to this issue.

Comment by sherryshen [ 12/Aug/12 11:19 PM ]

attached test.zip with ear file and test source for EJBRefFO16_restart

Comment by sherryshen [ 13/Aug/12 06:40 AM ]

After I used the SSO configuration in
ha-paas-tests/trunk/ha/functional/http/src/com/sun/dft/glassfish/http/failover/ejbref/EJBRefFO16_restart.java
e.g.
asadmin --user admin set st-cluster.http-service.virtual-server.server.sso-enabled=true
asadmin --user admin set st-cluster-config.availability-service.web-container-availability.sso-failover-enabled=true

the test passed on b49 with modified-attribute.
http://javaweb.us.oracle.com/net/asqe-logs.us.oracle.com/export1/4.0/Results/build49/ha/18995/b49wSSO/http-modified-attribute/com.sun.dft.glassfish.http.failover.ejbref.EJBRefFO16_restart/html/index.html

http://javaweb.us.oracle.com/net/asqe-logs.us.oracle.com/export1/4.0/Results/build49/ha/18995/b49wSSO/http-modified-attribute/com.sun.dft.glassfish.http.failover.ejbref.EJBRefFO16_restart/EJBRefFO16Test1_restart/logs/framework.log

Comment by sherryshen [ 13/Aug/12 10:06 PM ]

I consulted Mahesh, Shangwai, Rajov, and Rayn about this failure and updated the bug about our discussion and tests.

As I understood from ShingWai that SSO configuration is not needed since only one app is in the tests, and is not about SSO tests.

This failure is not always surfaced in ha execution since some previous tests set up SSO configuration, and don't clean SSO configuration.

Comment by sherryshen [ 23/Aug/12 04:30 AM ]

With the help of Mahesh and Shing Wai, I reproduced GLASSFISH-18995 in another way.
--Create a form-based web app based on
appserv-tests/devtests/web/form-based
--Use war file (ejbsecurity-test4.war), and steps (readme.txt) in
attachment test4.zip to reproduce the problem manually with a
browser on a cluster of 3 local instances.

Comment by Alex Pineda [ 15/Feb/13 09:27 PM ]

Request issue be resolved in GF 4.0 release.

Comment by Mahesh Kannan [ 14/Mar/13 04:24 PM ]

This is really HA bug requiring cluster support. Since there will be no clustering support for GF 4.0, I marking this to a future release.

Comment by Mahesh Kannan [ 21/Mar/13 02:20 AM ]

This is really a HA bug requiring cluster support.





[GLASSFISH-18962] Admin console throws back to login in iOS Safari Created: 30/Jul/12  Updated: 19/Oct/12

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: v2.1.1
Fix Version/s: future release

Type: Improvement Priority: Minor
Reporter: misschatter Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish on Linux, Console on Safari for iOS iPhone


Tags: admin-gui ios
Participants: Anissa Lam and misschatter

 Description   

This is only used in an on-call emergency, but still good to have working for those of us not lugging a laptop around. After logging into the admin console from an iPhone, after clicking something in the left navigation pane (i.e. Clusters -> Select a cluster) and then trying to move to a tab such as instances in the main pane, get thrown back out to the login screen. (I realize this is in 2.1.1 and maybe won't be fixed now that 3.1.2 is out and it seems to work fine there).



 Comments   
Comment by misschatter [ 02/Aug/12 01:43 PM ]

Update: I had to do deployments on GF3 (3.1.2.2) yesterday on iPad. You cannot scroll the main window deployment screen to get to the OK button (but using next/previous buttons can get you close enough to the top of the page to see the OK button). Also, if the war file to deploy is more than one directory down on the filesystem, the filesystem browser can't go there. It does, however, work if you type the full path in manually. Welcome to the mobile office

Comment by Anissa Lam [ 19/Oct/12 09:28 PM ]

RFE to support iOS. and sounds like there is a workaround, moving to future release and minor.





[GLASSFISH-18945] Better use of bundle start level Created: 25/Jul/12  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: OSGi
Affects Version/s: 3.1.2
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: File osgi.properties    
Issue Links:
Related
is related to GLASSFISH-18944 [REGRESSION] WARNING: Error finding i... Resolved
Tags: ee7ri_cleanup_deferred
Participants: Sanjeeb Sahoo and Tom Mueller

 Description   

Currently although we depend on certain bundle start orders as described in GLASSFISH-18944 , we are not using start levels to record the desired bundle start order. It should be a trivial effort to fix this. PFA a patched osgi.properties file as well. It can be applied once the code base is stable. When we change this, we will also have to fix our OSGi documentation that states the start level of shell bundle as 3.



 Comments   
Comment by Tom Mueller [ 18/Oct/12 09:22 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 issue 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-18920] Pick-up @ApplicationException from different deployment unit Created: 19/Jul/12  Updated: 10/Oct/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1.2
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: ancoron Assignee: Hong Zhang
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-18918 [OSGi/JavaEE] Annotated ApplicationEx... Resolved
Tags:
Participants: ancoron, Hong Zhang and Sanjeeb Sahoo

 Description   

Use case:

  • have some Exceptions pre-defined and shared (e.g. for inheritance) while also pre-defining business logic semantics

The concrete issue:

  • Create a plain-vanilla OSGi bundle containing service contracts as well as exceptions (annotate one of them)
  • Create a hybrid OSGi/JavaEE bundle containing an implementation and try to use the annotated exception

Result:

  • defined behaviour of the @ApplicationException is not applied

This is due to the fact that the BaseContainer does not find the exception in the list of application-exceptions.

We know that there exists workarounds but that involves modifying probably a lot of artifacts, esp. in a multi-layered, highly modularised application setup where only one of a few very basic shared Exception classes are deemed to provide specific semantics for all implementations.



 Comments   
Comment by Hong Zhang [ 19/Jul/12 01:55 PM ]

As the use cases are for OSGI bundles, I will let Sahoo do initial evaluation for this new feature request.

Comment by Sanjeeb Sahoo [ 19/Jul/12 02:04 PM ]

Changing it to a deployment type issue for reasons stated in GLASSFISH-18918.

Comment by Hong Zhang [ 10/Oct/12 02:14 AM ]

We don't scan the classes outside of the application due to various considerations (for example, performance). We may revisit this in the future release if those concerns are no longer applicable or this use case has to be supported.





[GLASSFISH-18870] Avoid configuring embeddable packages in osgi.properties. Created: 07/Jul/12  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: OSGi
Affects Version/s: 3.1.2
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File patch.txt    
Tags: ee7ri_cleanup_deferred
Participants: Sanjeeb Sahoo and Tom Mueller

 Description   

Turn simple-glassfish-api to be a framework extension instead.



 Comments   
Comment by Sanjeeb Sahoo [ 09/Jul/12 12:29 AM ]

This can't be integrated until https://issues.apache.org/jira/browse/FELIX-3587 is fixed. There must be a similar issue on Equinox as well. Those bugs will appear when gf is embedded in an existing environment. We encountered them while running FighterFish dev tests with this patch.

Comment by Tom Mueller [ 18/Oct/12 09:22 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 issue 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-18821] Support for application.xml icons in GUI Created: 22/Jun/12  Updated: 19/Oct/12

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.1_b12
Fix Version/s: future release

Type: Improvement Priority: Trivial
Reporter: mkarg Assignee: Anissa Lam
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GF3.1.1 Win7 Pro SP1 (64 Bit) JDK 1.6.0_26


Tags:
Participants: Anissa Lam and mkarg

 Description   

The application.xml allows to specifiy icons (a small one and a big one) for an EAR.

It would be great if this would be shown in the admin GUI.

For example, when having many applications in the "Applications" tree branch or tabular listing, it makes identification of the single application much simpler by visually marking the "wanted" entry using the small icon. Also, for ISVs, this is a nice possibility to brand the GUI in some way: The "Edit Application" table has plenty of free space in the upper right corner, which could by used to show the large icon.

This certainly is nothing essential, but would be simply cool.



 Comments   
Comment by Anissa Lam [ 19/Oct/12 05:04 AM ]

retarget for future release.





[GLASSFISH-18761] Help does not have --target for enable-monitoring command Created: 23/May/12  Updated: 23/May/12

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

Type: Bug Priority: Major
Reporter: Byron Nevins Assignee: Paul Davies
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Byron Nevins and Paul Davies

 Description   

d:\bg\all>asadmin enable-monitoring --x
Invalid option: --x
Usage: asadmin [asadmin-utility-options] enable-monitoring
[--target <target(default:server)>] [--pid <pid>] [--options <options>]
[--modules <modules>] [--mbean[=<mbean(default:false)>]]
[--dtrace[=<dtrace(default:false)>]] [?|-help[=<help(default:false)>]]

===================

Running --help on the command makes no mention of "--target". Or is it a "grandfathered-doc" option?!?






[GLASSFISH-18617] check property's name and value when add property in GUI Created: 11/Apr/12  Updated: 19/Oct/12

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

Type: Improvement Priority: Major
Reporter: Jeremy_Lv Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ALL


File Attachments: JPEG File screenshot-1.jpg     JPEG File screenshot-2.jpg    
Tags:
Participants: Anissa Lam and Jeremy_Lv

 Description   

configuration >> web container >> add property

phenomenon:
1.add a property but eithor the name or the value is null
2.save the property .
3.the GUI showed us "New values successfully saved" but without any property increased.



 Comments   
Comment by Jeremy_Lv [ 11/Apr/12 06:54 AM ]

in my opition, I wonder the glassfish should show us obvious information like "Please input an effective name.
" when the cunstomer hasn't entered both the Name and Value during the operation of adding a property.

Comment by Jeremy_Lv [ 11/Apr/12 06:55 AM ]

we can define a method in handle to judge whether both of the Name and Value have been entered before save the property. Then add the method in .jsf file where has the function of add the property.

Comment by Anissa Lam [ 19/Oct/12 05:16 AM ]

target this for 4.0

Comment by Anissa Lam [ 19/Oct/12 06:38 AM ]

Defer to future release





[GLASSFISH-18600] Document incorrectly states that 32-bit load-balancer plugin is support on Solaris and Linux Created: 06/Apr/12  Updated: 06/Apr/12

Status: Open
Project: glassfish
Component/s: docs
Affects Version/s: 3.1.2
Fix Version/s: future release

Type: Bug Priority: Critical
Reporter: kshitiz_saxena Assignee: Mike Fitch
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: kshitiz_saxena and Mike Fitch

 Description   

Documentation link : http://docs.oracle.com/cd/E26576_01/doc.312/e24934/web-servers-for-http-load-balancing.htm#gldbq

As per above link, load-balancer plugin support exists for 32-bit webserver on Solaris and Linux. This information is incorrect. We only support 64-bit webserver on Solaris and Linux platform. For solaris, support is limited to Solaris 10.

Information with respect to windows, AIX and HP-UX is correct.






[GLASSFISH-18594] jsftemplating optionally depend on dataprovider packages Created: 04/Apr/12  Updated: 11/Feb/13

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.2
Fix Version/s: future release

Type: Bug Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: spo
Participants: Anissa Lam, Sanjeeb Sahoo and TangYong

 Description   

jsftemplating has badly setup its OSGi metadata. Although it requires dataprovider packages,
it optionally imports them. So, it breaks any kind of automatic deployment that does not deploy optional modules. This should be fixed. When you do fix this issue, please remove the dead module called appserver/admingui/jsftemplating because jsftemplating is built in a separate workspace called https://svn.java.net/svn/jsftemplating~svn/trunk



 Comments   
Comment by TangYong [ 22/Jun/12 01:23 PM ]

Dear Anissa,Sahoo,

In the current gfv4 trunk, appserver\admingui\jsftemplating still exists, and in admingui's pom.xml,
the jsftemplating module is not put in build process. So, the appserver\admingui\jsftemplating is indeedly
a dead module. It should be removed from appserver\admingui.





[GLASSFISH-18587] [NATIVE][WINDOWS] Loadbalancer gets hang up during the deployment : " Error opening deployable artifact" [basic_db_paas_sample] Created: 02/Apr/12  Updated: 15/Feb/13

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

Type: Bug Priority: Major
Reporter: RameshT Assignee: Bhavanishankar
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x86


File Attachments: File server.log_2012-04-02T14-58-45    
Tags: deploy hang lb loadbalancer windows7
Participants: Alex Pineda, Bhavanishankar, kshitiz_saxena, RameshT and shamant

 Description   

Steps to reproduce ,

1. Install BG ( Extract the glassfish Bundle.)
2. Start Domain and create-ims-config-native
3. Create template with the option for the Native
4. Deploy basic_db_paas_sample.war

System gets hang up on step 4. In server.log 2 SEVERE messages are received.

[#|2012-03-20T13:19:44.681+0530|SEVERE|44.0|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=79;_ThreadName=Thread-2;|Unable to find cloud-config.properties file in 'config' directory. Returning EMPTY properties.|#]
[#|2012-03-

20T13:18:37.836+0530|SEVERE|44.0|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=80;_ThreadName=Thread-2;|Error opening deployable artifact|#]

PS : server.log is attached with this.



 Comments   
Comment by kshitiz_saxena [ 18/May/12 02:13 PM ]

Assigning to Shyamant to have a look.

Comment by shamant [ 08/Jun/12 06:48 AM ]

Assigning it to bhavani.
Once fixed by bhavani will assign it to myself for fixing it on LB side.

Comment by Alex Pineda [ 27/Jun/12 11:45 PM ]

Removing the 40-regression tag as this may turn out to be not an issue with the new design.





[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-18544] Removing the ejb-container dependency when building the app client container causes NPE in naming Created: 21/Mar/12  Updated: 02/Jul/13

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

Type: Task Priority: Minor
Reporter: Tim Quinn Assignee: guojun.shan
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File npe.txt     File TestEJB.ear    
Issue Links:
Related
is related to GLASSFISH-4109 Reduce footprint required by Applicat... Open
Tags:
Participants: guojun.shan, jthoennes, Tim Quinn and Tom Mueller

 Description   

In trying to reduce the footprint of the ACC, one step is to remove the dependency on the ejb container. This causes no build-time problems because the ACC itself does not depend on the class(es) in the ejb container that are used for injecting @EJB references, for example.

But if you rebuild the appserver/appclient/client/acc and appserver/appclient/client/acc-standalone components having removed the ejb dependency and then deploy an app containing an EJB and a client that uses the EJB, running the client fails with an NPE. (stack trace attached)

To reproduce:

1. cd to main/appserver/appclient/client/acc.
2. Edit the pom.xml file to comment out the dependency on the ejb-container module.
3. mvn clean install ; cp target/gf-client-module.jar glassfish3/glassfish/modules
4. cd ../acc-standalone
5. mvn clean install ; cp target/gf-client.jar glassfish3/glassfish/lib
6. Restart the server.
7. Deploy the attached app using "asadmin deploy --retrieve localdir TestEJB.ear"
8. Try to run the client using "appclient localdir/TestEJBClient.jar"



 Comments   
Comment by Tim Quinn [ 21/Mar/12 07:57 PM ]

Attached the stack trace during an attempted client run having commented out the ejb-container dependency (npe.txt)

and a test EAR with an EJB and a client (TestEJB.ear)

Comment by jthoennes [ 22/Mar/12 08:51 AM ]

Tim, is there a dedicated plan to reduce the footprint in the ACC client?
We would like to use this in our JavaWS application.

Comment by Tim Quinn [ 22/Mar/12 02:54 PM ]

There is a low-priority but nevertheless ongoing effort to reduce the ACC footprint.

Please feel free to vote for

http://java.net/jira/browse/GLASSFISH-4109

which captures this requirement.

Comment by Tom Mueller [ 15/Feb/13 10:45 PM ]

Reassigning to component lead as the assignee is no longer with the project.





[GLASSFISH-18536] GF callback handler blocking a JASPIC provider when Principal is unknown Created: 21/Mar/12  Updated: 16/Apr/14

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

Type: Bug Priority: Blocker
Reporter: bjb Assignee: JeffTancill
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 2008 64bits


Tags: JASPIC blocking users groups principal unknown
Participants: arjan tijms, bjb, JeffTancill and kumarjayanti

 Description   

When sending an unknown Principal (principal not valid as per a local JAAS config) but valid on a global perspective (all checks was done in the JASPIC provider), the GF CallerPrincipal handler will throw a blocking exception in the process :

com.sun.enterprise.security.auth.realm.NoSuchUserException: Cet utilisateur [USER@INTRA-DEV01.DOMAIN-DEV01.LOCAL] n'existe pas. at com.sun.enterprise.security.auth.realm.file.FileRealm.getGroupNames(FileRealm.java:329) at com.sun.enterprise.security.auth.login.LoginContextDriver.jmacLogin(LoginContextDriver.java:566) at com.sun.enterprise.security.jmac.callback.BaseContainerCallbackHandler.processCallerPrincipal(BaseContainerCallbackHandler.java:257) at com.sun.enterprise.security.jmac.callback.BaseContainerCallbackHandler.processCallback(BaseContainerCallbackHandler.java:197) at com.sun.enterprise.security.jmac.callback.ServerContainerCallbackHandler.handleSupportedCallbacks(ServerContainerCallbackHandler.java:76) at com.sun.enterprise.security.jmac.callback.BaseContainerCallbackHandler.handle(BaseContainerCallbackHandler.java:187) at com.sun.enterprise.security.jmac.callback.ContainerCallbackHandler.handle(ContainerCallbackHandler.java:83) at net.java.spnego.PACSpnegoServerAuthModule.updateCallerPrincipal(PACSpnegoServerAuthModule.java:550) at net.java.spnego.PACSpnegoServerAuthModule.validateRequest(PACSpnegoServerAuthModule.java:354) at com.sun.enterprise.security.jmac.config.GFServerConfigProvider$GFServerAuthContext.validateRequest(GFServerConfigProvider.java:1171) at com.sun.web.security.RealmAdapter.validate(RealmAdapter.java:1445) at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1323) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623) at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96) at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:662)

The problem is that groups that were provided before with a call to the GF handler (Group handler) is not used but insteand GF access the default realm (file) to fetch the user's groups.

This is blocking usage of non-JAAS bridge profile JASPIC providers.

To lower the state of this issue, either fix the issue or provide a way to bypass this issue.



 Comments   
Comment by bjb [ 24/Mar/12 08:37 AM ]

Hi Kumar,

Please lower the priority level as it is actually not blocking but only misleading.

It will not block non-JAAS bridge but simply push a wrong track to people debugging.

The core issue has been logged as :
http://java.net/jira/browse/GLASSFISH-18556

When runing in JASPIC mode, such an issue should not be raised.

Rgs,
JB

Comment by kumarjayanti [ 25/Mar/12 04:21 AM ]

This issue does sound like it needs a fix. The caller principal callback is trying to do an identity assertion in this case forcing people to also configure a realm that can be used to fetch the groups of the user. This was done to meet requirements of some other usecases but now i realize this is not appropriate. Instead the Group Principal Callback should be explicitly used in this case.

I will fix this for 3.1.2 Patch releases and glassfish trunk.

Thanks for raising this issue.

Comment by arjan tijms [ 13/Apr/13 11:42 AM ]

Is this still the same issue as reported? I've done a lot of JASPIC testing with GlassFish 3.1.2.2 but never encountered this issue. There is something fishy going on though.

The caller principal callback is trying to do an identity assertion in this case

I think you mean the caller principal callback handler right? Since the caller principal callback is a very simple DTO style class that only stores the Subject and the Principal or Name.

The handler (in BaseContainerCallbackHandler.processCallerPrincipal) does a call to the LoginContextDriver, but it itself does not do any identity assertion:

if (isCertRealm) {
    if (principal  instanceof X500Principal) {
        LoginContextDriver.jmacLogin(fs, (X500Principal)principal);
    }
} else {
    if (!principal.equals(SecurityContext.getDefaultCallerPrincipal())) {
        LoginContextDriver.jmacLogin(fs, principal.getName(), realmName);
    }
}

The LoginContextDriver.jmacLogin however does attempt to do this:

public static Subject jmacLogin(Subject subject, String identityAssertion, String realm) throws LoginException {

        if (subject == null) {
            subject = new Subject();
        }
        final Subject fs = subject;
        String userName = identityAssertion;

        try {
            if (realm == null || "".equals(realm)) {
                realm = Realm.getDefaultRealm();
            }
            Realm realmInst = Realm.getInstance(realm);
            final Enumeration groups = realmInst.getGroupNames(userName);
            if (groups != null && groups.hasMoreElements()) {
                AppservAccessController.doPrivileged(new PrivilegedAction() {

                    public java.lang.Object run() {
                        while (groups.hasMoreElements()) {
                            String grp = (String) groups.nextElement();
                            fs.getPrincipals().add(new Group(grp));
                        }
                        return fs;
                    }
                });
            }
        } catch (Exception ex) {
            if (_logger.isLoggable(Level.FINE)) {
                _logger.log(Level.FINE, "Exception when trying to populate groups for CallerPrincipal " + identityAssertion, ex);
            }
        }
        return subject;
    }

When using JASPIC, the passed in realm will be "" and when that happens this method obtains the default realm ("file") and tries to get the group names from that (realmInst.getGroupNames(userName);).

If this throws an exception (in my testing a NPE is typically thrown) it is ignored by the catch, so the problem as described for this issue doesn't seem to occur anymore (that is, the exception is still thrown, but it doesn't interrupt the authentication flow).

I'm afraid though that if I happened to have this file realm defined with a user that happened to have the same name as the user I'm trying to authenticate with JASPIC, that this user would suddenly get a set of extra roles. If my application happened to have roles with the same name, then this could be a rather big problem.





[GLASSFISH-18533] Make OSGi Web console available via admin port Created: 20/Mar/12  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: OSGi
Affects Version/s: 3.1.2
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

Workaround:
If you want to change it to 4848, please try adding a file called
domain_dir/autodeploy/bundles/org.apache.felix.webconsole.internal.servlet.OsgiManager.cfg
with following content:
http.service.filter=VirtualServer=__asadmin

Tags: ee7ri_cleanup_deferred
Participants: Sanjeeb Sahoo and Tom Mueller

 Description   

Based on feedback received in GLASSFISH-18228, it will be better to configure the OSgi admin console extension to make the OSGi console available on admin port than usual http traffic port. It will be even better to make it a configurable property.



 Comments   
Comment by Sanjeeb Sahoo [ 20/Mar/12 07:39 AM ]

See workaround until we switch the default.

Comment by Tom Mueller [ 18/Oct/12 09:22 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 issue 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-18527] glassfish has a dependency on gsettings-desktop-schemas. Created: 18/Mar/12  Updated: 22/Mar/12

Status: Open
Project: glassfish
Component/s: docs
Affects Version/s: 3.1.2
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: crochery Assignee: Paul Davies
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

slackware64 13.37
openjre 7 update 3
openjdk 7 update 3


Tags:
Participants: crochery, Paul Davies and Tom Mueller

 Description   

When I execute "asadmin start-domain --verbose", I see the following output.

asadmin> start-domain --verbose
Mar 18, 2012 8:49:54 PM com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: JVM invocation command line:
-XX:+UnlockDiagnosticVMOptions
-XX:PermSize=64m
-XX:MaxPermSize=192m
-XX:NewRatio=2
-Xmx512m
-client
-javaagent:/misc/data/glassfish3/glassfish/lib/monitor/flashlight-agent.jar
-Dosgi.shell.telnet.maxconn=1
-Dfelix.fileinstall.disableConfigSave=false
-Djdbc.drivers=org.apache.derby.jdbc.ClientDriver
-Dfelix.fileinstall.dir=/misc/data/glassfish3/glassfish/modules/autostart/
-Djavax.net.ssl.keyStore=/misc/data/glassfish3/glassfish/domains/domain1/config/keystore.jks
-Dosgi.shell.telnet.port=6666
-Djava.security.policy=/misc/data/glassfish3/glassfish/domains/domain1/config/server.policy
-Djava.awt.headless=true
-Dfelix.fileinstall.log.level=2
-Dfelix.fileinstall.poll=5000
-Dcom.sun.aas.instanceRoot=/misc/data/glassfish3/glassfish/domains/domain1
-Dosgi.shell.telnet.ip=127.0.0.1
-Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory
-Djava.endorsed.dirs=/misc/data/glassfish3/glassfish/modules/endorsed:/misc/data/glassfish3/glassfish/lib/endorsed
-Dcom.sun.aas.installRoot=/misc/data/glassfish3/glassfish
-Dfelix.fileinstall.bundles.startTransient=true
-Djava.ext.dirs=/usr/lib64/java/lib/ext:/usr/lib64/java/jre/lib/ext:/misc/data/glassfish3/glassfish/domains/domain1/lib/ext
-Dfelix.fileinstall.bundles.new.start=true
-Djavax.net.ssl.trustStore=/misc/data/glassfish3/glassfish/domains/domain1/config/cacerts.jks
-Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as
-Djava.security.auth.login.config=/misc/data/glassfish3/glassfish/domains/domain1/config/login.conf
-DANTLR_USE_DIRECT_CLASS_LOADING=true
Dgosh.args=-nointeractive
Mar 18, 2012 8:49:54 PM com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: Successfully launched in 11 msec.
Launching GlassFish on Felix platform
[#|2012-03-18T20:49:58.215+0900|INFO|glassfish3.1.2|com.sun.enterprise.server.logging.GFFileHandler|_ThreadID=1;_ThreadName=main;|Running GlassFish Version: GlassFish Server Open Source Edition 3.1.2 (build 23)|#]

[#|2012-03-18T20:49:59.178+0900|INFO|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=21;_ThreadName=Grizzly-kernel-thread(1);|Grizzly Framework 1.9.46 started in: 107ms - bound to [0.0.0.0:8181]|#]

[#|2012-03-18T20:49:59.184+0900|INFO|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=26;_ThreadName=Grizzly-kernel-thread(1);|Grizzly Framework 1.9.46 started in: 34ms - bound to [0.0.0.0:4848]|#]

[#|2012-03-18T20:49:59.186+0900|INFO|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=22;_ThreadName=Grizzly-kernel-thread(1);|Grizzly Framework 1.9.46 started in: 215ms - bound to [0.0.0.0:8080]|#]

[#|2012-03-18T20:49:59.211+0900|INFO|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=29;_ThreadName=Grizzly-kernel-thread(1);|Grizzly Framework 1.9.46 started in: 39ms - bound to [0.0.0.0:3700]|#]

[#|2012-03-18T20:49:59.233+0900|INFO|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=32;_ThreadName=Grizzly-kernel-thread(1);|Grizzly Framework 1.9.46 started in: 22ms - bound to [0.0.0.0:7676]|#]

[#|2012-03-18T20:49:59.911+0900|INFO|glassfish3.1.2|org.glassfish.ha.store.spi.BackingStoreFactoryRegistry|_ThreadID=1;_ThreadName=main;|Registered org.glassfish.ha.store.adapter.cache.ShoalBackingStoreProxy for persistence-type = replicated in BackingStoreFactoryRegistry|#]

[#|2012-03-18T20:50:00.104+0900|INFO|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=main;|GlassFish Server Open Source Edition 3.1.2 (23) startup time : Felix (3,227ms), startup services(2,352ms), total(5,579ms)|#]

GLib-GIO-ERROR **: Settings schema 'org.gnome.system.proxy' is not installed

aborting...

A bit of googling indicates that org.gnome.system.proxy is installed by gsettings-desktop-schemas.

Because it is a bad design decision for glassfish to depend on a gnome lib, I want this dependency removed.



 Comments   
Comment by Tom Mueller [ 19/Mar/12 03:37 PM ]

GlassFish does not contain any direct references to any gnome library. However, depending on the update tool client configuration settings, it will set the java.net.useSystemProxies environment variable to true, which may cause Java SE to use a gnome library to read the system proxies. You can avoid this in any of the following ways:

  • set http_proxy or https_proxy environment variable
  • set the proxy values in the $HOME/.updatetool/init.cfg (or defaults.cfg) to something other than use system proxy.
Comment by crochery [ 20/Mar/12 05:29 AM ]

I disabled system proxy in $HOME/.updatetool/init.cfg, and glassfish started working.

Can you disable system proxy by default?

Or I think the fact that system proxy settings should be disabled on some environments by some means should be explained in glassfish doc.

Comment by Tom Mueller [ 21/Mar/12 04:57 PM ]

Changing this to be a docs bug so that the need to disable the use of the system properties for some systems can be explained.

I'm not sure what is meant by "by default" in the previous comment.

Changing the value in init.cfg (as you have done) will change the default behavior of GlassFish for all domains that are created by the user who owns the init.cfg.

If the .zip distribution of GlassFish is used, no init.cfg file is created by default, and the default behavior will be to use no proxy, not the system proxy. So for the zip distribution, not using the system proxy is already the default.

When installed using the installer, the installer prompts for the proxy to use with the update tool. It does not offer a "use system proxy" option at that point. So again, the default behavior is to not use the system proxy.

So I'm not sure how the use of system proxies was enabled on your system without actually selecting it via updatetool.

Comment by crochery [ 22/Mar/12 01:49 AM ]

Initially, I tried to install glassfish with an installer, but it only installed a small fraction of glassfish on slackware.
I think init.cfg was implanted when installing or executing the updatetool.

After removing init.cfg and extracting the zip distribution again, I found out that system proxy was off by default.

bin/updatetool sets [network] proxy.user.system to true in ~/.updatetool/init.cfg
What's your idea on this?





[GLASSFISH-18520] Reduce number of modules Created: 16/Mar/12  Updated: 11/Mar/13

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

Type: Task Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-18521 Get rid of web-embed-api and web-embe... Sub-task Resolved Amy Roh  
Tags: spo
Participants: Sanjeeb Sahoo

 Description   

This is an umbrella task to reduce no. of modules.






[GLASSFISH-18514] CDI does not get enabled on server start for a WAB bundle, the war has to be redeployed after the server starts for CDI to be enabled. Created: 15/Mar/12  Updated: 20/Mar/13

Status: Open
Project: glassfish
Component/s: cdi, OSGi-JavaEE
Affects Version/s: 3.1.2
Fix Version/s: future release

Type: Bug Priority: Critical
Reporter: aaronjwhiteside Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File server.log    
Tags:
Participants: aaronjwhiteside, Sanjeeb Sahoo, Sivakumar Thyagarajan and tlcksnyder

 Description   

CDI does not get enabled on server start for a WAB bundle, the war has to be redeployed after the server starts for CDI to be enabled.

Please see attached server.log

You can see after the server has started I manually redeployed the WAB and CDI was enabled that time.

If I do not redeploy the WAB CDI is not enabled and I get NPE when trying to access a JAX-RS resource that @Inject's a @OSGiService(dynamic=true).



 Comments   
Comment by aaronjwhiteside [ 16/Mar/12 12:00 AM ]

So I think I tracked down the issue.

The org.glassfish.fighterfish.osgi-cdi bundle which provides the cdi support for WAB's has a run level of 2. However any bundle that is deployed under <domain>autodeploy/bundles always has a run level of 1.

So when you start glassfish that already has bundles under autodeploy/bundles and no osgi-cache (to tell it the deploy order, if you deployed something after the server was already started) it'll start the osgi-cdi bundle after the WAB bundle. And thus CDI support is never enabled for WAB's.

I tried adding

felix.fileinstall.start.level=4

to glassfish3/glassfish/config/osgi.properties

But the bundles deployed from <domain>/autodeploy/bundles still seem to start in runlevel 1.

Comment by aaronjwhiteside [ 16/Mar/12 12:03 AM ]

For reference:
http://felix.apache.org/site/apache-felix-file-install.html

Comment by aaronjwhiteside [ 16/Mar/12 12:14 AM ]

OK so it turns out that all the felix.fileinstall* properties in osgi.properties are totally ignored and should probably be removed.

The real file doing the configuration is:

glassfish3/glassfish/modules/autostart/org.apache.felix.fileinstall-autodeploy-bundles.cfg

However if I add the line:

felix.fileinstall.start.level=4

to this file, it still does not set the run level for bundles under autodeploy/bundles, they still start at run level one.

However I do get a log message printed out:

[#|2012-03-15T20:08:20.322-0400|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=12;_ThreadName=Thread-2;|felix.fileinstall.start.level set, but not a int: 4 |#]

Which is interesting, apparently 4 really isn't an int.. I guess this is an ERROR even though it says INFO.. or maybe a WARN as it seems to have ignored the config.

Without this fixed OSGi is pretty much useless.

Comment by aaronjwhiteside [ 16/Mar/12 12:18 AM ]

Fixing this issue will probably fix another bug I reported too.

http://java.net/jira/browse/GLASSFISH-18508

And a bunch of other random weird stuff I was pulling my hair out over..

Comment by aaronjwhiteside [ 16/Mar/12 04:16 PM ]

OK so after more investigation it turns out you have to set:

felix.fileinstall.start.level=4

in osgi.properties AND org.apache.felix.fileinstall-autodeploy-bundles.cfg or less it does not get picked up. This is probably a bug too.

(and obviously, even through I omitted it you must set glassfish.osgi.start.level.final=4 in osgi.properties too).

So now I can see that the start level of my WAB bundle is really 4, however CDI still does NOT get enabled. I have to remove the war and redeploy it again, after the server has started for CDI to kicked in.

So my assumption that the start level's were the issue seems to be moot, however having a start level of 1 for the bundles under autodeploy/bundles and a start level of 2 for most of glassfish's osgi to jee integration bundles is still a bug. The bundles under autodeploy/bundles should start in start level 4.

So the question is now, if not start levels, what is causing CDI to not load and required a redeploy of the war to be enabled???

Comment by Sanjeeb Sahoo [ 16/Mar/12 06:58 PM ]

No, I don't understand some of your observations. This is how things are supposed to work:

no osgi-cache:
fileinstall is started at start level 2 and it is configured to start after modules/autostart/,
which means first time (same as no osgi cache) the server starts, fileinstall will come into effect
after all bundles in modules/autostart/. Once fileinstall is started, it will then go onto deploy
autodeploy/bundles/. Now, let's say one such bundle is a WAB that uses CDI.
Since osgi-cdi is already installed,when the WAB is processed, osgi-cdi will process the WAB as well.

Let's stop the server and restart. Upon restart, the WAB is started at start level 1 which means it is
started before osgi-web-container and osgi-cdi are started. But, the WAB processing is deferred until
osgi-web-container is started. When server reaches start level 2, osgi-web-container is started and it
processes the WAB. It does not matter whether osgi-cdi is active or not. It only has to be in INSTALLED
state for it to be useful. So, when the WAB is processed by osgi-web-container, osgi-cdi will be used
as well.

So, I don't see a case why osgi-cdi is not used in your case. Could you supply a test case with instructions?
I tried a WAB+CDI test case and could not reproduce.

A note about fileinstall start level:
The bundles in autodeploy/bundles/ are started at start level 1. This seems like
a bad configuration. They should have start level matching that of fileinstall, which is 2. I will
open a separate issue to do this. But, I can't see it affecting any functionality now.

To change the start level of bundles in autodeploy/bundles, edit osgi.properties file.
modules/autostart/o.a.f.fileinstall-autodeploy-bundles.cfg is not used any more.
If you set a start level higher than 2, then you must also configure the server to change the
start level to that value. Currently, server sets final start level to 2 using the property:
glassfish.osgi.start.level.final=2
Change it to the higher value, else your bundles in autodeploy/bundles will never get activated.

Comment by aaronjwhiteside [ 16/Mar/12 08:06 PM ]

After clearing the osgi-cache (I keep forgetting) CDI now works, so changing the start level fixed the issue.

Can this please be fixed in the next release?

Comment by Sanjeeb Sahoo [ 17/Mar/12 01:23 AM ]

What you want to be fixed? start level of bundles/autodeploy/? Sure it can be (could you file an issue under osgi category?), but, as I mentioned earlier, I don't understand why you had to change start level. Are you really sure things didn't work for you as is? I would love to understand it better. Do you have a reproducible test case?

Comment by tlcksnyder [ 20/Mar/13 07:34 PM ]

not attempting to fix without a reproducible test case, or better description of reproduction steps.





[GLASSFISH-18469] On the local and remote hosts was used the same user, but install-node-dcom failed without -w <user_name> Created: 07/Mar/12  Updated: 15/Feb/13

Status: Open
Project: glassfish
Component/s: distributed management
Affects Version/s: 3.1.2_b21
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: easarina Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Byron Nevins and easarina

 Description   

3.1.2 bui8ld 21. Window 2008 machines.

I believe that this is a regression issue. install-node-dcom failed, because was not used -w <user_name> option. See, for example:
asadmin install-node-dcom -W password1.txt bigapp-oblade-3
com.sun.enterprise.util.cluster.windows.process.WindowsException: Logon failure:
unknown user name or bad password.
Command install-node-dcom failed.

But the command: "asadmin install-node-dcom -w aroot -W password1.txt bigapp-oblade-3" was executed successfully.
On the DAS machine and on the remote host was used the same user aroot, and according to the help: "The default is the user that is running this subcommand.". I.e. in my case aroot.






[GLASSFISH-18392] Multiple Failover of IIOP does not happen on dynamic cluster when one of the instances is removed Created: 22/Feb/12  Updated: 15/Feb/13

Status: Open
Project: glassfish
Component/s: rmi_iiop_failover
Affects Version/s: 3.1.2_b20
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: mzh777 Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OEL 5 + Oracle JDK


File Attachments: Zip Archive instancedeleteMultipleFO.zip     File MultiEJBApp.ear    
Issue Links:
Dependency
depends on GLASSFISH-15804 Multiple failover not happening on OE... Resolved
Related
is related to GLASSFISH-15746 Multiple Failover of IIOP does not ha... Open
Tags:
Participants: Harshad Vilekar and mzh777

 Description   

We were investigating issue 15804 and by adding delays to the test operations (before and after start-cluster, killing instances, accessing business methods), the multiple-failover tests passing. But even with those delays, the multiple failover of IIOP still does not happen on dynamic cluster when one of the instances is removed. In those two tests, there are similarities (the same EJB application is used, multiple fail-over, same exception on client side). But there difference also in terms of testing steps. File this separate issue to track the new scenario.

Run test with appclient: appclient ... com.sun.appserver.ee.tests.client.ClientDynamicClusterRemoveInstance MultipleFO
Exception was throw on client side:
[testng] javax.ejb.EJBException: java.rmi.MarshalException: CORBA COMM_FAILURE 1330446344 Maybe; nested exception is:
[testng] org.omg.CORBA.COMM_FAILURE: FINE: IOP00410008: Connection abort vmcid: OMG minor code: 8 completed: Maybe
[testng] at com.sun.appserver.ee.tests.ejb.stateful._SFSB3Remote_Wrapper.getName(com/sun/appserver/ee/tests/ejb/stateful/_SFSB3Remote_Wrapper.java)
[testng] at com.sun.appserver.ee.tests.client.ClientDynamicClusterRemoveInstance.runTest2(Unknown Source)
[testng] at com.sun.appserver.ee.tests.client.ClientDynamicClusterRemoveInstance.runMultipleFOTest(Unknown Source)
[testng] at com.sun.appserver.ee.tests.client.ClientDynamicClusterRemoveInstance.main(Unknown Source)
[testng] Caused by: java.rmi.MarshalException: CORBA COMM_FAILURE 1330446344 Maybe; nested exception is:
[testng] org.omg.CORBA.COMM_FAILURE: FINE: IOP00410008: Connection abort vmcid: OMG minor code: 8 completed: Maybe
[testng] at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:259)
[testng] at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:213)
[testng] at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
[testng] at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
[testng] at com.sun.appserver.ee.tests.ejb.stateful._SFSB3Remote_Remote_DynamicStub.getName(com/sun/appserver/ee/tests/ejb/stateful/_SFSB3Remote_Remote_DynamicStub.java)
[testng] ... 4 more
[testng] Caused by: org.omg.CORBA.COMM_FAILURE: FINE: IOP00410008: Connection abort vmcid: OMG minor code: 8 completed: Maybe
[testng] at sun.reflect.GeneratedConstructorAccessor39.newInstance(Unknown Source)
[testng] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
[testng] at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
[testng] at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
[testng] at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
[testng] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
[testng] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
[testng] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
[testng] at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
[testng] at $Proxy32.connectionAbort(Unknown Source)
[testng] at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doOptimizedReadStrategy(SocketOrChannelConnectionImpl.java:1537)
[testng] at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1084)
[testng] at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
[testng] at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
[testng] Caused by: org.omg.CORBA.COMM_FAILURE: FINE: IOP00410030: Exception in a blocking read on connection SocketOrChannelConnectionImpl[ java.nio.channels.SocketChannel[connected local=/10.133.185.4:61556 remote=asqeopteron1.us.oracle.com/10.133.169.163:23703] ESTABLISHED true true] with a temporary selector vmcid: OMG minor code: 30 completed: No
[testng] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
[testng] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
[testng] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
[testng] at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
[testng] at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
[testng] at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
[testng] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
[testng] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
[testng] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
[testng] at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
[testng] at $Proxy32.exceptionBlockingReadWithTemporarySelector(Unknown Source)
[testng] at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.blockingRead(SocketOrChannelConnectionImpl.java:1604)
[testng] at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doOptimizedReadStrategy(SocketOrChannelConnectionImpl.java:1501)
[testng] ... 3 more
[testng] Caused by: java.io.IOException: Connection reset by peer
[testng] at sun.nio.ch.FileDispatcher.read0(Native Method)
[testng] at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21)
[testng] at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:198)
[testng] at sun.nio.ch.IOUtil.read(IOUtil.java:171)
[testng] at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:243)
[testng] at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.blockingRead(SocketOrChannelConnectionImpl.java:1567)
[testng] ... 4 more

The steps to reproduce:

  1. Deploy MultiEJBApp.ear
  2. stop-cluster st-cluster
  3. start-instance instance110 and instance109
  4. access business methods
  5. Find and kill the instance with message [SFSB1Bean.getName]
  6. Delete the instance with message [SFSB1Bean.getName]
  7. start-cluster st-cluster
  8. access business methods
  9. Find and kill the instance with message [SFSB1Bean.getName] again.
  10. access more business methods
  11. assert the test pass or fail


 Comments   
Comment by mzh777 [ 22/Feb/12 02:10 AM ]

Test app and full test logs.





[GLASSFISH-18371] SSH: Do not allow running DAS on 4.0 and Remote Instances on 3.x Created: 15/Feb/12  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: distributed management
Affects Version/s: 4.0_b24
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Byron Nevins Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-18366 create-dcom should detect GlassFish v... Resolved
Tags:
Participants: Byron Nevins and Joe Di Pol

 Description   

I have not checked but this is almost certainly the case. See 18366.

It is visible by nadmin not existing in a 3.x installation.
But the real problem is that we should forbid hetero-version clustering.



 Comments   
Comment by Byron Nevins [ 15/Feb/12 07:44 PM ]

the DCOM version of this issue





[GLASSFISH-18368] [intermittent] Unable to set a value on the lb config's rewrite-location property when using jdk 1.7.0_03 Created: 15/Feb/12  Updated: 15/Feb/13

Status: Open
Project: glassfish
Component/s: configuration
Affects Version/s: 3.1.2_b23
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: varunrupela Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File server.log    
Tags: 3_1_2-release-note-added 3_1_2-release-notes 3_1_2_qa
Participants: Mahesh Kannan, Rebecca Parks, scatari, Tom Mueller and varunrupela

 Description   

GF Build: 23
JDK: 1.7.0_03
Platform: OEL 6

This works when using jdk 1.6.0_30.

Steps to reproduce the issue:

  • Install GF image with java-home set to a jdk with version 1.7.0_03
  • Start domain1: asadmin start-domain domain1
  • Create a LB Config: asadmin create-http-lb-config my-lb
  • Try to set the property rewrite-location on the lb: asadmin set lb-configs.lb-config.my-lb.property.rewrite-location=false

This last step results in the following output:

remote failure: Could not change the attributes: wrong number of arguments
wrong number of arguments
Command set failed.

Domain logs with logger javax.enterprise.system.tools.admin set to FINE are attached.

Workaround: Users can manually set the rewrite-location value in the loadbalancer.xml file that is in the <webserver>/https-<machine-name>/conf location.



 Comments   
Comment by varunrupela [ 15/Feb/12 11:56 AM ]


We are yet to check if this affects setting of other properties across admin.

Comment by Tom Mueller [ 15/Feb/12 04:01 PM ]

This issue is probably similar to GLASSFISH-18184

Comment by Tom Mueller [ 15/Feb/12 04:29 PM ]

Here is what might be happening.

The problem is in the HK2 ConfigSupport._createAndSet method, in the following loop:

for (Method m : parentProxyType.getMethods()) {
                            final Class returnType = m.getReturnType();
                            if (Collection.class.isAssignableFrom(returnType)) {
                                // this could be it...
                                if (!(m.getGenericReturnType() instanceof ParameterizedType))
                                    throw new IllegalArgumentException("List needs to be parameterized");
                                final Class itemType = Types.erasure(Types.getTypeArgument(m.getGenericReturnType(), 0));
                                if (itemType.isAssignableFrom(childType)) {
                                    List list = null;
                                    try {
                                        list = (List) m.invoke(param, null);
                                    } catch (IllegalAccessException e) {
                                        throw new TransactionFailure("Exception while adding to the parent", e);
                                    } catch (InvocationTargetException e) {
                                        throw new TransactionFailure("Exception while adding to the parent", e);
                                    }
                                    if (list != null) {
                                        list.add(child);
                                        break;
                                    }
                                }
                            }
                        }

When adding the "rewrite-location" property, as indicated in the bug report, this loop is executed with parentProxyType set to LbConfig. The getMethods call returns 28 methods. When I go through this with the debugger, this is the first method:

List<Property> getProperty()

This satisfies the conditions in the loop and the m.invoke method is called.

However, there is another item in the getMethods return value (item 6) that is for this method:

@DuckTyped <T> List<T> getRefs(Class<T> type);

This method also satisifies the conditions of the loop:

  • Collection.class.isAssignableFrom(List.class) is true
  • m.getGenericReturnType is a ParameterizedType
  • itemType is the Object class
  • Object.class.isAssignableFrom(Property.class) is true

So if the getRefs method is returned from getMethods before getProperty, then we get the failure indicated in the bug.

Adding the same fix as is in _deleteChild:

&& (m.getParameterTypes().length == 0)

will fix this problem.

Comment by Tom Mueller [ 15/Feb/12 08:11 PM ]

Assigning to Mahesh as this is an HK2 issue. Based on the analysis of this bug, it appears that this problem is specific to lb-config elements (unless there are other config beans that have methods with sufficiently similar signatures).

Comment by scatari [ 16/Feb/12 12:22 AM ]

This is too late to be considered for this release. Marking the bug for release notes, Please provide release notes info before COB 02/16/2012.

Comment by Rebecca Parks [ 17/Feb/12 06:31 PM ]

Added to the 3.1.2 Release Notes:

Description

If the JDK version is 1.7.0_03 and you attempt to set the rewrite-location load balancer property using the asadmin set command, the command fails.

Workaround

Set the rewrite-location property by editing the loadbalancer.xml file, located in the <web-server-install>/https-<machine-name>/conf directory.

Comment by varunrupela [ 17/Feb/12 07:11 PM ]

Adding Tom's comment to the issue, sent over e-mail:
"These method ordering bugs are sensitive to what has already happened in the JVM, such as class loading, object access, etc. "

The release notes can take into account the intermittent nature of the issue. The customer may or may not hit the issue.





[GLASSFISH-18336] Error starting remote, SSH instance after changing all log levels Created: 08/Feb/12  Updated: 15/Feb/13

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

Type: Bug Priority: Minor
Reporter: lidiam Assignee: naman_mehta
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

DAS on OEL 6 with JDK 7u3, b04
remote instance on Solaris 10 with JDK 7u3, b04
Firefox on Winxp


File Attachments: Java Archive File console-common.jar     JPEG File error-starting-instance.JPG     JPEG File logging-error-saving-changes.JPG     Text File logging.properties.das.txt     Text File logging.properties.instance.txt     Text File LoggingHandlers.diff.text     Text File server.log.badfileexception.txt     Text File server.log.das.txt     Text File server.log.instance.txt    
Tags: 312_qa 312_regression
Participants: Anissa Lam, Joe Di Pol, lidiam, naman_mehta and Rebecca Parks

 Description   

After changing all log levels for a remote instance, on SSH node, to WARNING, instance fails to start with the following error in Admin Console:

An error has occurred
Could not start instance intp on node tuppy (tuppy). Command failed on node tuppy (tuppy): CLI801 Instance is already synchronized Waiting for intp to start ..........Command start-local-instance failed. Error starting instance intp. The server exited prematurely with exit code 1. Before it died, it produced the following output: Launching GlassFish on Felix platform Completed shutdown of GlassFish runtime Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97) at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55) Caused by: java.lang.NullPointerException at com.sun.enterprise.server. .... msg.seeServerLog

Attaching server.log files.

I have tried it several times with b20 and b21 and it always happens in my setup with a remote instance on an SSH node. I does not happen when instance is on a DCOM node or on localhost. Changing just one or two log levels for an instance on SSH node does NOT trigger this error. However, I'm still logging this as a Major issue, so we at least investigate it, since this is not an unlikely scenario, to set all log levels to warning on a production system.

Steps to reproduce:

1. Create a remote SSH node.
2. Create a standalone instance under the new node and start it.
3. In Admin Console go to instance's configuration, Logger Settings, Log Levels.
4. Select checkboxes for all loggers, WARNING for Log Level drop down and click on Change Level. Then click on Save.
5. Go back to instance page and stop it.
6. Start the instance and the above mentioned error is displayed.



 Comments   
Comment by lidiam [ 08/Feb/12 02:37 AM ]

Once I change log levels to INFO for all loggers, and set com.sun.enterprise.server.logging.GFFileHandler level to ALL, instance starts fine once again. However, if I only change all log levels to INFO, instance still fails to start with the same exception. Please note that there is no "Load Default" button on this page, so user will have hard time finding out what were the default settings (it can be seen in default-conifg).

Comment by naman_mehta [ 08/Feb/12 04:24 AM ]

As per the error looks like logging.properties files are missing some entries on SSH node.

Can you send me logging.properties files from ssh machine?
Have you changed log levels through admin console?
Can you share same machine with me so I can check the same?

Comment by lidiam [ 08/Feb/12 05:19 AM ]

Attaching logging.properties.instance.remote.txt file - this is logging.properties file on the remote SSH node, under <glassfish home>/glassfish/nodes/tuppy/intp/config/intp-config directory.

Comment by lidiam [ 08/Feb/12 05:24 AM ]

I performed all operations from Admin Console, as described in steps to reproduce section. I attached logging.properties for the instance on the remote SSH node - the file is the same as on the DAS system, under domain1/config/intp-config (diff shows no difference). I also sent you an email with the machine information.

Comment by naman_mehta [ 08/Feb/12 05:25 AM ]

logging.properties file is correct...

Have you changed log levels through admin console? Can you share same machine with me so I can check the same? Is it reproducible/occasionally?

Comment by lidiam [ 08/Feb/12 06:07 AM ]

I have changed the log levels back to info, in order to see if instance would start then. I already wrote that all operations were performed through Admin Console, including setting the log levels. Please see the section above that starts with "Steps to reproduce". It is reproducible each time all log levels are set to WARNING.

Comment by naman_mehta [ 08/Feb/12 09:17 AM ]

I tried on my local machine with use of ssh node on another machine on linux but couldn't able to reproduce the same. I tried several times but no success.

Then, I tried on same machine and same setup having this issue filed but after several runs it couldn't be reproducible.

Comment by naman_mehta [ 08/Feb/12 09:19 AM ]

Lidia,

Please try yourself again on same machine by creating new node and new instance. If it's reproducible for you then stop using this machine. Let me know, I will debug same on this machine only by doing remote debug.

Comment by naman_mehta [ 08/Feb/12 11:36 AM ]

I would able to identify the issue: Sometimes logging.properties file is missing entries

Initially logging.properties file contains:
"logging.properties" 69 lines, 3756 characters

now after updating log levels from admin console
"logging.properties" 46 lines, 2285 characters

So missing some properties which is causing failure....

Comment by naman_mehta [ 08/Feb/12 12:15 PM ]

When you change log levels through admin console it's going to update logging.proeprties file on DAS and then trying to replicate on the instance machine. But sometimes we are stopping instance before replication is successful and which corrupts the logging.properties file on remote machine. If you check logging.properties file on DAS it's up to date and corrupted on remote machine.

Now, next time when you trying to start instance it's looking for some properties on startup and which are missing there and so it's not coming up.

Solution is to to avoid catastrophic failure in the absence of a user defined configuration property like com.sun.enterprise.server.logging.GFFileHandler.file.

Comment by lidiam [ 08/Feb/12 11:20 PM ]

I tried the following on newly created instance:

1. Changed all log levels to WARNING, waited 25 seconds after Admin Console reported logging changes saved.
Result: instance started fine.

2. Changed all log levels to INFO, waited 20 seconds after Admin Console reported logging changes saved.
Result: instance started fine.

3. Chagned all log levels to SEVERE - could not save the change with the following error in Admin Console:

An error has occurred
An error occurred during replication Failure: Command set-log-levels failed on server instance inbif: remote failure: Could not set logger levels for inbif-config. Failure: Command set-log-levels failed on server instance inbif: remote failure: Could not set logger levels for inbif-config.

The following exception was in the instance's server.log:

[#|2012-02-08T15:05:16.277-0800|SEVERE|oracle-glassfish3.1.2|null|ThreadID=19;
ThreadName=Thread-2;|Cannot read logging.properties file :
java.io.IOException: Bad file number
at java.io.FileInputStream.readBytes(Native Method)

I'm attaching instance's server.log as server.log.badfileexception.txt.

Comment by lidiam [ 09/Feb/12 12:13 AM ]

It looks like stopping of the instance is NOT the cause of bad logging.properties file being written to the remote machine. This looks like an intermittent problem with writing full logging.properties file to the remote machine. Once the "bad" file is written, I can wait for a minute before restarting server and it is not getting corrected. Here is what I tested:

1. Change all log levels and save.
2. Wait 30 seconds after save.
3. Compare size of logging.properties files on DAS and remote system.
4. Restart instance.

While executing the above, logging.properties file got corrupted on the 4th attempt - size differed between DAS and remote and instance failed to start. I tested further and again hit the issue on the 6th attempt (or 10th, 4 + 6 new attempts). The trouble is that once the instance cannot be started I can only fix it by manually copying logging.properties file from DAS to the instance. Other changes, also to logging properties, don't seem to trigger copying the file over.

Comment by lidiam [ 09/Feb/12 12:17 AM ]

I'm attaching logging.properties files from the time of failure:

t# ls -l logging.p*
rw-rr- 1 j2eetest green 3659 Feb 8 15:36 logging.properties.das
rw-rr- 1 j2eetest green 1278 Feb 8 15:36 logging.properties.instance

Comment by lidiam [ 09/Feb/12 12:18 AM ]

Example of error in Admin Console when logging changes cannot be saved due to corrupted logging.properties file.

Comment by lidiam [ 09/Feb/12 12:20 AM ]

Attaching logging.properties files with txt extension for easier viewing.

Comment by Joe Di Pol [ 09/Feb/12 01:20 AM ]

Workaround is to manually copy the logging.properties from the DAS to the instance that can't start.

Comment by naman_mehta [ 09/Feb/12 06:10 AM ]

set-log-level command has capability to update multiple log levels simultaneously.

Usage of command:
./asadmin set-log-levels --target in5-config javax.enterprise.system.container.cmp=INFO:javax.enterprise.resource.webcontainer.jsf.application=INFO:javax.enterprise.system.ssl.security=INFO

Here, all logger name are : separated.

In this scenario, logging back end code will open logging.properties files once update all log levels as passed and closing logging.properties file. So here all log levels are updated in single file operation.

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

In current scenario, when user updates all log level through admin console by selecting all logger names, it passes single logger name and log level to back end code then next time passes another logger name and log level. So if glassfish has 46 loggers it has 46 back end calls and due to that file operation is also becomes multiple of 46 and which causes file related exception in back end code.

Instead of this admin gui can consolidate all log levels with : separated as above and pass to back end code which cause single file operation and it avoids file related exceptions.

Comment by naman_mehta [ 09/Feb/12 06:21 AM ]

One more thing I monitored,

If user changes single log level for admin console then also it passes all logger names and levels to the back end code.

So for single log level updates from GUI also making 46 back end calls to set-log-level command.

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

Added to the 3.1.2 Release Notes:

Description

Changing all log levels on a remote SSH server instance before stopping the instance can cause the instance to fail to restart.

Workaround

Manually copy the logging.properties file from the domain administration server (DAS) to the server instance that won’t restart.

Comment by lidiam [ 09/Feb/12 06:44 PM ]

Now that this issue is understood fully I'm upgrading it to P2, after talking to Sudipa. Since logging.properties file is relatively likely to get corrupted, we should fix this issue for 3.1.2 if another show stopper is found for this release. I'm also reassigning to Admin Console, to evaluate the possible fix proposed by Naman.

Comment by Anissa Lam [ 09/Feb/12 09:47 PM ]

Agree that GUI shouldn't call changing of one log level at a time. Thats bad for performance too. I have fixed that in the trunk for 4.0

Log Message:
------------
Improve performance of GUI when changing log levels and to work around a bug in logging,