[GLASSFISH-21320] Automate check-up of Class-Path jar 'javaee.jar' Created: 27/Feb/15  Updated: 27/Feb/15

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

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


 Description   

Verify that all the required javax.* classes are present in the Class-Path jar 'javaee.jar'.
Possibly also verify that no other class files are present.

One way of doing this could be:

Reuse the list of spec that is defined under appserver/pom.xml, with a mojo in the spec-version-maven-plugin.

It would be similar to what we did to ensure all spec jars had compliant
metadata around the time of EE7/GFv4 release.

E.g. It could be an option to the current mojo "check-distribution", to check-up
a "class-path jar", or a separate mojo.

Possibly hook that by default in the build / CI job.






[GLASSFISH-21319] javax.inject.jar missing in javaee.jar Created: 27/Feb/15  Updated: 27/Feb/15

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

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


 Description   

In the GlassFish lib directory there's a javaee.jar that just contains
a manifest Class-Path header referring to other jar files. It's missing
javax.inject.jar. And it includes weld-osgi-bundle.jar, which has no javax
classes in it.






[GLASSFISH-21288] SHARED SUBSCRIPTIONS NOT WORKING WITH MDB TOPIC DURABLE SUBSCRIBERS Created: 13/Jan/15  Updated: 13/Jan/15

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

Type: Bug Priority: Major
Reporter: cmundt Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms

 Description   

See :GlassFish bug 19568699 - SHARED SUBSCRIPTIONS NOT WORKING WITH MDB TOPIC DURABLE SUBSCRIBERS


When Glassfish is configured to use a remote Broker(s) it is unable to establish a shared durable subscription however when using an EMBEDDED broker it will create a shared subscription fine.

This has been replicated in GF 3.1.2.2, GF 4.0 build 89, and GF Build 13.

Would like to see a fix back filled to GF 4.x if possible.






[GLASSFISH-21226] Java EE 6 API in the Maven repository has an incorrect method. Created: 08/Oct/14  Updated: 27/Feb/15

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

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

OS: Windows 7 (x64)
Java: JDK 8, Java(TM) SE Runtime Environment 1.8.0_11-b12
IDE: Netbeans IDE 8.0.1


Issue Links:
Relates
relates to GLASSFISH-11389 javax:javaee-api:6.0 and javax.jvaee-... Open

 Description   

I am not sure you are responsible to correct the error, but the Java EE 6 API registered in the Mave repository has an incorrect method in interface javax.enterprise.inject.spi.BeforeBeanDiscovery. It is specified in the API document to have the following method:

void addInterceptorBinding(java.lang.Class<? extends java.lang.annotation.Annotation> bindingType, java.lang.annotation.Annotation... bindingTypeDef)

But the one from the Mave repository has this one instead:

void addInterceptorBinding(Class<? extends Annotation> type)

This may cause false compilation errors in some programs. It should be updated to match the API document..



 Comments   
Comment by Romain Grécourt [ 08/Oct/14 ]

There is no "javadoc" artifact for the official EE6 API maven artifact: javax.javaee:javaee-api:6.0.
Can you please provide maven coordinates for these artifacts (include the so-called API document)?

Comment by kazssym [ 08/Oct/14 ]

The API document at http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/spi/BeforeBeanDiscovery.html#addInterceptorBinding(java.lang.Class,%20java.lang.annotation.Annotation...) describes the former is correct and one of projects I have fails with the javaee-api 6.0 dependency. To make it builds successful, I must add another dependency on cdi-api 1.0-SP4 to override the interface definition in javaee-api 6.0. AFAIK, the Java EE 6 API includes the CDI 1.0 specification, doesn't it?

Comment by Romain Grécourt [ 09/Oct/14 ]

cdi-1.0 (javax.enterprise:cdi-api:1.0:jar) is what is included in the javaee6 api jar:

> javap -cp ./javaee-api-6.0.jar javax.enterprise.inject.spi.BeforeBeanDiscovery

public interface javax.enterprise.inject.spi.BeforeBeanDiscovery {
  public abstract void addQualifier(java.lang.Class<? extends java.lang.annotation.Annotation>);
  public abstract void addScope(java.lang.Class<? extends java.lang.annotation.Annotation>, boolean, boolean);
  public abstract void addStereotype(java.lang.Class<? extends java.lang.annotation.Annotation>, java.lang.annotation.Annotation...);
  public abstract void addInterceptorBinding(java.lang.Class<? extends java.lang.annotation.Annotation>);
  public abstract void addAnnotatedType(javax.enterprise.inject.spi.AnnotatedType<?>);
}

> javap -cp ./cdi-api-1.0.jar javax.enterprise.inject.spi.BeforeBeanDiscovery

public interface javax.enterprise.inject.spi.BeforeBeanDiscovery {
  public abstract void addQualifier(java.lang.Class<? extends java.lang.annotation.Annotation>);
  public abstract void addScope(java.lang.Class<? extends java.lang.annotation.Annotation>, boolean, boolean);
  public abstract void addStereotype(java.lang.Class<? extends java.lang.annotation.Annotation>, java.lang.annotation.Annotation...);
  public abstract void addInterceptorBinding(java.lang.Class<? extends java.lang.annotation.Annotation>);
  public abstract void addAnnotatedType(javax.enterprise.inject.spi.AnnotatedType<?>);
}

However, there is indeed a discrepancy between the official javadoc and the API artifact (javax.javaee:javaee-api:6.0:jar).
I will follow-up on that.

Comment by Romain Grécourt [ 27/Feb/15 ]

linking to GLASSFISH-11389 as this will require an update to the EE6 combined maven artifacts.





[GLASSFISH-21214] QL AMX/JMX test failure with JDK8 Created: 25/Sep/14  Updated: 25/Sep/14

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

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

JDK8



 Description   

Test output shows:

   [testng] PROBLEMS:
   [testng] null:type=Null,name=Null

Nothing obvious in the server log.

Title and Description to be updated when initial investigation is done.






[GLASSFISH-21163] Include ../modules/cdi-api.jar in the Class-Path: section of META-INF/MANIFEST.MF in ${com.sun.aas.installRoot}/lib/javaee.jar Created: 12/Aug/14  Updated: 24/Mar/15

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

Type: Bug Priority: Minor
Reporter: rgoldberg Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 5 minutes
Time Spent: Not Specified
Original Estimate: 5 minutes
Environment:

All


Tags: cdi, jar, javaee, manifest, modules

 Description   

The:

Class-Path:

section of the file:

META-INF/MANIFEST.MF

in the jar file:

$

{com.sun.aas.installRoot}

/lib/javaee.jar

should include:

../modules/cdi-api.jar

Other Java EE jars might be missing from that manifest, too, but I haven't checked.



 Comments   
Comment by rgoldberg [ 12/Aug/14 ]

In the Description, I forgot to escape the opening brace and closing brace, so .${com.sun.aas.installRoot}/lib/javaee.jar is formatted poorly.

I cannot seem to edit the Description.

Can someone escape the braces?

Comment by rgoldberg [ 25/Aug/14 ]

Will this be fixed anytime soon?

It should only take 30 seconds to add ../modules/cdi-api.jar to the Class-Path: section.

It might take a few minutes (around 2 - 5) to check if any other jars should also be included.





[GLASSFISH-21035] FileRealm.getGroupNames throws NPE when user does not exist. Created: 09/Apr/14  Updated: 24/Apr/14

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: 3.1.2_b23, 3.1.2.2
Fix Version/s: future release

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

JDK 1.6.0_45 on Windows and RHEL.



 Description   

Regarding com.sun.enterprise.security.auth.realm.file.FileRealm implementation.

The following code fragment will result in a NullPointerException being thrown from a servlet's service method when user "FOO" does not exist:

FileRealm realm = new FileRealm("keyfile");
realm.getGroupNames("FOO");

Method signature for getGroupNames indicates it throws NoSuchUserException but this is not the case.

The sequence:

FileRealm realm = new FileRealm("keyfile");
realm.getUser("FOO");

does throw NoSuchUserException.






[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: deployment, devtests

 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 ]

update the script snippet I'm using currently





[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: admin-gui

 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 ]

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
Labels: None
Remaining Estimate: 2 weeks
Time Spent: Not Specified
Original Estimate: 2 weeks
Environment:

any


Tags: devtest, glassfish, maven, test

 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
Labels: None
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


Attachments: JPEG File overlap_application_browseButton.jpg    

 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 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Server 2008 r2, 24 GB ram, 16 cores



 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 ]

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 ]

How do you attach files?

Comment by Anissa Lam [ 09/Oct/13 ]

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 ]

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 ]

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

Comment by vaughnmb [ 09/Dec/13 ]

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-20841] GlassFish submits wrong Client certificate and throws bad_certificate SSL error from Webservice Created: 02/Oct/13  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: gfuser9999 Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:
  • GlassFish 2.1.x (if httpsOutBoundKeyAlias is set)
  • GFv301x
  • GFv312x
  • GFv4

Tags: Axis, SSL, bad_certificate, certificate, chooseClientAlias, client, handshake, https, s1as

 Description   

Background

This problem happens especially in GFv3.x as the following
JVM options is added -Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as
The impact of this is that it sets the default client cert
to be sent is s1as.

Although this option is there is GFv2, it was not enabled in the JVM
options. So no issues unless one set it. Now the internals of GFv3 opensource
suggest that on startup
1) GFv301 will replace the HttpsURLConnection setDefault to have
a KeyManager that will sent "httpsOutboundKeyAlias"/s1as is client cert
is requested.
2) Gfv312 also does this
3) Now in GFv301, it does not set the SSLContext but in GFv312x
due to change GLASSFISH-15369, it seems that SSLContext.setDefault()
is called to make the SSLContext have a default key manager
that will submit s1as as the client cert if requested

Well the behaviour is that things that work say in GFv2 may not
work in GFv301 (if URLConnection to a https://... that does
optional client cert request). For example

==> https://www.java.net//forum/topic/glassfish/glassfish/axis2-generated-stub-soap-webservice-call-not-working-glassfish-312?force=516

where javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
may happen in GFV312 (but may work in GFv301) due to (3).

Now the problem is this

The issue is that
a) GFv3 set the default alias to sent the client cert globally
b) In GFv312, SSL artifact created from
HttpsURLConnection and SSLContext will have this KeyManager that
does chooseClientAlias() from X509ExtendedKeymanager and always returns s1as
irregardless if the issuer matches with s1as

Look at J2EEKeyManager.java
https://java.net/projects/glassfish/sources/svn/content/tags/3.1.2/security/core/src/main/java/com/sun/enterprise/security/ssl/J2EEKeyManager.java

As you may see, from the code, the fix/issues are:

a) Not setting com.sun.enterprise.security.httpsOutboundKeyAlias may help
(if you do not ever use client cert) but the code may always return null
for some conditions (ie: !server&!acc)
b) Even if the property is explicitly set, the chooseClientAlias
should still check if this alias is compatible with what the SSL server
requested otherwise it should return NULL

Symptom
For this issue even if you added all the SSL cert to the client trust store, if the remote SSL server ask for say an optional client cert (or required), the handshake will fail since the wrong client cert (self-signed s1as) is submitted which is totally different from the valid cert the server accepts.

javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1961)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077)
at sun.security.ssl.SSLSocketImpl.waitForClose(SSLSocketImpl.java:1707)
at sun.security.ssl.HandshakeOutStream.flush(HandshakeOutStream.java:122)
at sun.security.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:972)
at sun.security.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:1087)
at sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:1006)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:285)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:804)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1016)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:515)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)





[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
Labels: None
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days

Tags: 3rdparty, maven, osgi, packaging

 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: 23/Dec/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: 5
Labels: None
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-reviewed, admin-gui

 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)



 Comments   
Comment by MisterNibble [ 18/Dec/14 ]

I can confirm the same issue; exception at org.glassfish.admingui.common.util.GuiUtil.genId(GuiUtil.java:343) with the official Glassfish 4.1 release on Ubuntu 12.04 x64 (with all latest updates) and JDK 1.8.0_25-b17 x64. This is after I patched to the latest version of Tyrus (1.9), updated Java Server Faces (javax.faces.jar) to 2.2.8-04 and upgraded nucleus-grizzly-all.jar to 2.3.17 (without which my application is completely unusable).

This error also causes application deployment to fail in Netbeans 8.0.2 because Netbeans requires a usable Admin interface to deploy.

Comment by smillidge-c2b2 [ 20/Dec/14 ]

Can you provide step by step instructions to reproduce?

Comment by MisterNibble [ 21/Dec/14 ]

The error occurs when the Admin console is open in a tab for a few hours. No discernible cause besides that.

Comment by arie_golos [ 23/Dec/14 ]

I can also add to the above MisterNibble comment, that I observed that problem in Chrome today, but when I pasted the same login URL in IE, it worked just fine.





[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
Labels: None
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days

Tags: finsbugs, maven, netbeans

 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
Labels: None
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Tags: findbugs, logging, logging-annotation-processor, maven

 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
Labels: None
Remaining Estimate: 1 week
Time Spent: Not Specified
Original Estimate: 1 week

Tags: l0n, maven

 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: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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: 19/Sep/14

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

Type: Bug Priority: Major
Reporter: xianwu Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Labels: None
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)



 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 ]

Hi Anissa

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

Regards, Xianwu





[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Tags: custom_resource, description, jndi

 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-20679] After returned from setupSecurityContext(), should check whether CallerPrincipalCallback is handled Created: 03/Jul/13  Updated: 11/Sep/14

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: not determined
Fix Version/s: future release

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

Tags: jca

 Description   

According to the section 16.4.5.1 "Case A: Establishing a Single Principal as the Caller Identity" of JCA1.6 Spec, if a resource adapter intends to establish an authenticated caller identity, and the principal Set of the executionSubject contains exactly the one Principal, then the setupSecurityContext() do not has to use the container provided CallbackHandler to handle a CallerPrincipalCallback.

In this case, the container must check whether or not it handled the CallerPrincipalCallback after returned from setupSecurityContext(). If it determines that it did not handle any Callbacks, the container must transform the contents of the executionSubject, as if they are handled through the Callbacks on behalf of the resource adapter.

But according to the method setupSecurityWorkContext (as below) of the class WorkContextHandlerImpl, GlassFish does not support the Case A. If setupSecurityContext() do not call CallbackHandler, GlassFish will ignore the content of executionSubject and setup up an unauthenticated identity for Work instance.

private void setupSecurityWorkContext(SecurityContext securityWorkContext,
WorkContextLifecycleListener listener, String raName)
throws WorkCompletedException{
try

{ Subject executionSubject = new Subject(); Subject serviceSubject = new Subject(); Map securityMap = getWorkContextMap(raName); CallbackHandler handler = new ConnectorCallbackHandler(executionSubject, runtime.getCallbackHandler(), securityMap); securityWorkContext.setupSecurityContext(handler, executionSubject, serviceSubject); // Need check whether the CallbackHandler is called or not here for Case A. notifyContextSetupComplete(listener); }

catch (Exception e)

{ ... ... }

}






[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: admin-gui, stateless, webservice

 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 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows


Tags: fishcat

 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 ]

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 ]

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 ]

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 ]

edit subject to better describe the issue.





[GLASSFISH-20589] AzResource URI Path encoding problems Created: 29/May/13  Updated: 24/Apr/14

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

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

Nucleus



 Description   

The CommandSecurityChecker is creating AzResource URI by URL encoding the URI Path with the following logical operation:

new URI(ADMIN_RESOURCE_SCHEME, URLEncoder.encode(resourceName, RESOURCE_NAME_URL_ENCODING), null)

As an example, when using input resourceName as "/users/user/admin" this approach results in the following output from the constructed URI object:

URI.toString() 'admin:%252Fusers%252Fuser%252Fadmin'
URI.toASCIIString() 'admin:%252Fusers%252Fuser%252Fadmin'
uri.getAuthority() 'null'
uri.getPath() 'null'

thus yielding the AzResource based on the URI object unable to obtain proper the proper Path information.



 Comments   
Comment by Craig Perez [ 29/May/13 ]

Without URL encoding the following more expected output results:

URI.toString() 'admin:/users/user/admin'
URI.toASCIIString() 'admin:/users/user/admin'
uri.getAuthority() 'null'
uri.getPath() '/users/user/admin'





[GLASSFISH-20588] Principal Classes have serious problems Created: 29/May/13  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: Byron Nevins Assignee: Craig Perez
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Ref: Joshua Bloch, Effective Java, 2nd edition, item #8
Mr. Bloch does an excellent job of describing precisely the problem in these classes:
(all in common-util)
common/common-util/src/main/java/org/glassfish/security/common/Role.java
common/common-util/src/main/java/org/glassfish/security/common/Group.java
common/common-util/src/main/java/org/glassfish/security/common/Principal.java
3 problems:
(1) These problems are the only low level FindBugs issues in all of common-util.
(2) The equals/hash methods are a mess. Look at the FB results for common-utils. Especially look at the way the base class equals() method chedcks to see if the other object is a Group. Note how it doesn't check if it is a Role (why?). This is quite brittle. The base class ought to know nothing about subclasses!
(3) Even though all three classes implement the Principal interface, the outside calling code does NOT use it. Instead, it uses PrincipalImpl. Why bother with an interface if it isn't used ? Should either use them as a class hierarchy OR as references to interfaces.
I attempted to fix this using Bloch's recommendation which is to use composition instead of inheritance. I.e. I made all three implement the interface directly. Then Role and Group stopped being subclasses. This failed because outside code is looking for PrincipalImpl objects - not Principal objects.
PrincipalImpl pi = new PrincipalImpl("foo");
Group g = new Group("foo");
Role r = new Role("foo");
pi.equals(r) --> true
r.equals(pi) --> false






[GLASSFISH-20585] Command model update does not work correctly for cluster command replication Created: 28/May/13  Updated: 11/Sep/14

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

Type: Bug Priority: Major
Reporter: martin.mares Assignee: martin.mares
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Command model update does not work correctly for cluster command replication.
Quicklooks can demonstrate it.






[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
Labels: None
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

 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 ]

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
Labels: None
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


Attachments: JPEG File adminObjectResource_dropdownList.jpg     JPEG File connectorConnectionPool_dropdownList.jpg     JPEG File workSecurity_dropdownList.jpg    

 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
Labels: None
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


Attachments: JPEG File updateTool_link.jpg    

 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 ]

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 ]

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-20485] appclient -user xxx option is ignored unless -passwordfile is given Created: 08/May/13  Updated: 24/Apr/14

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

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

GlassFish 3.1.1, Win 7 Pro SP 1 (64 Bit), JDK 1.7.0_21



 Description   

Steps to reproduce:

  • appclient -name myname -client MyClient.jar

Expected result:

  • Login dialog should default user name to "myname".

Actual result:

  • Login dialog defaults user name to Windows Account.


 Comments   
Comment by Tim Quinn [ 08/May/13 ]

Updated title and component; this applies to the appclient utility

Comment by Tim Quinn [ 08/May/13 ]

The "-name" option on the appclient command specifies the name of the app client to be executed (especially if there are multiple app clients in the EAR), not to tell what username to use for authentication.

The "-user" option is used for specifying the username on the command line.

Markus, can you please confirm whether you are actually using "-name" or "-user" in your example?

Comment by mkarg [ 10/May/13 ]

Sorry for the typos, I was in a hurry.

Actually I typed:

appclient -user myname -Client MyClient.jar

And the ACC's login dialog Shows the user Name field defautled to the value "MARKUS KARG" (which seems to be taken from active directory), but not "myname".

Comment by Tim Quinn [ 24/May/13 ]

I am reassigning this to the security team.

The app client container invokes AppClientSecurityInfoImpl's constructor, passing the username (if the user provided one on the command line, null otherwise).

I looked around a little and it seems that ClientPasswordLoginModule interrogates the UsernamePasswordStore to retrieve a user-provided username and/or password but the code seems not to use those values (I concentrated on the username) in setting the default value in the callback.





[GLASSFISH-20470] NullPointerException loading JMS dest UI mngmt after stopping a cluster Created: 06/May/13  Updated: 11/Sep/14

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

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


 Description   

The exception bellow was throw after doing the following steps:

1. Create a cluster
2. Add two instances
3. Start cluster
4. Create a JMS Destination 'myQueue' targeted to this cluster
5. Stop the cluster
6. Reopen the JMS destination 'myQueue' configuration page
7. NullPointerException raised

[2013-05-05T22:21:30.948-0300] [glassfish 4.0] [SEVERE] [] [org.glassfish.admingui] [tid: _ThreadID=34 _ThreadName=admin-listener(3)] [timeMillis: 1367803290948] [levelValue: 1000] [[
  RestResponse.getResponse() gives FAILURE.  endpoint = 'http://localhost:4848/management/domain/resources/admin-object-resource/jms%2FmyQueue/property.json'; attrs = '{}']]

[2013-05-05T22:21:30.952-0300] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=34 _ThreadName=admin-listener(3)] [timeMillis: 1367803290952] [levelValue: 900] [[
  StandardWrapperValve[FacesServlet]: Servlet.service() for servlet FacesServlet threw exception
java.lang.NullPointerException
	at java.util.ArrayList.addAll(ArrayList.java:530)
	at org.glassfish.admingui.common.handlers.CommonHandlers.filterTable(CommonHandlers.java:717)
	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.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)


 Comments   
Comment by Bruno Borges [ 06/May/13 ]

I'm not sure now if the steps do reproduce the problem are correct.

Another possibiltiy is that the destination has been deleted, but it remained visible in the navigation tree on the left panel. And when I clicked, it threw the exception above





[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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 ]

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

Comment by jjsnyder83 [ 18/Jun/13 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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 ]

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 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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 ]

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 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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 ]

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 ]

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 ]

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 ]

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-20413] automate jms resource creation for weld glassfish tck runner Created: 25/Apr/13  Updated: 11/Sep/14

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

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: phil.zampino
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See
https://github.com/weld/weld-glassfish-tck-runner/blob/master/src/test/java/org/jboss/weld/tck/glassfish/GlassFishResourceManager.java#L36

Wouldn't it be better to support this directly in the Managed/Remote containers in the same way it's done for Embedded, by exposing a configuration option in ContainerConfiguration. Then any user can install a global resources.xml file during the lifetime of the test execution. Installed in start(), removed in stop() ?

glassfish embedded configuration:
https://github.com/arquillian/arquillian-container-glassfish/blob/master/glassfish-embedded-3.1/src/main/java/org/jboss/arquillian/container/glassfish/embedded_3_1/GlassFishConfiguration.java#L156

glassfish embedded impl:
https://github.com/arquillian/arquillian-container-glassfish/blob/master/glassfish-embedded-3.1/src/main/java/org/jboss/arquillian/container/glassfish/embedded_3_1/GlassFishContainer.java#L186

glassfish-resources.xml example: https://github.com/ahhughes/glassfish3x.resources.xml.example/blob/master/glassfish3x-resources-xml-example-ear/src/main/application/META-INF/glassfish-resources.xml



 Comments   
Comment by jjsnyder83 [ 25/Apr/13 ]

The arquillian.xml property, in this case, allow for a , separated list of resource file references. Tho I'm pretty sure you could define two jms resources in one resource.xml file as well.





[GLASSFISH-20377] Unable to create file users after changing key file of the file realm Created: 23/Apr/13  Updated: 24/Apr/14

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

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


 Description   

This is GlassFish 3.1.2.2 and GlassFish 4 issue.

After changing the key file of file realm of cluster,
I could not create file users.

ex)

asadmin create-auth-realm --classname com.sun.enterprise.security.auth.realm.file.FileRealm --property jaas-context=fileRealm:file=${com.sun.aas.instanceRoot}/config/keyfile1 test
asadmin set cluster.security-service.auth-realm.test.property.file=${com.sun.aas.instanceRoot}/config/keyfile2
asadmin stop-cluster cluster
asadmin start-cluster cluster
asadmin create-file-user --target cluster --authrealmname test user1

This error happened when executing asadmin create-file-user command.

The specified physical file C:\gf4b82\glassfish4\glassfish\domains\domain1/config/keyfile2 associated with the file realm test does not exist.

Likewise, if I set the key file to the other directory of glassfish (such as C:\work\keyfile),
asadmin create-file-user shows this error.
However, file users were created in the key file.

An error occurred during replication Failure: Command create-file-user failed on server instance instance: remote failure: Adding User user1 to file realm test failed. User user1 already exists.

If I tried GlassFish 2.1.1, these problem did not occur.






[GLASSFISH-20363] security devtests cert-realm-custom-loginmodule failure Created: 19/Apr/13  Updated: 24/Apr/14

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

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

security-devtests-trunk



 Description   

The cert-realm-custom-loginmodule security devtest is failing and has been disabled.

The client is being denied access to the test application that us using <CLIENT-CERT> authentication method.

Debug of the client SSL handshake looks fine but there is no information in the server log so further debug is needed.



 Comments   
Comment by Craig Perez [ 19/Apr/13 ]

Server log entries:

[2013-04-19T15:15:31.082-0700] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=34 _ThreadName=admin-listener(3)] [timeMillis: 1366409731082] [levelValue: 800] [[
cert-realm-custom-loginmodule-web was successfully deployed in 3,797 milliseconds.]]

[2013-04-19T15:15:35.145-0700] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=100 _ThreadName=Thread-16] [timeMillis: 1366409735145] [levelValue: 800] [[
Server shutdown initiated]]





[GLASSFISH-20339] security devtests wss roles failures Created: 17/Apr/13  Updated: 24/Apr/14

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

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

security-devtests-trunk



 Description   

Disabled the roles tests for security devtests wss suite.

[exec] Apr 12, 2013 4:41:47 PM org.glassfish.appclient.client.acc.AppclientCommandArguments warnAboutPasswordUsage
[exec] WARNING: ACC013: The -password option is deprecated and will likely be removed in a future release. Please use -passwordfile or let the app client container prompt for the username and/or password if they are needed to access a remote resource.
[exec] com.sun.xml.ws.fault.ServerSOAPFaultException: Client received SOAP Fault from server: java.lang.Exception: Client not authorized for invocation of public java.lang.String com.sun.s1asdev.security.wss.roles.ejbws.HelloEjb.hello(java.lang.String) Please see the server log to find more detail regarding exact cause of the failure.



 Comments   
Comment by Craig Perez [ 17/Apr/13 ]

Additionally the roles2, ssl & sslclientcert where previously disabled

  • roles2 has same/similar test failure
  • ssl and sslclientcert have build failures on wsimport looking for WSDL at HTTPS URL




[GLASSFISH-20338] security devtests ciphertest failures Created: 17/Apr/13  Updated: 24/Apr/14

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

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

security-devtests-trunk



 Description   

Disabled tests for ciphers:

  • SSL_RSA_WITH_DES_CBC_SHA
  • SSL_RSA_EXPORT_WITH_RC4_40_MD5

Use of -Dsun.security.ssl.allowUnsafeRenegotiation=true no impact both server and client side






[GLASSFISH-20337] security devtests jmac failure Created: 17/Apr/13  Updated: 24/Apr/14

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

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

security-devtests-trunk



 Description   

The security-jmac-httpservlet test in the jmac security devtests suite is failing and has been disabled.

The expected output includes an adjusted PrintWriter count that is not matching the golden files output.

Otherwise the general behavior and functional output looks correct.



 Comments   
Comment by Craig Perez [ 17/Apr/13 ]

From examining the test case, the MyHttpServletResponseWrapper.java only overrides the method write(char[] cbuf, int off, int len) and the test currently outputs a count of 0 vs 218 along with the blank lines that are not lining up 1-1 as previously.

Functionally the SAM is working but either the MyPrintWriter needs changes or the goldenfiles could be updated since the test will validate basic ServerAuthModule wrappering.

[webtest] Expected Output ****************************************
[webtest] Hello World from 196 HttpServlet AuthModule Test!
[webtest] <hr>
[webtest] Hello, shingwai123 from com.sun.s1asdev.security.jmac.httpservlet.HttpServletTestAuthModule
[webtest] PC = security-jmac-httpservlet-web/security-jmac-httpservlet-web
[webtest]
[webtest]
[webtest] <hr>
[webtest] Adjusted count: 218
[webtest]
[webtest] ********************************************************
[webtest] Actual Output ##########################################
[webtest] Hello World from 196 HttpServlet AuthModule Test!
[webtest] <hr>
[webtest] Hello, shingwai123 from com.sun.s1asdev.security.jmac.httpservlet.HttpServletTestAuthModule
[webtest] PC = security-jmac-httpservlet-web/security-jmac-httpservlet-web
[webtest]
[webtest] <hr>
[webtest]
[webtest] Adjusted count: 0





[GLASSFISH-20336] ejb.security_preinvoke_exception for security devtests Created: 17/Apr/13  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: Craig Perez Assignee: JeffTancill
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

security-devtests-trunk



 Description   

The security devtests mdb and timerStandalone have been disabled from the set of tests. These tests both fail for the same root cause:

java.lang.NullPointerException
at java.util.Arrays$ArrayList.<init>(Arrays.java:2842)
at java.util.Arrays.asList(Arrays.java:2828)
at com.sun.enterprise.security.auth.realm.file.FileRealm.getGroupNames(FileRealm.java:299)
at com.sun.enterprise.security.auth.login.LoginContextDriver.loginPrincipal(LoginContextDriver.java:295)
at org.glassfish.ejb.security.application.EJBSecurityManager$2.run(EJBSecurityManager.java:857)
at com.sun.enterprise.security.common.AppservAccessController.doPrivileged(AppservAccessController.java:61)
at org.glassfish.ejb.security.application.EJBSecurityManager.loginForRunAs(EJBSecurityManager.java:855)
at org.glassfish.ejb.security.application.EJBSecurityManager.preInvoke(EJBSecurityManager.java:824)
at org.glassfish.ejb.security.application.EjbSecurityComponentInvocationHandler$1.beforePreInvoke(EjbSecurityComponentInvocationHandler.java:76)
at org.glassfish.api.invocation.InvocationManagerImpl.preInvoke(InvocationManagerImpl.java:180)



 Comments   
Comment by Craig Perez [ 17/Apr/13 ]

mdb test:

[2013-04-17T11:25:00.018-0700] [glassfish 4.0] [SEVERE] [ejb.security_preinvoke_exception] [javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application] [tid: _ThreadID=33 _ThreadName=admin-listener(2)] [timeMillis: 1366223100018] [levelValue: 1000] [[
SECEJB9000: Exception while running pre-invoke
java.lang.NullPointerException
at java.util.Arrays$ArrayList.<init>(Arrays.java:2842)
at java.util.Arrays.asList(Arrays.java:2828)
at com.sun.enterprise.security.auth.realm.file.FileRealm.getGroupNames(FileRealm.java:299)
at com.sun.enterprise.security.auth.login.LoginContextDriver.loginPrincipal(LoginContextDriver.java:295)
at org.glassfish.ejb.security.application.EJBSecurityManager$2.run(EJBSecurityManager.java:857)
at com.sun.enterprise.security.common.AppservAccessController.doPrivileged(AppservAccessController.java:61)
at org.glassfish.ejb.security.application.EJBSecurityManager.loginForRunAs(EJBSecurityManager.java:855)
at org.glassfish.ejb.security.application.EJBSecurityManager.preInvoke(EJBSecurityManager.java:824)
at org.glassfish.ejb.security.application.EjbSecurityComponentInvocationHandler$1.beforePreInvoke(EjbSecurityComponentInvocationHandler.java:76)
at org.glassfish.api.invocation.InvocationManagerImpl.preInvoke(InvocationManagerImpl.java:180)
at org.glassfish.ejb.mdb.MessageBeanContainer.<init>(MessageBeanContainer.java:248)
at org.glassfish.ejb.mdb.MessageBeanContainerFactory.createContainer(MessageBeanContainerFactory.java:63)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:221)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:291)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:206)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
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 com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
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 org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
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.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:722)
]]

Comment by Craig Perez [ 17/Apr/13 ]

timeStandalone test:

[2013-04-17T11:29:06.808-0700] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=98 _ThreadName=Thread-3] [timeMillis: 1366223346808] [levelValue: 800] [[
In SfulEJB:hello()]]

[2013-04-17T11:29:06.819-0700] [glassfish 4.0] [SEVERE] [ejb.security_preinvoke_exception] [javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application] [tid: _ThreadID=98 _ThreadName=p: thread-pool-1; w: 2] [timeMillis: 1366223346819] [levelValue: 1000] [[
SECEJB9000: Exception while running pre-invoke
java.lang.NullPointerException
at java.util.Arrays$ArrayList.<init>(Arrays.java:2842)
at java.util.Arrays.asList(Arrays.java:2828)
at com.sun.enterprise.security.auth.realm.file.FileRealm.getGroupNames(FileRealm.java:299)
at com.sun.enterprise.security.auth.login.LoginContextDriver.loginPrincipal(LoginContextDriver.java:295)
at org.glassfish.ejb.security.application.EJBSecurityManager$2.run(EJBSecurityManager.java:857)
at com.sun.enterprise.security.common.AppservAccessController.doPrivileged(AppservAccessController.java:61)
at org.glassfish.ejb.security.application.EJBSecurityManager.loginForRunAs(EJBSecurityManager.java:855)
at org.glassfish.ejb.security.application.EJBSecurityManager.preInvoke(EJBSecurityManager.java:824)
at org.glassfish.ejb.security.application.EjbSecurityComponentInvocationHandler$1.beforePreInvoke(EjbSecurityComponentInvocationHandler.java:76)
at org.glassfish.api.invocation.InvocationManagerImpl.preInvoke(InvocationManagerImpl.java:180)
at com.sun.ejb.containers.BaseContainer.createEjbInstanceAndContext(BaseContainer.java:1628)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:456)
at com.sun.ejb.containers.StatelessSessionContainer.access$000(StatelessSessionContainer.java:97)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:698)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:246)
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:430)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2516)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1906)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:204)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
at $Proxy267.hello(Unknown Source)
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.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:143)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:173)
at com.sun.corba.ee.impl.protocol.ServerRequestDispatcherImpl.dispatchToServant(ServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.ServerRequestDispatcherImpl.dispatch(ServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequestRequest(MessageMediatorImpl.java:1549)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequest(MessageMediatorImpl.java:1425)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleInput(MessageMediatorImpl.java:930)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:213)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequest(MessageMediatorImpl.java:694)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.dispatch(MessageMediatorImpl.java:496)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.doWork(MessageMediatorImpl.java:2222)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
]]

Comment by bebbo [ 29/Jul/13 ]

suggested fix: add a null check and create an empty array if null.

if (groups == null)
  groups = new String[0];
return Collections.enumeration(Arrays.asList(groups));




[GLASSFISH-20321] Saving server properties in Glassfish console leads to blank page Created: 16/Apr/13  Updated: 11/Sep/14

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

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

Glassfish 3.1.2.2 b5



 Description   

Saving server properties (and other pages) occationally (ok, quite often) leads to just a blank page, and nothing being saved.



 Comments   
Comment by Anissa Lam [ 16/Apr/13 ]

Can you provide more info ?
Which platform and browser are you using to reproduce this ?
When you say "server properties", do you mean the Sever tree node -> "Properties" tab -> "System Properties" sub-tab or do you mean the "Instance Properties" sub-tab ?
I have tried both tab on my Mac using Glassfish 3.1.2.2b5 for more than 10 times, and cannot reproduce it.
Please include the exact property name and value you are saving.
thanks.

Comment by Tobb [ 16/Apr/13 ]

I am using Google Chrome on Windows 7. I'm logging in through remote login (not on the server itself).

By server properties I mean "Server (Admin server)", the "Properties" tab, and the "System properties"

The problem now occured the first time I tried, did not change any properties.

I also tried viewing the source of the blank page (with Chrome's Inspect element), and it appears that all the html is in place (the correct areas are highlighted when i hover them). Just, nothing is visible.

It also appears that if the save goes well once, repeated clicks on the save button will also be successful. I will try to restart my browser to see if this is something that happens the first time one tries to save.

Comment by Tobb [ 16/Apr/13 ]

It seems that the problem is most appearant the first time one tries.

I have tried 6 different glassfish-servers, just logging in and going directly to the page in question and hitting save, for 4 of them gave back the blank page. But, the strange thing is that all subsequent saves have been successful, even if I relogin or restart the browser completely. So it might be a problem that occurs after idling for a while or something.

Also, I noticed that the body-element of the page that is loaded after hitting save has a css-element stating "display: none;" in the file index.jsf:92, this was enabled when it returned a blank page, disabled when the page had content. The line in question has a comment "clickjacking defense", maybe it has something to do with this?

Comment by Anissa Lam [ 16/Apr/13 ]

Thanks for the information. Based on the description and the severity of the bug, I am lowering this to minor.
We are now at RC2 build for GlassFish 4.0, and only allows critical bug fix.
I will continue to investigate this, but its targeted for 4.1 now.
thanks.





[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OS



 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 ]

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 ]

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

Comment by Snjezana Sevo-Zenzerovic [ 17/Apr/13 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

WIN7 FF19 IE


Tags: admingui, docs, log, raw

 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 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7 FF19 , IE


Tags: admingui, log, search, viewer

 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 ]

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.





[GLASSFISH-20242] ADMINGUI : Add property changes context information values Created: 09/Apr/13  Updated: 11/Sep/14

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

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

WIN 8 FF19


Tags: adminguil, concurrency

 Description   

Issue : 1 Add property changes context information values

new context service screen provide jndi name, select context information as "security" alone , Description.
click "AddProperty" when you click this button you will see all the context information are selected. ( changes the selected value )

The above issue is available with other concurrency resources ( Managed thread factory, managed executor service and managed scheduled executor service )



 Comments   
Comment by Anissa Lam [ 09/Apr/13 ]

I am downgrading this to minor and will look into this for next release.
The page is simple enough that user can easily select the value he wants.
This is not a real use case.
I have checked with Anthony, there is no property recognized by the concurrent resources yet.

Comment by Anissa Lam [ 11/Apr/13 ]

This is a general UI issue, not 508 related. I have removed the 508 tag.





[GLASSFISH-20202] compilation warning about authorization from web cli Created: 05/Apr/13  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I notice the following while complying the web/admin and web-gui-plugin-common.

[WARNING] Following command classes neither provide nor inherit authorization: [org.glassfish.web.admin.cli.CreateHttp, org.glassfish.web.admin.cli.CreateHttpListener, org.glassfish.web.admin.cli.CreateHttpRedirect, org.glassfish.web.admin.cli.CreateNetworkListener, org.glassfish.web.admin.cli.CreateProtocol, org.glassfish.web.admin.cli.CreateProtocolFilter, org.glassfish.web.admin.cli.CreateProtocolFinder, org.glassfish.web.admin.cli.CreateTransport, org.glassfish.web.admin.cli.CreateVirtualServer, org.glassfish.web.admin.cli.DeleteHttp, org.glassfish.web.admin.cli.DeleteHttpListener, org.glassfish.web.admin.cli.DeleteHttpRedirect, org.glassfish.web.admin.cli.DeleteNetworkListener, org.glassfish.web.admin.cli.DeleteProtocol, org.glassfish.web.admin.cli.DeleteProtocolFilter, org.glassfish.web.admin.cli.DeleteProtocolFinder, org.glassfish.web.admin.cli.DeleteTransport, org.glassfish.web.admin.cli.DeleteVirtualServer, org.glassfish.web.admin.cli.ListHttpListeners, org.glassfish.web.admin.cli.ListNetworkListeners, org.glassfish.web.admin.cli.ListProtocolFilters, org.glassfish.web.admin.cli.ListProtocolFinders, org.glassfish.web.admin.cli.ListProtocols, org.glassfish.web.admin.cli.ListTransports, org.glassfish.web.admin.cli.ListVirtualServers]

[WARNING] Following command classes neither provide nor inherit authorization: [org.glassfish.web.plugin.common.ListWebContextParamCommand, org.glassfish.web.plugin.common.ListWebEnvEntryCommand, org.glassfish.web.plugin.common.SetWebContextParamCommand, org.glassfish.web.plugin.common.SetWebEnvEntryCommand, org.glassfish.web.plugin.common.UnsetWebContextParamCommand, org.glassfish.web.plugin.common.UnsetWebEnvEntryCommand]

Per discussion with Tom, this is related to role based access control feature.






[GLASSFISH-20182] configure-ldap-for-admin command should allow the full set of LDAP configuration, not just basedn and ldap-group Created: 04/Apr/13  Updated: 19/Sep/14

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

Type: Improvement Priority: Minor
Reporter: Tim Quinn Assignee: JeffTancill
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-19525 Enabling secure admin fails if admin ... Resolved

 Description   

(inspired by a comment from javashawn on GLASSFISH-19525)

[W]hen we originally began working with setting up GF admin realm to use LDAP we were trying to understand why the configure-ldap-for-admin subcommand only let you set the basedn and ldap-group attributes? This is what started us down the path of using a domain template that populated the other attributes (such as group-search-filter). It seems like the configure-ldap-for-admin command should allow for setting the same properties available for the LDAPRealm?






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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Refer to main task.



 Comments   
Comment by Mike Fitch [ 04/Apr/13 ]

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
Labels: None
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

 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 ]

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

Comment by Anissa Lam [ 29/Mar/13 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: Fishcat

 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 ]

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-20063] GUI cannot handle mulitbyte char in the login page Created: 26/Mar/13  Updated: 24/Apr/14

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

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

Tags: console

 Description   

I am able to create an admin user with multibyte char, eg 中文 through console or CLI.
In console u can create this user by:
Config -> server-config -> Security -> Realms -> admin-realm , manage User button, select and add user.

The admin-keyfile in domain1/config directory is updated correctly.

If i use CLI with this user name, and enter password, it works fine. so, it shows multibyte char is supported.
eg.
%asadmin --user 中文 create-jdbc-resources --connectionpoolid DerbyPool myJDBC

But i cannot login to console using this user name.
Also, I cannot delete this user when i go to
Config -> server-config -> Security -> Realms -> admin-realm , manage User button, select and delete it.



 Comments   
Comment by Jason Lee [ 26/Mar/13 ]

The Console login screen POSTs to j_security_check for the credential validation and does no actual user/pass handling at this point in the user experience. This seems to be an issue in the security layer, so I'm reassigning to that team for evaluation.





[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: devx_web

 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 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish Server Open Source Edition 4.0 (build 80)


Tags: fishcat

 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 ]

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 ]

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 ]

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 ]

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 ]

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 ]

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
Labels: None
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

 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 ]

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 ]

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 ]

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 ]

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
Labels: None
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

 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 ]

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

Comment by RameshT [ 08/Apr/13 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHL6.2 and JDK1.7.0_10



 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 ]

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 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

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



 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 ]

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 ]

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 ]

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 ]

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

Thanks

Comment by Daniel [ 03/Jul/13 ]

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 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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
Labels: None
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-19798 usage of internal proprietary API in ... Open
depends on GLASSFISH-19799 usage of internal proprietary API in... Open
depends on GLASSFISH-19801 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-19804 usage of internal proprietary API in... Open
depends on GLASSFISH-19805 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-19811 usage of internal proprietary API in... Open
depends on GLASSFISH-19808 usage of internal proprietary API in... Resolved
depends on GLASSFISH-19810 usage of internal proprietary API in... Resolved
Related
is related to GLASSFISH-2888 Try to use standard JDK classes only Resolved
Tags: build, maven, proprietary-api, warning

 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 ]

linking separate issues

Comment by Tim Quinn [ 13/Feb/14 ]

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
Labels: None
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, common-util, maven, proprietary-api, warning

 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 ]

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 ]

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
Labels: None
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, maven, proprietary-api, security, warning

 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
Labels: None
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, common, maven, proprietary-api, warning

 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 ]

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 ]

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
Labels: None
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, maven, proprietary-api, security, warning

 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
Labels: None
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, cmp, maven, proprietary-api, warning

 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
Labels: None
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, maven, orb, proprietary-api, warning

 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
Labels: None
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, ejb, maven, proprietary-api, security, warning

 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
Labels: None
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, maven, proprietary-api, verifier, warning

 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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: build, maven, proprietary-api, security, warning

 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
Labels: None
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, build, proprietary-api, security, warning

 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 ]

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
Labels: None
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, proprietary-api, security, warning

 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 ]

change fix version





[GLASSFISH-19790] configure-ldap-for-admin should be investigated such that the default security service configuration is updated when switching admin realm to LDAP. Created: 07/Mar/13  Updated: 19/Sep/14

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

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


 Description   

configure-ldap-for-admin should be investigated such that the default security service configuration is updated when switching admin realm to LDAP.






[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: maven, schemas

 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-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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: future-release, osgi-cdi, osgi-javaee

 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 ]

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 ]

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 ]

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 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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-19735] [PERF] Page to page navigation has slowed down and showing the long process popup Created: 27/Feb/13  Updated: 11/Sep/14

Status: In Progress
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b77
Fix Version/s: future release

Type: Task Priority: Critical
Reporter: Anissa Lam Assignee: Jason Lee
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: devx_web

 Description   

I notice that starting about a week or 2 ago, the admin console page to page navigation has slowed down significantly. Very often, the 'long process is detected' popup also shows up.
The doc team also reports the same observation.

There isn't a particular way to reproduce the issue. But if you use the console by clicking around, creating or deleting some objects, you will for sure notice the poor performance.
I see this on my Mac and the issue shows up in all 3 browsers (chrome, firefox and safari) , so don't think this is a browser issue.



 Comments   
Comment by Jason Lee [ 28/Feb/13 ]

I think this is a performance regression in Jersey. Here are some rough timings taken from revisions before and after the latest integration:

r59530
GET http://localhost:4848/common/appServer/serverInstGeneralPe.jsf?instanceName=server&bare=true 200 OK 1.1s
GET http://localhost:4848/cluster/standalone/standaloneInstances.jsf?bare=true 200 OK 240ms
GET http://localhost:4848/common/appServer/serverInstGeneralPe.jsf?instanceName=server&bare=true 200 OK 855m
GET http://localhost:4848/cluster/cluster/clusters.jsf?bare=true 200 OK 259m
GET http://localhost:4848/common/appServer/serverInstGeneralPe.jsf?instanceName=server&bare=true 200 OK 875m

r59545 <- This is the 2.0m12-1 integration
GET http://localhost:4848/common/appServer/serverInstGeneralPe.jsf?instanceName=server&bare=true 200 OK 2.28s
GET http://localhost:4848/cluster/standalone/standaloneInstances.jsf?bare=true 200 OK 1.72s
GET http://localhost:4848/common/appServer/serverInstGeneralPe.jsf?instanceName=server&bare=true 200 OK 2.61s
GET http://localhost:4848/cluster/cluster/clusters.jsf?bare=true 200 OK 1.04s
GET http://localhost:4848/common/appServer/serverInstGeneralPe.jsf?instanceName=server&bare=true 200 OK 2.11s

I'll email the Jersey team to get their take.

Comment by Jason Lee [ 05/Mar/13 ]

The numbers listed above were pretty rough, page-level timings; that is, how long it takes from the click of the mouse to the response from the server. I added some logging on the server side that measures ONLY the Jersey calls (i.e., target.request()). Prior to the integration, here are the timings we see for requests on a single page:

r59530:

***** GET request for http://localhost:4848/management/domain/servers/server/server finished in 31 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/uptime finished in 8 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/servers/server/server finished in 24 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/network-config/network-listeners/network-listener finished in 37 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/network-config/network-listeners/network-listener finished in 36 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/network-config/network-listeners/network-listener/admin-listener.json finished in 42 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/network-config/network-listeners/network-listener/http-listener-1.json finished in 53 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/network-config/network-listeners/network-listener/http-listener-2.json finished in 41 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/servers/server/server finished in 23 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/iiop-service/iiop-listener finished in 31 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/iiop-service/iiop-listener finished in 31 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/iiop-service/iiop-listener/SSL.json finished in 37 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/iiop-service/iiop-listener/SSL_MUTUALAUTH.json finished in 37 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/iiop-service/iiop-listener/orb-listener-1.json finished in 44 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/_get-restart-required finished in 7 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/anonymous-user-enabled finished in 10 milliseconds|#]

After the integration, this is what we see for the exact same page:

r59545:

***** GET request for http://localhost:4848/management/domain/servers/server/server finished in 82 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/uptime finished in 29 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/servers/server/server finished in 70 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/network-config/network-listeners/network-listener finished in 135 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/network-config/network-listeners/network-listener finished in 123 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/network-config/network-listeners/network-listener/admin-listener.json finished in 140 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/network-config/network-listeners/network-listener/http-listener-1.json finished in 181 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/network-config/network-listeners/network-listener/http-listener-2.json finished in 143 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/servers/server/server finished in 76 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/iiop-service/iiop-listener finished in 114 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/iiop-service/iiop-listener finished in 103 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/iiop-service/iiop-listener/SSL.json finished in 125 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/iiop-service/iiop-listener/SSL_MUTUALAUTH.json finished in 138 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/configs/config/server-config/iiop-service/iiop-listener/orb-listener-1.json finished in 185 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/_get-restart-required finished in 32 milliseconds|#]
***** GET request for http://localhost:4848/management/domain/anonymous-user-enabled finished in 44 milliseconds|#]

For reference, here are the lines of code in question:

long start = System.currentTimeMillis();
Response resp = target
    .request(RESPONSE_TYPE)
    .cookie(new Cookie(REST_TOKEN_COOKIE, getRestToken()))
    .get(Response.class);
GuiUtil.getLogger().log(Level.INFO, "\n\n***** GET request for {1} finished in {0} milliseconds", 
    new Object[] {
        (System.currentTimeMillis() - start), 
        address
    });

That's about as slimmed down, Jersey-only as you can get, and clearly after the integration, things get slower. If there are no objections, I will transfer this issue to the Jersey team (or perhaps file an issue on their tracker for this).

Comment by Jakub Podlesak [ 05/Mar/13 ]

I am not 100 % sure about the measurement method above, but the fact we do not have Jersey client side covered by performance tests is awful.
Please feel free to file a task in the Jersey JIRA to cover client side performance testing. Once implemented, we should be able to get some numbers also for previous Jersey releases and compare.

Comment by Jason Lee [ 05/Mar/13 ]

It is a pretty simple measure, but we get a pretty accurate timing, I think, on the processing time for the client request. At any rate, I have filed a task for the client-side performance testing coverage: http://java.net/jira/browse/JERSEY-1767

How quickly do you think this will be addressed? The performance in the console is raising eyebrows. Can we use the older version of the client in the meantime?

Comment by Jakub Podlesak [ 08/Mar/13 ]

To better understand where the regression is, it would be useful to have some numbers also with using a non Jersey client (e.g. curl) for the above tests.
Given that http://localhost:4848/management/domain application does not use Jersey client internally, of course.

Jason, would you have some cycles for it?

Comment by Anissa Lam [ 09/Apr/13 ]

I see that the performance has improved some after I filed this issue, although it still hasn't got back to the same level of performance like in 3.1.2.
There is lots of discussions regarding this, and i don't think Jason is planning to do anything specifically to address this issues in the console code.
I am changing this to Task and target that for the next release to see what console can do to improve the paga to page navigation.

One thing i notice is that, when refreshing the tree node, even though we called the ajax to just refresh a particular node, eg. Applications, the entire tree is refreshed, thus sending lots of requests to the backend to update the tree. We may want to look into why this is happening. But since its done asynchronously, the main page on the left isn't really waiting for the tree to completely refreshed before displaying the right side, thus not directly impacted by this whole tree update.

I am changing this to Task and target that for the next release to see what console can do to improve the paga to page navigation.





[GLASSFISH-19722] module-monitoring-levels should not include cloud related attributes Created: 23/Feb/13  Updated: 11/Sep/14

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

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

Tags: console

 Description   

Console's Monitoring Service page list out the attributes of module-monitoring-levels and allow user to set each one to be OFF/LOW/HIGH.
The attributes related to cloud such as cloud, cloud-account-manager, cloud-elasticity, cloud-orchestrator, shouldn't be included nor returned for GlassFish.

%~ 16) asadmin get configs.config.server-config.monitoring-service.module-monitoring-levels
configs.config.server-config.monitoring-service.module-monitoring-levels.cloud=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.cloud-account-manager=HIGH
configs.config.server-config.monitoring-service.module-monitoring-levels.cloud-elasticity=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.cloud-orchestrator=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.cloud-virt-assembly-service=HIGH
configs.config.server-config.monitoring-service.module-monitoring-levels.connector-connection-pool=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.connector-service=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.deployment=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.ejb-container=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.http-service=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.jdbc-connection-pool=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.jersey=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.jms-service=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.jpa=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.jvm=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.orb=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.security=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.thread-pool=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.transaction-service=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.web-container=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.web-services-container=OFF
Command get executed successfully.

cloud related attributes should be removed from GlassFish 4.0



 Comments   
Comment by Byron Nevins [ 24/Feb/13 ]

This was done by Suma and Srini last May

Ref:
com.sun.enterprise.config.serverbeans.ModuleMonitoringLevels

Comment by Anissa Lam [ 08/Mar/13 ]

Change the fix version to b82, MS7.
MS7 is the HCF day, 3/25.

Comment by srinik76 [ 21/Mar/13 ]

There is already a HK2 RFE raised to address this issue. (http://java.net/jira/browse/HK2-23)
Also there is a wiki page which lists outs the information this issue.

http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Nucleus+Cleanup+-+Monitoring

To fix the current issue we need to fix the above blocking issue.

Comments from Nazrul...

We should take this to a CCC meeting if we are unable to fix the HK2 RFE.

Chris/Masoud: We should explore why we are not able to fix HK2 RFE. Please schedule a meeting with HK2 team first (John Wells, Mahesh, Larry F, Tom Snyder).
After that, depending on the result, please schedule a CCC meeting and include Bill, Paul Davies, Sudipa and folks we need from Dev (Tom, Mahesh, John Wells).

Thanks.

Comment by Anissa Lam [ 02/Apr/13 ]

I have added a filter in the GUI code to filter out any modules that starts with "cloud".
Log Message:
------------
work around for GLASSFISH-19722. hide cloud modules for monitoring level screen.

Revisions:
----------
61083

Modified Paths:
---------------
trunk/main/appserver/admingui/common/src/main/java/org/glassfish/admingui/common/handlers/MonitoringHandlers.java

When this bug is fixed, the workaround should be removed as it is not needed.

Comment by Anissa Lam [ 08/Apr/13 ]

Since i have put in the workaround for the console by filtering out the cloud* container name, the actual fix of this bug can be deferred to after 4.0.
I am changing the target to 4.1.

Comment by Anissa Lam [ 26/Apr/13 ]

I saw that Srini added "4_0-release-notes" to the tag.
Do we really need to release note this, how does the release note help our users ?
With the work around, user will not see the cloud related monitoring level in the console, they will only see it exists by using CLI get and then set it.
Setting it doesn't give any error and user will not notice any problem as they won't see cloud related monitoring anyway.

I feel that adding this to the release note is just going to prevent user to easily see issues that they should be aware of.

Comment by srinik76 [ 29/Apr/13 ]

As per anissa's comment i am removing the tag on 4_0_release_notes





[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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 ]

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-19686] Java EE security classes are part of nucleus Created: 18/Feb/13  Updated: 24/Apr/14

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

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


 Description   

Classes like J2EESecurityManager JavaEESecurityLifecycle are part of nucleus when they should not be.






[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
Labels: None
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

 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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7 Pro 64 Bit
8.3 support is disabled



 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 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Tags: asadmin

 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 ]

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 ]

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 ]

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 ]

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 ]

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 ]

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 ]

> 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
Labels: None
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

 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 ]

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 ]

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
Labels: None
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

 Description   

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






[GLASSFISH-19568] Regression: WebComponentInvocation cannot be cast to EjbInvocation from deploying an ear without web component Created: 22/Jan/13  Updated: 24/Apr/14

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

Type: Bug Priority: Critical
Reporter: marina vatkina Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The failing ejb devtest is /txprop/simple with the exception from the security module, so starting with the security component (please reassign as you see it fit):

[exec] java.lang.ClassCastException: com.sun.enterprise.web.WebComponentInvocation cannot be cast to com.sun.ejb.EjbInvocation
[exec] at org.glassfish.ejb.security.application.EjbSecurityComponentInvocationHandler$1.afterPostInvoke(EjbSecurityComponentInvocationHandler.java:101)
[exec] at org.glassfish.api.invocation.InvocationManagerImpl.postInvoke(InvocationManagerImpl.java:254)
[exec] at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1983)
[exec] at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1961)
[exec] at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:212)
[exec] at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:123)
[exec] at $Proxy280.callHello(Unknown Source)

There are other errors in the run, but this error started happening between the builds that were used for the 4am and 10am test runs on Jan 18th. This is a very old EJB test with no recent modifications.



 Comments   
Comment by marina vatkina [ 22/Jan/13 ]

You can use http://hudson-sca.us.oracle.com/job/ejb-devtests-trunk-single-test/ to setup to run a single ejb devtest.





[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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
Labels: None
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, hibernate, severe

 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 ]

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

Comment by esejfi [ 18/Jan/13 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

Assigning to Sahoo...

Comment by mkeith [ 17/Jan/13 ]

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 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: asadmin, create-jvm-options, delete-jvm-options, list-jvm-options

 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 ]

What, you didn't like my description?





[GLASSFISH-19437] Open-source Az* implementations are incomplete - cannot get resource/action name Created: 13/Dec/12  Updated: 24/Apr/14

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

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


 Description   

The open-source implementations of the AzResource and AzAction interfaces simply extend AttributesImpl and thus provide no way to obtain the resource name or action name from the respective classes.

In fact, the interfaces themselves lack such methods.






[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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





[GLASSFISH-19349] Choosing SSL cipher suites in GlassFish admin GUI results in many "Unrecognized cipher" warnings in GlassFish log Created: 15/Nov/12  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: rdelaplante Assignee: JeffTancill
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Using the web admin GUI I went into the configuration of http-listener-2 which has SSL enabled. I went to the SSL tab and clicked the "select all" button for all cipher suites EXCEPT the 40 bit and 56 bit ciphers, and then pressed save. My goal is to disable the 40 bit and 56 bit ciphers. I noticed the following in my GlassFish log. Note that I already have the unlimited strength JCE installed in my JDK:

INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: Grizzly Framework 1.9.50 started in: 1ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDHE_RSA_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDH_ECDSA_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDH_anon_WITH_RC4_128_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDH_anon_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDHE_ECDSA_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDH_RSA_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDH_anon_WITH_AES_128_CBC_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDHE_RSA_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDHE_ECDSA_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDHE_RSA_WITH_NULL_SHA].

Why did it offer cipher suites that are unrecognized in the first place? Which ones were actually used?






[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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 ]

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 ]

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

Comment by Hong Zhang [ 05/Mar/13 ]

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
Labels: None
Remaining Estimate: 5 weeks
Time Spent: Not Specified
Original Estimate: 5 weeks


 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 ]

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
Labels: None
Remaining Estimate: 6 weeks
Time Spent: Not Specified
Original Estimate: 6 weeks

Tags: ee7platspec

 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
Labels: None
Remaining Estimate: 3 weeks
Time Spent: Not Specified
Original Estimate: 3 weeks


 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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-11941 Improve CORBA testing Resolved

 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-19138] Unable to configure/bind acustom ldap context with user credentials Created: 09/Oct/12  Updated: 24/Apr/14

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

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

GlassFish V3 / V2



 Description   

I am not absolutly sure but I think there is a configuration problem with custom resources for ldap directories.
The problem is, that when a custom ldap resoruce is configurerd in GlassFish together with additional properties for the user
pricipal and user credentials, these information seems to be ignored during binding the ldap context.
So when external ldap server requires an authenticated user to search for objects, the context object can not be used.
The following exception is throwns (for MS Active Directory)

 
javax.naming.NamingException: [LDAP: error code 1 - 00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece ]; remaining name 'DC=xxxxx,DC=local'

I am creating the context object with the following code:

 
Context initCtx = new InitialContext();
ldapCtx = (LdapContext) initCtx.lookup("my.jndi.ldap-Custom-Resource");

The situation is the same on GlassFish V2 as also on GlassFish V3 (3.1.1).

When the LdapContext is setup programmatically with the same information like configured in the custom resource configuration the connection works.

To reproduce the problem:
1. create a custom ldap resoruce to an ldap server which did not allow any anonymous access.
2. lookup the resoucre from a ejb
3. try to search a object in the ldap directory
4. search fails with insufficient permission (from the external ldap server)

I have also posted this issue into the form:
http://www.java.net/forum/topic/glassfish/glassfish/unable-bind-ldap-context-custom-ressource



 Comments   
Comment by rsoika [ 12/Oct/12 ]

I think I made a fault during the setup of my resource.
When I configure an external jndi resource (instead of an custom jndi resource) everything works fine.

Maybe the other fault was that I choose 'javax.naming.directory.Directory' as the resource type.
I think 'javax.naming.ldap.LdapContext' is the right resource type to bind the ldap directory. (but javax.naming.directory.Directory works if you can bind Anonymous user)

So maybe you can close this issue?
The only thing what is really missing is a clear documentation about how to bind a ldap server into GlassFish as a jndi resource.
The best what I have found so fare was this blog:

http://javaevangelist.blogspot.de/2007/03/sun-java-system-application-server-9x_15.html

Comment by rsoika [ 19/Mar/13 ]

In the meantime I continued using my external jndi ldap resource for for my applications.
But another problem I recognized was, that the ldap resource becomes stale after some time.
I had this situation with a MS AD. First everything looks fine. But after some time (>10 minutes) the ldap server closes the 'pooled' connection. This is not recognized by the existing external jndi resource. So when you try to reuse it (simply another method call in my EJB) an exception is thrown that the connection was closed and can not be used for lookups (exception comes from the ldap server).
So at the end I came to the only solution that the jndi ldap resource can not be used.
My stateless EJB is not creating the ldap connection manually for each ldap lookup and closes the connection after the lookup.
I think you can verify this behaviour.

After I read more about java LDAP connections I understand that there is no way to verify if a connection is still valid. So there seems no way to pool ldap connections ...?
For my understanding the only way for GlassFish to pool such external jndi ldap resources would be to create a new connection each time the resource is requested from a client. But how should GlassFish be able to decide if the connection can be closed....?

Can you confirm this?





[GLASSFISH-19113] [PERF] Forwarded JSP makes multiple calls to InvocationManagerImpl Created: 28/Sep/12  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: Scott Oaks Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: PSRBUG

 Description   

When a simple servlet forwards a response to a JSP, there are multiple calls made to InvocationManagerImpl.preInvoke and postInvoke.

In the case of preInvoke, the first of these calls comes from ApplicationDispatcher.invoke -> ApplicationDispatcher.doInvoke -> InstanceSupport.fireInstanceEvent -> J2EEInstanceListener.instanceEvent. In that case the instance event is the InstanceEvent.EventType.BEFORE_DISPATCH_EVENT (line 792 of ApplicationDispatcher). The second call comes from line 821, which calls StandardWrapper.service -> InstanceSupport.fireInstanceEvent. In that case the instance event is InstanceEvent.EventType.BEFORE_SERVICE_EVENT. So within J2EEInstanceListener, the events are different. But that information isn't passed into the InvocationManagerImpl.preInvoke method, which appears just to be doing duplicate work. Unless the event is somehow passed to the lower methods in a way I'm just missing.

Can we figure out a way to eliminate the duplicate processing?

This is doubtless a long-standing issue that we've just discovered, in part because of a large regression in the performance of InvocationManagerImpl.preInvoke and postInvoke. But even if we fix the invocation manager performance, we should eliminate this duplicate call.






[GLASSFISH-19102] Creating (misscofigured) jdbcRealm disables usage of other secure Realm Created: 24/Sep/12  Updated: 24/Apr/14

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

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

Red Hat (server machine)
Ubuntu


Tags: admin-gui, fileRealm, jdbcRealm

 Description   

How to recreate:
-Create application to protect with BASIC authentication
-define new user in "file" Realm
-configure application to use "file" Realm
(now you can use successfully file realm)
-create new jdbcRealm (probably with wrong configuration)
-restart Glassfish (via admin-gui, not asadmin which was not tested)!!

now I can't use neither jdbcRealm (if it is properly configured and I believe it is) nor file realm any more

if I dispose jdbcRealm I still can't use file realm, I need to reconfigure domain from scratches

I constantly receive

[#|2012-09-24T15:12:47.251+0200|FINEST|glassfish3.1.2|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.login|_ThreadID=70;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.login.LoginContextDriver;MethodName=doPasswordLogin;|doPasswordLogin fails
javax.security.auth.login.LoginException: No LoginModules configured for fileRealm
at javax.security.auth.login.LoginContext.init(LoginContext.java:273)
at javax.security.auth.login.LoginContext.<init>(LoginContext.java:382)
at javax.security.auth.login.LoginContext.<init>(LoginContext.java:459)
at com.sun.enterprise.security.auth.login.LoginContextDriver.doPasswordLogin(LoginContextDriver.java:381)
at com.sun.enterprise.security.auth.login.LoginContextDriver.login(LoginContextDriver.java:240)
at com.sun.enterprise.security.auth.login.LoginContextDriver.login(LoginContextDriver.java:153)
at org.glassfish.admin.rest.cli.SecurityUtil.getAnonymousUser(SecurityUtil.java:343)
at org.glassfish.admin.rest.cli.IsAnonymousUserEnabledCommand.execute(IsAnonymousUserEnabledCommand.java:73)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:214)
at org.glassfish.admin.rest.resources.TemplateExecCommand.executeCommand(TemplateExecCommand.java:127)
at org.glassfish.admin.rest.resources.TemplateCommandGetResource.processGet(TemplateCommandGetResource.java:78)
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.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer._service(GrizzlyContainer.java:182)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer.service(GrizzlyContainer.java:147)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:148)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
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:722)

#]

or similar with jdbcRealm






[GLASSFISH-19064] Glassfish unreasonably denies access to JSF page with HTTP 403, restarting the domain fixes the problem Created: 07/Sep/12  Updated: 24/Apr/14

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

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

Tested on Ubuntu 12.04 x86 and Debian 6 x64.



 Description   

I've got an @Startup EJB (named EJB1) which connects to an HBase database using a library in its @PostConstruct method. The library itself takes advantage of HBase's Java API. This EJB is injected into another EJB (named EJB2) of which its local interface (EJB2Local) is injected into web-module beans, including an EJB which creates a web service and a managed bean which is tied to the index.xhtml JSF page.

This is how I reproduce and fix the problem:
1. Create and start a clean Glassfish domain.
2. Deploy the ear archive.
3. Glassfish denies access to index.xhtml with an HTTP 403 error. Other parts of the application, including the web services inside the web module, work flawlessly. The following lines get inserted into server.log upon each request for index.xhtml. Starting the domain in --verbose mode does not produce more messages at this point.

INFO: JACC Policy Provider:Failed Permission Check: context (" App/App-war_war ") , permission (" ("javax.security.jacc.WebUserDataPermission" "" "GET") ")
INFO: JACC Policy Provider:Failed Permission Check: context (" App/App-war_war ") , permission (" ("javax.security.jacc.WebUserDataPermission" "" "GET:CONFIDENTIAL") ")
INFO: JACC Policy Provider:Failed Permission Check: context (" App/App-war_war ") , permission (" ("javax.security.jacc.WebUserDataPermission" "/favicon.ico" "GET") ")
INFO: JACC Policy Provider:Failed Permission Check: context (" App/App-war_war ") , permission (" ("javax.security.jacc.WebUserDataPermission" "/favicon.ico" "GET:CONFIDENTIAL") ")

4. Without undeploying the application, restart the domain and let the pre-deployed application start automatically.
5. index.xhtml loads without problems.
6. Undeploying/deploying the ear file does not reproduce the problem. To see the 403 error again, one has to create a new domain.



 Comments   
Comment by shreedhar_ganapathy [ 13/Dec/12 ]

-> Hong - please eval this and if it belongs elsewhere, please reassign.

Comment by Hong Zhang [ 13/Dec/12 ]

A reproducible use case will help us to understand the problem better.

Assign to web team to take initial look to see if the permission file needs to be fixed somehow for this use case, and reassign to appropriate category (security?) as needed.

Comment by Shing Wai Chan [ 13/Dec/12 ]

403 means there is no permission is granted for a given page.
Please provide an app to illustrate this issue.

Comment by Shing Wai Chan [ 17/Jan/13 ]

Change to security component.

Comment by james.falkner [ 15/Aug/13 ]

We are also seeing this with recent builds of Liferay on JDK 6 and 7.

[#|2013-08-15T21:09:50.938+0000|INFO|glassfish3.1.2|javax.enterprise.system.core.security|_ThreadID=238;_ThreadName=http-thread-pool-8080(5);|JACC Policy Provider:Failed Permission Check: context (" liferay-portal/liferay-portal ") , permission (" ("javax.security.jacc.WebUserDataPermission" "" "GET") ") |#]

[#|2013-08-15T21:09:50.938+0000|INFO|glassfish3.1.2|javax.enterprise.system.core.security|_ThreadID=238;_ThreadName=http-thread-pool-8080(5);|JACC Policy Provider:Failed Permission Check: context (" liferay-portal/liferay-portal ") , permission (" ("javax.security.jacc.WebUserDataPermission" "" "GET:CONFIDENTIAL") ") |#]




[GLASSFISH-18996] More than maximum number of characters can be entered for create-file-user Created: 13/Aug/12  Updated: 24/Apr/14

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

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

Windows 7



 Description   

More than maximum number of characters can be entered in the UserID, Group List and Password for create-file-user on command or Admin console.

1.Open admin GUI. http://localhost:4848
2.Configurations > server-config > Security > Realms > file
3.Click Manage Users button.
4.In File Users, click New button.
5.Enter more than 255 characters in User ID, Group List and Password.
The description says "Name can be up to 255 characters, must contain only alphanumeric, underscore, dash, or dot characters."
6.Click OK button.
7.Check the new user. The user name is more than 255 characters.

Similarly, more than the maximum number of characters 255 can be entered for these parameters when create-file-user command is used.
1. asadmin> create-file-user
2. Enter the value for the username operand> Enter more than 255 characters
3. Enter the user password> Enter more than 255 characters
4. Check the new user.



 Comments   
Comment by tak09 [ 04/Jul/13 ]

maximum length for the group also needs checking.





[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Solaris 11 and JDK1.6.0_30


Attachments: Zip Archive test.zip     Zip Archive test4.zip    

 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 ]

[1] Test Spec
16 Failover of session with form-based authentication and authorization for Stateless Session Bean