[GLASSFISH-20566] Deployment of a EJB fails with CDI if the bean is described by a descriptor instead of an annotation Created: 21/May/13  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b89_RC5
Fix Version/s: 4.1

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

Linux


Attachments: File JCDIServiceBugEar.ear    

 Description   

A NP is thrown in in org.glassfish.weld.services.JCDIServiceImpl#_createJCDIInjectionContext(EjbDescriptor ejb, T instance), when a bean is being described by a deployment descriptor in the corresponding jar instead of using annotations :

[glassfish 4.0] [SEVERE] [ejb.stateless_ejbcreate_exception]
[javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=135 _ThreadName=admin-listener(11)]
[timeMillis: ...] [levelValue: 1000] [[EJB5070: Exception creating stateless session bean : [MyTimerBean]]]

[glassfish 4.0] [WARNING] [ejb.system_exception] [javax.enterprise.system.container.ejb.com.sun.ejb.containers]
[tid: _ThreadID=135 _ThreadName=admin-listener(11)] [timeMillis: ...] [levelValue: 900]
[[ EJB5184:A system exception occurred during an invocation on EJB MyTimerBean,
method: public void MyTimerBean.cancelAllTimers()]]

[glassfish 4.0] [WARNING] [] [javax.enterprise.system.container.ejb.com.sun.ejb.containers]
[tid: _ThreadID=135 _ThreadName=admin-listener(11)] [timeMillis: ...] [levelValue: 900] [[

javax.ejb.EJBException: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:435)
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.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:123)
at com.sun.proxy.$Proxy266.cancelAllTimers(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.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:239)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:150)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:226)
at MyTimer_DynamicStub.cancelAllTimers(_MyTimer_DynamicStub.java)
...
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.ejb.containers.interceptors.BeanCallbackInterceptor.intercept(InterceptorManager.java:1035)
at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55)
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.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:986)
at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.init(SystemInterceptorProxy.java:125)
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.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:986)
at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.init(SystemInterceptorProxy.java:125)
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.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:986)
at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:412)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:375)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:1949)
at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:475)
at com.sun.ejb.containers.AbstractSingletonContainer.access$000(AbstractSingletonContainer.java:81)
at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:654)
at com.sun.ejb.containers.AbstractSingletonContainer.instantiateSingletonInstance(AbstractSingletonContainer.java:396)
at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:219)
at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:180)
at org.glassfish.ejb.startup.SingletonLifeCycleManager.doStartup(SingletonLifeCycleManager.java:158)
at org.glassfish.ejb.startup.EjbApplication.start(EjbApplication.java:166)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.InstanceDeployCommand.execute(InstanceDeployCommand.java:213)
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.execCommandMultInMultOut(CommandResource.java:256)
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:224)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:331)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:165)
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.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:722)
Caused by: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:700)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:246)
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:430)
... 124 more
Caused by: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:514)
at com.sun.ejb.containers.StatelessSessionContainer.access$000(StatelessSessionContainer.java:97)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:698)
... 126 more
Caused by: java.lang.reflect.InvocationTargetException
at com.sun.ejb.containers.BaseContainer.createEjbInstanceAndContext(BaseContainer.java:1641)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:456)
... 128 more
Caused by: java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.hash(ConcurrentHashMap.java:333)
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:988)
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:1163)
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:178)
at org.glassfish.weld.services.JCDIServiceImpl._createJCDIInjectionContext(JCDIServiceImpl.java:198)
at org.glassfish.weld.services.JCDIServiceImpl.createJCDIInjectionContext(JCDIServiceImpl.java:179)
at com.sun.ejb.containers.BaseContainer.createEjbInstanceAndContext(BaseContainer.java:1631)
... 129 more
]]

RootCause :

org.glassfish.weld.services.JCDIServiceImpl#_createJCDIInjectionContext(EjbDescriptor ejb, T instance)

org.jboss.weld.ejb.spi.EjbDescriptor ejbDesc = weldManager.getEjbDescriptor(ejb.getName());
// Get an the Bean object
Bean<?> bean = weldManager.getBean(ejbDesc);

It sounds like the second experience under https://java.net/jira/browse/GLASSFISH-15888 .
The bda only shows up beans, that are being described by annotations. It seems that the deployment descriptors are ignored.



 Comments   
Comment by jjsnyder83 [ 22/May/13 ]

Please attach the application with source code.

Comment by jjsnyder83 [ 31/May/13 ]

The reason it is failing is because the ejb classes are not in the ejb jar but are in another jar in the application's classpath. I checked with Marina and she said that the way your application is packaged is valid but the GF CDI code is written such that it expects the ejbs to be in the same jar as the ejb descriptor. I will have to think about how to fix this.

In the mean time because this is not a cdi application you can issue the following asadmin command to disable cdi and your application will deploy without any exceptions:

$GFHOME/bin/asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false

Comment by phil.zampino [ 18/Jun/13 ]

Removed unnecessary restriction that EJB classes be packaged in the EJB JAR in which the corresponding descriptor is packaged. Now, EJB classes packaged outside the JAR containing their descriptor will be correctly loaded.

Committed revision 62240.

Comment by phil.zampino [ 12/Aug/13 ]

The previous fix breaks the CDI TCK. So, this issue needs to be revisited.





[GLASSFISH-17151] EJB remote deployed on GF 3.1 behind a NAT unaccessible via a simple Java app Created: 05/Aug/11  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: orb
Affects Version/s: 3.1
Fix Version/s: 4.1

Type: Bug Priority: Blocker
Reporter: Blaise Gosselin Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS Linux Debian 6
JDK 1.6.0.26


Issue Links:
Related
is related to GLASSFISH-17147 App client cannot find EJB behind NAT Open
Tags: 3_1_2-exclude, 3_1_2-release-note-added, 3_1_2-release-notes, orb-review

 Description   

I have 2 Glassfish servers version 3.1: a FRONT server and a BACK server.
The FRONT server is in a DMZ.
The BACK server is in on a private lan, not accessible directly from the DMZ, but through a firewall that does a NAT on the IP of the BACK server.
-> IP-PU-B = Public IP address of the BACK
-> IP-PR-B = Private IP address of the BACK

Thus, the FRONT server only knows the public IP of the BACK server (the "NATed" IP). The Glassfish on the BACK server knows only its own "private" IP address, not its NATed address (it is only valid for machines on the DMZ).

Here is my client code:
try {
InitialContext context = new InitialContext();
System.out.println("Context initialized!");
HelloService service = (HelloService) context.lookup("HelloEJB");
System.out.println("Service retrieved!");
String name = service.countryCount();
System.out.println("Hello " + name);
} catch (Exception e) {
e.printStackTrace();
}

And here is my jndi.properties content in my client app:
java.naming.factory.initial = com.sun.enterprise.naming.SerialInitContextFactory
java.naming.factory.url.pkgs = com.sun.enterprise.naming
java.naming.factory.state = com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl
org.omg.CORBA.ORBInitialHost = IP-PU-B
org.omg.CORBA.ORBInitialPort = 3700

This code doesn't work if I launch my application from the DMZ trying to access the EJB remote via the IP address IP-PU-B.
This code works if I launch the application from "inside the network" trying to access the EJB remote via the IP address IP-PR-B.

The problem is due to the IIOP protocol as implemented on the Glassfish server. It does a first call on the ORB to locate the EJB (which is deployed on the same server as the ORB). Thus, the ORB sends the private IP to the client, instead of the public IP (which it has no way of knowing, as it is determined by the firewall)... The client then tries to connect on the private IP, which does not go though the firewall.

We have already tried the following solutions:

  • Connecting to a Remote EJB Module Through a Firewall
    Link: http://download.oracle.com/docs/cd/E19226-01/820-7695/6niugesud/index.html
    We have put the IP-PU-B as value for the variable "com.sun.corba.ee.ORBVAAHost".
    In that case, the problem between the FRONT and the BACK still exists, and moreover there is also a problem when I try to access the EJB remote from the Java application run on the BACK to the EJB remote on the BACK.
  • Replace Network address of the orb-listener-1, no better result.
  • Use of variable "java.rmi.server.hostname", no better result.

Is there a specific way to configure Glassfish behind a NAT to make it send the public IP instead of the private one?

Thanks in advance for your help!



 Comments   
Comment by Blaise Gosselin [ 09/Aug/11 ]

Important info: I just tested with the version 3.0.1, and it works correctly when I change the "Network address" of the "orb-listener-1".

It must then be a regression...

Comment by Nicolasdew [ 14/Sep/11 ]

Hello everyone,

we are experiencing the same problem using glassfish 3.1.1
The weirdest thing when setting the parameter com.sun.corba.ee.ORBVAAHost = "our_public_address" is that sometimes i can see that this address is taken into account and sometimes not.
I can see that by analyzing the GIOP packet on wireshark.
Is it confirmed that it is a regression or a misuse ?
Thank you for your reply.

Comment by Blaise Gosselin [ 22/Sep/11 ]

Hi,

Is it possible to have an answer to this problem please?

We are currently facing CDI problems with version 3.0.1, while it is the only one that works through a firewall => WE ARE STUCK for the moment, and we will probably have to use another AS (such as JBoss) if one solution is not proposed/found to our issues! At least maybe you could indicate us the class/lib to change in the GF 3.1 to make it work through a firewall as expected!

Thanks in advance for your help!

KR,

Comment by Blaise Gosselin [ 27/Sep/11 ]

Good news: we have solved this issue by our-self!

A colleague of mine has investigated in the Glassfish source, and here is the result.

Modifications in org.glassfish.enterprise.iiop.impl.GlassFishORBManager:

  1. Change method getClearTextIiopListener to test the “security-enabled” attribute of the iiop-listener (our clear text listener had an SSL element, probably set by the administration console…).
GlassFishORBManager.java
    private IiopListener getClearTextIiopListener() {
        if (iiopListeners != null)  {
            for (IiopListener il : iiopListeners) {
                if (!"true".equals(il.getSecurityEnabled())) {
                    return il ;
                }
            }
        }
		
        return null ;
    }
  1. Change the checkForAddrAny method to set the ORBConstants.SERVER_HOST_PROPERTY property to orbInitialHost. This allows us to send the hostname to the front server, and not the un-NATed IP. This is the same behavior as in Glassfish 3.0, and is needed in our case (natted network between the EJB server and the client).
GlassFishORBManager.java
    private String checkForAddrAny(Properties props, String orbInitialHost) {
        if ((orbInitialHost.equals("0.0.0.0")) || (orbInitialHost.equals("::"))
                || (orbInitialHost.equals("::ffff:0.0.0.0"))) {
            try {
                String localAddress = java.net.InetAddress.getLocalHost().getHostAddress();
                return localAddress;
            } catch (java.net.UnknownHostException uhe) {
                logger.log(Level.WARNING,
                    "Unknown host exception - Setting host to localhost");
				
                return DEFAULT_ORB_INIT_HOST;
            }
        } else {
            props.setProperty(ORBConstants.SERVER_HOST_PROPERTY, orbInitialHost);
            return orbInitialHost;
        }
    }

That's it!

Comment by Harshad Vilekar [ 15/Oct/11 ]

The fix is putback to 3.1.2 workspace. Blaise, could you please confirm if the issue is resolved in (tonight's or later) 3.1.2 build ?

First change was not required - getSsl() correctly returns null for ClearTextIiopListener. Please check you admin settings if there is issue.

Comment by Harshad Vilekar [ 16/Nov/11 ]

The fix is verified by the reporter.

Comment by Harshad Vilekar [ 16/Dec/11 ]

Although the fix works with NAT, it has a side effect - resulting in regression (GLASSFISH-17689). Fix is reverted.

Comment by mone_java [ 24/Jan/12 ]

I have the same problem.... I tried with glassfish 3.1.2-b19-01_23_2012....

this is what my client sends to the server (wireshark):

0000 00 13 49 e2 a3 e9 f4 6d 04 16 75 5e 08 00 45 00 ..I....m ..u^..E.
0010 01 60 ad b9 40 00 40 06 6b 86 c0 a8 01 23 4f 0e .`..@.@. k....#O.
0020 0f 7f c3 9e 0e 75 34 13 d6 8c 7e 5c 1a d8 80 18 .....u4. ..~\....
0030 00 5c 21 ab 00 00 01 01 08 0a 00 37 7b 6c 00 23 .!..... ...7{l.#
0040 e1 d3 47 49 4f 50 01 02 00 00 00 00 01 20 00 00 ..GIOP.. ..... ..
0050 00 05 03 00 00 00 00 00 00 00 00 00 00 0b 4e 61 ........ ......Na
0060 6d 65 53 65 72 76 69 63 65 00 00 00 00 06 5f 69 meServic e....._i
0070 73 5f 61 00 00 00 00 00 00 03 00 00 00 11 00 00 s_a..... ........
0080 00 02 00 02 00 00 4e 45 4f 00 00 00 00 02 00 14 ......NE O.......
0090 00 00 00 00 00 06 00 00 00 a6 00 00 00 00 00 00 ........ ........
00a0 00 28 49 44 4c 3a 6f 6d 67 2e 6f 72 67 2f 53 65 .(IDL:om g.org/Se
00b0 6e 64 69 6e 67 43 6f 6e 74 65 78 74 2f 43 6f 64 ndingCon text/Cod
00c0 65 42 61 73 65 3a 31 2e 30 00 00 00 00 01 00 00 eBase:1. 0.......
00d0 00 00 00 00 00 6a 00 01 02 00 00 00 00 0a 31 32 .....j.. ......12
00e0 37 2e 30 2e 31 2e 31 00 95 21 00 00 00 19 af ab 7.0.1.1. .!......
00f0 cb 00 00 00 00 02 00 00 00 65 00 00 00 08 00 00 ........ .e......
0100 00 00 00 00 00 00 14 00 00 00 00 00 00 02 00 00 ........ ........
0110 00 01 00 00 00 20 00 00 00 00 00 01 00 01 00 00 ..... .. ........
0120 00 02 05 01 00 01 00 01 00 20 00 01 01 09 00 00 ........ . ......
0130 00 01 00 01 01 00 00 00 00 26 00 00 00 02 00 02 ........ .&......
0140 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e 6f 72 .....(ID L:omg.or
0150 67 2f 43 6f 73 4e 61 6d 69 6e 67 2f 4e 61 6d 69 g/CosNam ing/Nami
0160 6e 67 43 6f 6e 74 65 78 74 3a 31 2e 30 00 ngContex t:1.0.

and this what my server sends to my client:

0000 f4 6d 04 16 75 5e 00 13 49 e2 a3 e9 08 00 45 00 .m..u^.. I.....E.
0010 02 72 fb 33 40 00 33 06 29 fa 4f 0e 0f 7f c0 a8 .r.3@.3. ).O.....
0020 01 23 0e 75 c3 9e 7e 5c 1a d8 34 13 d7 b8 80 18 .#.u..~\ ..4.....
0030 00 6c cf 72 00 00 01 01 08 0a 00 23 e2 05 00 37 .l.r.... ...#...7
0040 7b 6c 47 49 4f 50 01 02 00 01 00 00 02 32 00 00 {lGIOP.. .....2..
0050 00 05 00 00 00 03 00 00 00 02 4e 45 4f 00 00 00 ........ ..NEO...
0060 00 02 00 14 00 00 00 00 00 06 00 00 01 30 00 00 ........ .....0..
0070 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e 6f 72 .....(ID L:omg.or
0080 67 2f 53 65 6e 64 69 6e 67 43 6f 6e 74 65 78 74 g/Sendin gContext
0090 2f 43 6f 64 65 42 61 73 65 3a 31 2e 30 00 00 00 /CodeBas e:1.0...
00a0 00 01 00 00 00 00 00 00 00 f4 00 01 02 00 00 00 ........ ........
00b0 00 0e 31 39 32 2e 31 36 38 2e 31 2e 32 30 32 00 ..192.16 8.1.202.
00c0 0e 74 00 00 00 19 af ab cb 00 00 00 00 02 00 00 .t...... ........
00d0 00 64 00 00 00 08 00 00 00 00 00 00 00 00 14 00 .d...... ........
00e0 00 00 00 00 00 03 00 00 00 01 00 00 00 20 00 00 ........ ..... ..
00f0 00 00 00 01 00 01 00 00 00 02 05 01 00 01 00 01 ........ ........
0100 00 20 00 01 01 09 00 00 00 01 00 01 01 00 00 00 . ...... ........
0110 00 26 00 00 00 02 00 02 00 00 00 00 00 21 00 00 .&...... .....!..
0120 00 7c 00 00 00 00 00 00 00 01 00 00 00 00 00 00 .|...... ........
0130 00 24 00 00 00 20 00 00 00 66 00 00 00 00 00 00 .$... .. .f......
0140 00 01 00 00 00 0e 31 39 32 2e 31 36 38 2e 31 2e ......19 2.168.1.
0150 32 30 32 00 0e ec 00 40 00 00 00 00 00 08 06 06 202....@ ........
0160 67 81 02 01 01 01 00 00 00 17 04 01 00 08 06 06 g....... ........
0170 67 81 02 01 01 01 00 00 00 07 64 65 66 61 75 6c g....... ..defaul
0180 74 00 04 00 00 00 00 00 00 00 00 00 00 01 00 00 t....... ........
0190 00 08 06 06 67 81 02 01 01 01 00 00 00 0f 00 00 ....g... ........
01a0 00 00 00 00 00 2b 49 44 4c 3a 6f 6d 67 2e 6f 72 .....+ID L:omg.or
01b0 67 2f 43 6f 73 4e 61 6d 69 6e 67 2f 4e 61 6d 69 g/CosNam ing/Nami
01c0 6e 67 43 6f 6e 74 65 78 74 45 78 74 3a 31 2e 30 ngContex tExt:1.0
01d0 00 00 00 00 00 01 00 00 00 00 00 00 00 a2 00 01 ........ ........
01e0 02 00 00 00 00 0e 31 39 32 2e 31 36 38 2e 31 2e ......19 2.168.1.
01f0 32 30 32 00 0e 74 00 00 00 4d af ab cb 00 00 00 202..t.. .M......
0200 00 20 00 00 00 64 00 00 00 09 53 31 41 53 2d 4f . ...d.. ..S1AS-O
0210 52 42 00 00 00 00 00 00 00 02 00 00 00 08 52 6f RB...... ......Ro
0220 6f 74 50 4f 41 00 00 00 00 0d 54 4e 61 6d 65 53 otPOA... ..TNameS
0230 65 72 76 69 63 65 00 00 00 00 00 00 00 08 00 00 ervice.. ........
0240 00 01 00 00 00 01 14 00 00 00 00 00 00 02 00 00 ........ ........
0250 00 01 00 00 00 20 00 00 00 00 00 01 00 01 00 00 ..... .. ........
0260 00 02 05 01 00 01 00 01 00 20 00 01 01 09 00 00 ........ . ......
0270 00 01 00 01 01 00 00 00 00 26 00 00 00 02 00 02 ........ .&......

As you can see the server send to my client the private IP and not the public.... I don't understand what i can do for resolve this....
Thank you a lot!

set the public IP as IP for IIOP listener, will that not solve the problem ?

Comment by Rebecca Parks [ 24/Jan/12 ]

This has been flagged for the 3.1.2 Release Notes, but I'm not sure what the Release Notes should say. I think I understand the problem, which is summed up in this paragraph:

"The problem is due to the IIOP protocol as implemented on the Glassfish server. It does a first call on the ORB to locate the EJB (which is deployed on the same server as the ORB). Thus, the ORB sends the private IP to the client, instead of the public IP (which it has no way of knowing, as it is determined by the firewall)... The client then tries to connect on the private IP, which does not go though the firewall."

What I'm not sure I understand is the workaround. Is it the code that Blaise posted?

Comment by Harshad Vilekar [ 25/Jan/12 ]

There is no properly tested workaround available for this issue.

Comment by mone_java [ 25/Jan/12 ]

So for now, it is impossible to communicate with an EJB on a server debian? I have not tried it with windows server ... The code of Blaise Gosselin has been applied, or has been removed? Otherwise for now try with that code, because I need it to work!

ps And another question... Why the client sends to the server 127.0.1.1 ?

Comment by mone_java [ 29/Jan/12 ]

I tried the version 3.1.2_b06 but does not work.... What is your setting of the iiop listener?

Comment by thezebulette [ 16/Apr/12 ]

hello
I think I had the same problem trying to deploy my Eclipse RCP application ( EJB3 inside )

I don't have any problem accesing glassfish server on private adress
I can't ( and I had try all) calling my application on public adress outside the DMZ ..

What are the clue in fine ? any

Comment by ymajoros [ 15/Jan/13 ]

Hi,

Is it possible to have an answer to this problem please?

I work with Blaise Gosselin, who made the patch in #4, and we still have the issue. We have to patch every new version of Glassfish as described.

Thanks in advance for your help!

KR,

Comment by Tom Mueller [ 07/Feb/13 ]

Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.

Comment by hoseka [ 22/Apr/13 ]

Hi all!
Can I solve this problem in version 3.1.2?
Does the correction proposed by Blaise Gosselin work?
Where can I get the source orb-iiop.jar to fix it and replace in my glassfish?

Comment by skgaju [ 05/Sep/13 ]

has anyone tried setting public IP to IIOP listener and Blaise Gosselin patch.





[GLASSFISH-14687] [regression] javax.xml.ws.WebServiceException while deploying a 109 web service Created: 15/Nov/10  Updated: 17/Feb/12

Status: Reopened
Project: glassfish
Component/s: test
Affects Version/s: 3.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: sonymanuel Assignee: Sreekanth
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Attachments: Java Archive File 14687-src.jar     File jaxws-wsamss11.war     File jaxws-wsamss12.war     Text File server.log    
Issuezilla Id: 14,687
Tags: 3_1-exclude, 3_1_2-exclude, metro2_2-waived

 Description   

While deploying the attached applications on 3.1 build 29 get the following
exception. This used to work fine with GF 3.0.1.

[#|2010-11-15T18:57:38.336+0530|WARNING|glassfish3.1|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=14;_ThreadName=Thread-1;|Deployment
failed
javax.xml.ws.WebServiceException: WSDL
jndi:/server/jaxws-wsamss11/WEB-INF/wsdl/wsaTestService.wsdl has the following
services [

{http://example.org/wsaTestService}

wsaTestService] but not . Maybe you
forgot to specify a serviceName and/or targetNamespace in
@WebService/@WebServiceProvider?
at
com.sun.xml.ws.server.EndpointFactory.verifyPrimaryWSDL(EndpointFactory.java:481)
at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:159)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:513)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:568)
at
org.glassfish.webservices.WSServletContextListener.registerEndpoint(WSServletContextListener.java:260)
at
org.glassfish.webservices.WSServletContextListener.contextInitialized(WSServletContextListener.java:99)
at
org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:4703)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:533)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5323)
at com.sun.enterprise.web.WebModule.start(WebModule.java:497)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:697)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1934)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1611)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:100)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:242)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:262)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:438)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:243)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:351)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1061)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1257)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1246)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:396)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:216)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

#]

[#|2010-11-15T18:57:38.343+0530|SEVERE|glassfish3.1|org.apache.catalina.core.StandardContext|_ThreadID=14;_ThreadName=Thread-1;|PWC1306:
Startup of context /jaxws-wsamss11 failed due to previous errors|#]

[#|2010-11-15T18:57:38.347+0530|SEVERE|glassfish3.1|org.apache.catalina.core.StandardContext|_ThreadID=14;_ThreadName=Thread-1;|PWC1305:
Exception during cleanup after start failed
org.apache.catalina.LifecycleException: PWC2769: Manager has not yet been started
at org.apache.catalina.session.StandardManager.stop(StandardManager.java:872)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:5527)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:528)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5341)
at com.sun.enterprise.web.WebModule.start(WebModule.java:497)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:697)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1934)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1611)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:100)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:242)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:262)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:438)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:243)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:351)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1061)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1257)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1246)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:396)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:216)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

#]


 Comments   
Comment by sonymanuel [ 15/Nov/10 ]

Created an attachment (id=5464)
webservice app

Comment by sonymanuel [ 15/Nov/10 ]

Created an attachment (id=5465)
app2

Comment by sonymanuel [ 15/Nov/10 ]

Created an attachment (id=5466)
server log

Comment by Bhakti Mehta [ 20/Nov/10 ]

Is this only happening in specific cases. I do not see cts failures related to
this. Requesting Rama to look into this

Comment by jitu [ 08/Dec/10 ]

Can you attach the source code. Want to see primarily @WebService, @WebServiceProvider annotations.
WEB-INF/classes/wsa/msinterop/s11/server/NonAnonymousProvider.class
WEB-INF/classes/wsa/msinterop/s11/server/WsaTestImpl.class
WEB-INF/classes/wsa/msinterop/s11/server/WsaTestPortType.class
WEB-INF/classes/wsa/msinterop/s11/server/WsaTestService.class

Comment by sonymanuel [ 08/Dec/10 ]

Attaching requested src.

Comment by jitu [ 09/Dec/10 ]

@WebServiceProvider(wsdlLocation="WEB-INF/wsdl/wsaTestService.wsdl")
@ServiceMode(value = Service.Mode.MESSAGE)
public class NonAnonymousProvider implements Provider<SOAPMessage> {
}

In the above class, WSDL is specified, but not serviceName, portName, and targetNamespace elements. Otherwise, runtime cannot find a correponding port in WSDL. I would be really surprised, if this really worked any time.

Also, I don't see any use in specifying wsdlLocation in this case. Correct the test.

Comment by jitu [ 09/Dec/10 ]

Test case is invalid.

Comment by sonymanuel [ 21/Dec/10 ]

I tried deploying the app on GF 3.0.1 and it works fine. See logs below.

[#|2010-12-21T22:53:24.424+0530|INFO|glassfish3.0.1|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=26;_ThreadName=Thread-1;|WS00018: Webservice Endpoint deployed
WsaTestImpl listening at address at http://localhost:10128/jaxws-wsamss11/wsaTestService|#]

[#|2010-12-21T22:53:24.425+0530|INFO|glassfish3.0.1|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=26;_ThreadName=Thread-1;|WS00018: Webservice Endpoint deployed
wsa.msinterop.s11.server.NonAnonymousProvider listening at address at http://localhost:10128/jaxws-wsamss11/NonAnonymousProviderService|#]

[#|2010-12-21T22:53:24.475+0530|INFO|glassfish3.0.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=26;_ThreadName=Thread-1;|Loading application jaxws-wsamss11 at /jaxws-wsamss11|#]

[#|2010-12-21T22:53:24.475+0530|INFO|glassfish3.0.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=26;_ThreadName=http-thread-pool-10096-(1);|Loading application jaxws-wsamss11 at /jaxws-wsamss11|#]

[#|2010-12-21T22:53:24.475+0530|INFO|glassfish3.0.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=26;_ThreadName=http-thread-pool-10096-(1);|Loading application jaxws-wsamss11 at /jaxws-wsamss11|#]

[#|2010-12-21T22:53:24.486+0530|INFO|glassfish3.0.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=26;_ThreadName=Thread-1;|jaxws-wsamss11 was successfully deployed in 229 milliseconds.|#]

I checked the CVS history for this test case. This particular test was written by Arun and checked in by Deepak (I think) on 2007/03/09. There has been no change to the test or config file since. Since it deployed fine on GF 3.0.1, I assume it worked on all prior GF/Metro releases till 2007/03/09

Reopening the issue as it is a regression and ~450 jax-wsa interop test cases are blocked because of this deployment issue.

The sources are available
tango/qe-tests/jax-wsa/interop-109/src/wsamss11

If its a test case please let me know exactly what to fix since I am fairly new to this.

With the 20th Dec nightly build I am seeing a NPE.

[#|2010-12-21T22:46:24.266+0530|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=15;_ThreadName=Thread-1;|The log message is null.
java.lang.RuntimeException
at org.glassfish.webservices.WebServicesDeployer.prepare(WebServicesDeployer.java:192)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:870)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:410)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1080)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1260)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1248)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:453)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:220)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
at org.glassfish.webservices.WebServicesDeployer.doWebServiceDeployment(WebServicesDeployer.java:719)
at org.glassfish.webservices.WebServicesDeployer.doWebServicesDeployment(WebServicesDeployer.java:650)
at org.glassfish.webservices.WebServicesDeployer.prepare(WebServicesDeployer.java:183)
... 29 more

#]
Comment by ramapulavarthi [ 23/Dec/10 ]

We should definitely fix the NPE.

Regarding the original issue, as Jitu mentioned test case need to be fixed to specify serviceName and portName and targetNameSpace in @WebServiceProvider matching those attributes in the packaged wsdl. In V2 we might be creating the web service endpoint lazily giving a false sense of deployment success. If you try to access the endpoint, then you would see if the web service was created successfully. Check the logs by accessing http://localhost:10128/jaxws-wsamss11/NonAnonymousProviderService in a browser after deploying on V2 or V3.0.1. Though the testcase is not modified, it is possible that the the test case has not been ever verified to make sure that the non-anonymous endpoint receives messages.

Comment by ramapulavarthi [ 23/Dec/10 ]

Removing the 3_1-regression keyword as it is not real regression. Adding 3_1-exclude so that sqe can continue to track for fixing the test case.

As earlier evaluated, in V3.1 we are creating web service endpoints on deployment unlike in previous versions where endpoints are lazily created. This is done as fix for https://glassfish.dev.java.net/issues/show_bug.cgi?id=14061. This is one way good that it finds the serious runtime errors during deployment itself. The sqe test case should be corrected and the exception in the log is clear on what is missing. Here is the excerpt from v3.1 log.

Caused by: java.lang.RuntimeException: Servlet web service endpoint '' failure
at org.glassfish.webservices.WSServletContextListener.contextInitialized(WSServletContextListener.java:104)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:4683)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:531)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5303)
... 38 more
Caused by: javax.xml.ws.WebServiceException: WSDL jndi:/server/jaxws-wsamss11/WEB-INF/wsdl/wsaTestService.wsdl has the following services [

{http://example.org/wsaTestService}

wsaTestService] but not . Maybe you forgot to specify a serviceName and/or targetNamespace in @WebService/@WebServiceProvider?
at com.sun.xml.ws.server.EndpointFactory.verifyPrimaryWSDL(EndpointFactory.java:481)
at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:159)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:513)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:568)
at org.glassfish.webservices.WSServletContextListener.registerEndpoint(WSServletContextListener.java:260)
at org.glassfish.webservices.WSServletContextListener.contextInitialized(WSServletContextListener.java:99)
... 41 more

#]
Comment by ramapulavarthi [ 23/Dec/10 ]

sqe should fix the testcase

Comment by sonymanuel [ 03/Jan/11 ]

Assigning to Anand for checking the testcase.

Comment by Martin Grebac [ 09/Dec/11 ]

Sreekanth, is this one still valid?

Comment by Sreekanth [ 17/Feb/12 ]

This is still an issue with the latest promoted build of glassfish 3.1.2.Will try to fix as suggested by Jitu and Rama





[GLASSFISH-14389] [BLOCKING] asadmin -m * and asadmin --monitor=true * is not working as it mention on the online --help. Created: 03/Nov/10  Updated: 18/Feb/13

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

Type: Bug Priority: Critical
Reporter: Homer Yau Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
depends on GLASSFISH-14461 Extra "server." in monitoring output ... Resolved
Issuezilla Id: 14,389
Tags: added-devtest

 Description   

"asadmin -m *" and "asadmin --monitor=true *" is not working as it mention on
the online --help.

I have created a cluster instance for monitoring test and turn it to "HIGH".

-bash-3.2$ asadmin list -m *
Command list executed successfully.

-bash-3.2$ asadmin list -m=true *
Command list executed successfully.

You could see what online help says, I think it confuse user.
It says the " ./asadmin list * " to see all the monitoring element.

-bash-3.2$ asadmin list --help

User need to know the element start point and need to able to list.
The following command works.

-bash-3.2$ asadmin list -m=true monitoring-server.*
-bash-3.2$ asadmin list -m monitoring-server.*
monitoring-server :
monitoring-server.server
monitoring-server.server.applications
monitoring-server.server.applications.__default-web-module
monitoring-server.server.applications.__default-web-module.server
monitoring-server.server.applications.__default-web-module.server.default
monitoring-server.server.applications.__default-web-module.server.jsp
monitoring-server.server.applications.standalonewebmod1
monitoring-server.server.applications.standalonewebmod1.server
monitoring-server.server.applications.standalonewebmod1.server.default
monitoring-server.server.applications.standalonewebmod1.server.jsp
monitoring-server.server.applications.standalonewebmod1.server.standalonewebmod1_Servlet1
monitoring-server.server.applications.standalonewebmod1.server.standalonewebmod1_Servlet2
monitoring-server.server.applications.standalonewebmod2
monitoring-server.server.applications.standalonewebmod2.server
monitoring-server.server.applications.standalonewebmod2.server.ErrorServlet
monitoring-server.server.applications.standalonewebmod2.server.ReceiveBytes
monitoring-server.server.applications.standalonewebmod2.server.SecureServlet
monitoring-server.server.applications.standalonewebmod2.server.SendBytes
monitoring-server.server.applications.standalonewebmod2.server.default
monitoring-server.server.applications.standalonewebmod2.server.jsp
monitoring-server.server.applications.standalonewebmod2.server.standalonewebmod2_Servlet1
monitoring-server.server.applications.standalonewebmod2.server.standalonewebmod2_Servlet2
monitoring-server.server.applications.webapp1
monitoring-server.server.applications.webapp1.webapp1webmod1\.war
monitoring-server.server.applications.webapp1.webapp1webmod1\.war.server
monitoring-server.server.applications.webapp1.webapp1webmod1\.war.server.default
monitoring-server.server.applications.webapp1.webapp1webmod1\.war.server.jsp
monitoring-server.server.applications.webapp1.webapp1webmod1\.war.server.webapp1webmod1_Servlet1
monitoring-server.server.applications.webapp1.webapp1webmod1\.war.server.webapp1webmod1_Servlet2
monitoring-server.server.applications.webapp1.webapp1webmod2\.war
monitoring-server.server.applications.webapp1.webapp1webmod2\.war.server
monitoring-server.server.applications.webapp1.webapp1webmod2\.war.server.default
monitoring-server.server.applications.webapp1.webapp1webmod2\.war.server.jsp
monitoring-server.server.applications.webapp1.webapp1webmod2\.war.server.webapp1webmod2_Servlet1
monitoring-server.server.applications.webapp1.webapp1webmod2\.war.server.webapp1webmod2_Servlet2
monitoring-server.server.applications.webapp2
monitoring-server.server.applications.webapp2.webapp2webmod1\.war
monitoring-server.server.applications.webapp2.webapp2webmod1\.war.server
monitoring-server.server.applications.webapp2.webapp2webmod1\.war.server.default
monitoring-server.server.applications.webapp2.webapp2webmod1\.war.server.jsp
monitoring-server.server.applications.webapp2.webapp2webmod1\.war.server.webapp2webmod1_Servlet1
monitoring-server.server.applications.webapp2.webapp2webmod1\.war.server.webapp2webmod1_Servlet2
monitoring-server.server.applications.webapp2.webapp2webmod2\.war
monitoring-server.server.applications.webapp2.webapp2webmod2\.war.server
monitoring-server.server.applications.webapp2.webapp2webmod2\.war.server.default
monitoring-server.server.applications.webapp2.webapp2webmod2\.war.server.jsp
monitoring-server.server.applications.webapp2.webapp2webmod2\.war.server.webapp2webmod2_Servlet1
monitoring-server.server.applications.webapp2.webapp2webmod2\.war.server.webapp2webmod2_Servlet2
monitoring-server.server.web
monitoring-server.server.web.jsp
monitoring-server.server.web.request
monitoring-server.server.web.servlet
monitoring-server.server.web.session

Command list executed successfully.



 Comments   
Comment by Nazrul [ 03/Nov/10 ]

This is blocking tests execution for monitoring.

Comment by Byron Nevins [ 03/Nov/10 ]

I'm guessing that it is behaving exactly the same as V3 final release – in
which case it will be a big deal...

Comment by Byron Nevins [ 05/Nov/10 ]

"I have created a cluster instance for monitoring test and turn it to "HIGH"."

What does the above mean? How about simply copying & pasting the actual
commands you ran?

Comment by Byron Nevins [ 05/Nov/10 ]

What did you set to high?

Comment by Byron Nevins [ 05/Nov/10 ]

Output from 3.0.1

C:\glassfishv3\glassfish\bin>asadmin list -m "*"
server
server.applications
server.applications.AuthAdmin
server.applications.AuthAdmin.server
server.applications.AuthAdmin.server.AuthCreationManager
server.applications.AuthAdmin.server.AuthManager
server.applications.AuthAdmin.server.AuthUpdateManager
server.applications.AuthAdmin.server.Registrar
server.applications.AuthAdmin.server.Signup
server.applications.AuthAdmin.server.default
server.applications.AuthAdmin.server.jsp
server.applications.__default-web-module
server.applications.__default-web-module.server
server.applications.__default-web-module.server.default
server.applications.__default-web-module.server.jsp
server.http-service
server.http-service.__asadmin
server.http-service.__asadmin.request
server.http-service.server
server.http-service.server.request
server.jvm
server.jvm.class-loading-system
server.jvm.compilation-system
server.jvm.garbage-collectors
server.jvm.garbage-collectors.Copy
server.jvm.garbage-collectors.MarkSweepCompact
server.jvm.memory
server.jvm.operating-system
server.jvm.runtime
server.jvm.thread-system
server.jvm.thread-system.thread-10
server.jvm.thread-system.thread-12
server.jvm.thread-system.thread-13
server.jvm.thread-system.thread-14
server.jvm.thread-system.thread-15
server.jvm.thread-system.thread-16
server.jvm.thread-system.thread-18
server.jvm.thread-system.thread-2
server.jvm.thread-system.thread-20
server.jvm.thread-system.thread-22
server.jvm.thread-system.thread-23
server.jvm.thread-system.thread-24
server.jvm.thread-system.thread-3
server.jvm.thread-system.thread-30
server.jvm.thread-system.thread-31
server.jvm.thread-system.thread-32
server.jvm.thread-system.thread-33
server.jvm.thread-system.thread-34
server.jvm.thread-system.thread-35
server.jvm.thread-system.thread-36
server.jvm.thread-system.thread-37
server.jvm.thread-system.thread-38
server.jvm.thread-system.thread-39
server.jvm.thread-system.thread-4
server.jvm.thread-system.thread-40
server.jvm.thread-system.thread-41
server.jvm.thread-system.thread-42
server.jvm.thread-system.thread-43
server.jvm.thread-system.thread-44
server.jvm.thread-system.thread-45
server.jvm.thread-system.thread-46
server.jvm.thread-system.thread-47
server.jvm.thread-system.thread-49
server.jvm.thread-system.thread-5
server.jvm.thread-system.thread-9
server.network
server.network.admin-listener
server.network.admin-listener.connection-queue
server.network.admin-listener.file-cache
server.network.admin-listener.keep-alive
server.network.admin-listener.thread-pool
server.network.http-listener-1
server.network.http-listener-1.connection-queue
server.network.http-listener-1.file-cache
server.network.http-listener-1.keep-alive
server.network.http-listener-1.thread-pool
server.network.http-listener-2
server.network.http-listener-2.connection-queue
server.network.http-listener-2.file-cache
server.network.http-listener-2.keep-alive
server.network.http-listener-2.thread-pool
server.security
server.security.web
server.transaction-service
server.web
server.web.jsp
server.web.request
server.web.servlet
server.web.session

Command list executed successfully.

Comment by Byron Nevins [ 05/Nov/10 ]

Homer -
I know what you do NOT want it to do.

What do you WANT it to do?

====================================================

I can see exactly why you are getting the results you documented. Vijay
programmed it three months ago to do this:

Take the arg. and parse out everything before the first dot. If there is no dot
– then take the entire string. That is the server name
Then call that server and run the get command on it...

So say you give these args:

server.* --> name of server == "server"

  • --> name of remote server == "*" !!!

============

So in your case it contacts the server named "", sees that "" is not running
and returns nothing.

=========================

Comment by Byron Nevins [ 05/Nov/10 ]

I get no output from:

asadmin list -m monitoring-server.*

I'm guessing that monitoring-server is the name of a server instance you created?
Why am I guessing?

Comment by Byron Nevins [ 05/Nov/10 ]

I have no instructions on WHAT EXACTLY it should do.
I will implement solution #3 if I don't hear back soon...

asadmin list -m "*"

to do

What it does right now is very brain-dead. It blindly assumes that "*" is the
name of a server instance. So obviously that should change. But change to what?

(1) Assume the user wants a list of everything for DAS and every running server
instance. Call every instance and stick all the outputs into one big list

(2) Fail with an error saying something like "You must specify a server"

(3) *Assume* that if there is no server name that the user wants output from
DAS.

I like (3) – it knits together with 3.0.1 output the best.

Comment by Byron Nevins [ 05/Nov/10 ]

Here is how V2 handles 'get -m "*"'

case 1 – only DAS is running

C:\glassfish\bin>asadmin list -m "*"
server
server.applications
server.applications.WSTXServices
server.applications.__JWSappclients
server.applications.__JWSappclients.sys\.war
server.applications.__default-web-module
server.applications.adminapp
server.applications.admingui
server.connector-service
server.http-service
server.http-service.server
server.jms-service
server.jvm
server.orb
server.orb.connection-managers
server.resources
server.thread-pools

case 2: DAS and i1 are running

C:\glassfish\bin>asadmin list -m "*"
i1
i1.applications
i1.applications.WSTXServices
i1.applications.__JWSappclients
i1.applications.__JWSappclients.sys\.war
i1.applications.__default-web-module
i1.connector-service
i1.http-service
i1.http-service.server
i1.jms-service
i1.jvm
i1.orb
i1.orb.connection-managers
i1.resources
i1.thread-pools
server
server.applications
server.applications.WSTXServices
server.applications.__JWSappclients
server.applications.__JWSappclients.sys\.war
server.applications.__default-web-module
server.applications.adminapp
server.applications.admingui
server.connector-service
server.http-service
server.http-service.server
server.jms-service
server.jvm
server.orb
server.orb.connection-managers
server.resources
server.thread-pools

Comment by Byron Nevins [ 07/Nov/10 ]

Notice how the output is:

monitoring-server.server.applications

In V2 it would have been:

monitoring-server.applications

    • blocking bug created for this – 14461
Comment by Byron Nevins [ 07/Nov/10 ]

There used to be 5 lines of code figuring out what part of the "pattern" is
really the regular expression pattern and what part is the target. And handling
defaults, etc.

Now there is ~~ 300 lines of code doing this. It needs massive, but rapid,
testing by Homer informally at a console. E.g. here are a bunch of commands
that should all do what you would hope they would do

You have a cluster c1 with 2 instances c1i1, c1i2 and 2 stand-alone instance i1,i2

asadmin get -m "*" – get EVERYTHING from EVERY instance and DAS
asadmin get -m "server.*" - get everything from DAS
asadmin get -m "c1.*" get everything from c1i1 and c1i2
asadmin get -m "c1i1.*" get everything from c1i1
asadmin get -m "c1i1.server.*" exactly like above. ignore the "server."
asadmin get -m "." – just like ""

And on and on and on – you'll think of more!
asadmin get -m "
asadmin get -m "
asadmin get -m "

Comment by Byron Nevins [ 07/Nov/10 ]

There are 2 parts to this bug – get and list
get is now fixed.
list is next to be fixed.

Homer – get is ready for your testing!

C:\gf\v3\core\kernel>svn commit -F ..\qqq
Sending kernel\src\main\java\com\sun\enterprise\v3\admin\GetCommand.java
Sending
kernel\src\main\java\com\sun\enterprise\v3\admin\LocalStrings.properties
Adding
kernel\src\main\java\com\sun\enterprise\v3\admin\MonitoringReporter.java
Transmitting file data ...
Committed revision 42545.

Comment by Byron Nevins [ 10/Nov/10 ]

List is done now too.

Finis!

Comment by Tom Mueller [ 03/May/12 ]

Reopening this issue because the admin devtests are failing (sometimes) when the test that was written for this issue is enabled.

It appears that this is related to retrieving monitoring data from remote instances.





[GLASSFISH-701] Sequence generator conflicts with existing primary key values Created: 02/Jun/06  Updated: 01/Nov/12

Status: Reopened
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: future release

Type: New Feature Priority: Critical
Reporter: craig_mcc Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 701

 Description   

When I build a persistence unit for a set of entity classes that correspond to
an existing database (again, in my case, I was using the TRAVEL example database
that ships with Creator 2 Update 1), I wanted to take advantage of the ability
to autogenerate primary key values. When I deployed an application using these
classes the first time, it created a SEQUENCE table for me (good). But the
starting value it stored in the SEQ_COUNT column was within a range of primary
key values that were used by existing rows in the database (bad), so I got a
"duplicate key" error the first time I tried to insert a new row.

Workaround is to manually adjust the stored sequence number to something larger
than the highest used key in any of the existing tables represented in this
persistence unit. But that is something the JPA architecture should do for me,
so I don't have to.



 Comments   
Comment by marina vatkina [ 07/Jun/06 ]

Hmmm... I'm confused... If you map entities to existing tables, we do not add
any more tables to the mapping, and your SEQUENCE table should already exist. If
you use java2db functionality to create or drop-and-create tables, the new tables
will be created and no pre-existing data should be found in them.

Can you please check?

Comment by marina vatkina [ 13/Jun/06 ]

Looks for me as a user error - the use of create-tables with existing tables.
If this is not the case, please provide a reproduceable test case and reopen the
issue

Comment by craig_mcc [ 14/Jul/06 ]

The use case was listed in the original report, but the important issues are
summarized again here:

  • The data tables already existed, because they were created
    for a previously existing application (in this case the database
    involved is the Travel Center example database that is shipped
    with Sun Java Studio Creator.
  • The SEQUENCE table did not previously exist, because this is the
    first time that these data tables were being accessed via a
    JPA persistence unit.
  • The first time an application is deployed using JPA to access these
    tables, a SEQUENCE table was created. However, no attempt was made
    to ensure that the sequence numbers about to be generated would not
    conflict with primary key values that were already assigned by the
    previous applications that populated these data tables.
  • As a result, any attempt to add a new row in any table supported by
    a JPA entity class runs the risk of creating a collision on a primary
    key value. Since a large number of potential uses for Glassfish
    involves creating JPA entity classes to work with existing database
    tables, this is definitely a sub-optimal result.

This is a P2 only because there is a workaround – go in with the command
console for the database in use and manually tweak the SEQ_COUNT value in the
one and only row of the SEQUENCE table. But that is not a user-friendly solution.

An upcoming version of Creator will feature support for JPA entity classes. I
am not interested in apologizing for this functionality in the underlying database.

Craig McClanahan
Architect, Java Studio Creator

Comment by Sanjeeb Sahoo [ 15/Jul/06 ]

Added myself to cc-list

Comment by ijuma [ 17/Jul/06 ]

Adding myself to cc list.

Comment by marina vatkina [ 17/Jul/06 ]

I feel that there is a disconnect here. You think that there is a bug in an
interesting feature - adding a SEQUENCE table to an existing set of tables, and
I'm saying that such feature does not exist: we either create all of the tables
(or at least try to), or use existing set of tables.

Please check your persistence.xml - does it have property
"toplink.ddl-generation" set to either "drop-and-create-tables" or
"create-tables"?

  • If not, no tables will be created at deployment. No exceptions.
  • If yes, all of them will be created (or at least attempted), again without any
    exception. Which means that those tables which names conflict with the existing
    ones will fail to be created, and those that don't (SEQUENCE in your case) will
    succeed.
    If you still have the server.log around, you should see error messages about
    failed statement execution. Those errors are also (unless there is another bug)
    displayed in the output of the asadmin deploy command.

While partial table creation is an interesting feature, it's not a bug in the
current implementation. Do you want to keep it as a feature request, or change
to a doc bug to add a warning to our docs about possible side effects of using
auto DDL generation?

Meanwhile I'm downgrading the bug.

Regards,
-marina

Comment by craig_mcc [ 17/Jul/06 ]

Yes, the persistence unit was set for create tables – deleting the existing
production tables would not have been a good thing. Yes, SEQUENCE is the only
table that was created; all the rest failed because the tables already existed.

However, the initial sequence number was set to a value such that, on the very
first attempt to insert a new row, I got a duplicate primary key error. Whose
fault was that? It sure isn't the developer's fault that their persistence
framework was not smart enough to recognize it was being configured (for the
first time) on data tables that already head existing rows.

Given that the vast majority of people who try JPA for the first time are going
to be dealing with existing database tables, I am not the only person who is
going to run into this problem. Sounds like I need to go over your head and
lean on Tony a bit to get this issue paid attention to, so that's what I'll do next.

Craig

Comment by marina vatkina [ 25/Jul/06 ]

Feature request

Comment by marina vatkina [ 06/Sep/06 ]

The requested feature will not be spec compliant if implemented by default (i.e.
without any extra hint or vendor specific annotation). Users of such
applications will not know that they are relying on a vendor-specific behavior.

The spec requires (see 9.1.37) that SEQUENCE has an initial value of 1 if the
initialValue is not specified. Does specifying the initialValue in the
annotation solves your problem?

Regards,
-marina

Comment by craig_mcc [ 06/Sep/06 ]

> The requested feature will not be spec compliant if implemented by default (i.e.
> without any extra hint or vendor specific annotation). Users of such
> applications will not know that they are relying on a vendor-specific behavior.

Wow, that's a pretty horrible spec bug, then. I'll forward a pointer to this to
the JSR-220 expert grup.

> The spec requires (see 9.1.37) that SEQUENCE has an initial value of 1 if the
> initialValue is not specified. Does specifying the initialValue in the
> annotation solves your problem?

No.

Consider a scenario where I am building an app in a big enterprise installation
that has multiple stagings for deploying an updated version of an existing app
(test, staging, and production). What are the chances that any single
initialValue will be appropriate for all of them? What happens when I redeploy
later and the "used" values have changed?

As it is, the only thing I can see the developer doing is going into the
SEQUENCE table with a SQL console, and manually changing the value. That means
several things:

  • They have to understand the cause of this problem in the first place.
  • They have to understand how to construct an appropriate SQL UPDATE
    statement.
  • They have to undertand how to use a SQL command tool to update the
    SEQUENCE table, which is implementation specific.

That is not an appropriate solution for a Java EE 5 release that bills itself
as being focused on ease of use.

Craig McClanahan

Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Mitesh Meswani [ 01/Nov/12 ]

Not targeting for 4.0.

I think a RFE should be filled against JPA spec to discuss this further.





[GLASSFISH-17358] Embedded GF started using instanceRoot fails to compile JSPs in WAR Created: 27/Sep/11  Updated: 01/Mar/12

Status: Reopened
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Amy Roh Assignee: Bhavanishankar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File hello.war     Java Source File JspTest.java    

 Description   

Embedded GF started using instanceRoot fails to compile JSPs in WAR.

If instanceRoot isn't set using GlassFishProperties, JSPs work fine.

/* IF YOU START THIS WAY, JSPS WORK
GlassFishProperties props = new GlassFishProperties();
props.setPort("http-listener", 8080);

GlassFish glassfish = GlassFishRuntime.bootstrap().newGlassFish(props);
glassfish.start();
*/

// JSPS DON'T WORK IF YOU SET INSTANCEROOT
String instanceRoot = "/glassfish3/glassfish/domains/domain1";
GlassFishProperties gfProps = new GlassFishProperties();
gfProps.setInstanceRoot(instanceRoot);

This happens with glassfish-embedded-all.jar and -web.jar.



 Comments   
Comment by Amy Roh [ 21/Oct/11 ]

When using installRoot, glassfish-embedded-static-shell.jar needs to be in CLASSPATH instead of glassfish-embedded-web.jar.

Comment by Amy Roh [ 01/Mar/12 ]

According to Bhavani, setting instanceRoot should work with all-in-one.jar for JSP compilation.





[GLASSFISH-18320] [Regression] Addition of AdminConsoleStartupService broke EJB embedded Container Created: 03/Feb/12  Updated: 15/Mar/12

Status: Reopened
Project: glassfish
Component/s: admin
Affects Version/s: 4.0
Fix Version/s: None

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


 Description   

EJB embeddable container suppresses services that won't be necessary for regular testing of local EJBs. One of such services is a Web container. We do it by modifying domain.xml on the fly and using that temporary version during the run.

02/03/2012 hudson build (http://hudson-sca.us.oracle.com/job/ejb-devtests-v3/623/) failed with

java.lang.IllegalStateException: Can't operate without at least one <network-listener>
[java] at com.sun.enterprise.config.util.ServerHelper.getAdminListener(ServerHelper.java:164)
[java] at com.sun.enterprise.config.serverbeans.Config$Duck.getAdminListener(Config.java:460)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at java.lang.reflect.Method.invoke(Method.java:597)
[java] at org.jvnet.hk2.config.Dom.invokeDuckMethod(Dom.java:961)
[java] at org.jvnet.hk2.config.Dom.invoke(Dom.java:914)
[java] at org.glassfish.config.support.TranslatedConfigView.invoke(TranslatedConfigView.java:131)
[java] at $Proxy30.getAdminListener(Unknown Source)
[java] at com.sun.enterprise.v3.admin.adapter.AdminEndpointDecider.setValues(AdminEndpointDecider.java:118)
[java] at com.sun.enterprise.v3.admin.adapter.AdminEndpointDecider.<init>(AdminEndpointDecider.java:84)
[java] at com.sun.enterprise.v3.admin.adapter.AdminConsoleAdapter.init(AdminConsoleAdapter.java:507)
[java] at com.sun.enterprise.v3.admin.adapter.AdminConsoleAdapter.postConstruct(AdminConsoleAdapter.java:465)

To reproduce (assuming v2/appserv-tests lib/ and config/ are checked out):
cd v2/appserv-tests/devtests/ejb/ejb31/embedded
ant all-report



 Comments   
Comment by Tom Mueller [ 07/Feb/12 ]

Marina,
Do you know when this broke? The recent changes to AdminConsoleAdapter do not change this code that eventually calls ServerHelper.getAdminListener, and ServerHelper hasn't changed since last July.

Can you provide the details of the changes you make to domain.xml. From the exception, it appears as though the admin-listener network-listener has been removed.

Comment by Tom Mueller [ 07/Feb/12 ]

Masoud, this is actually a zero-config issue. Here, we have a situation where the embedded tests have removed the network listener named "admin-listener" and the server (in AdminConsoleAdapter) throws an exception because of it. I expect AdminAdapter would also have a problem here.

We need a design decision here as to whether some minimal configuration is required to have the admin interface (on port 4848) come up or whether it should come up by default if the config information isn't there. I would think that we would want to be able to configure a server that doesn't have an admin interface but this should be discussed.

Comment by marina vatkina [ 07/Feb/12 ]

Tom,

The test started failing on 02/03/2012 (8am). So the change was made in the 24 hours prior to that.

Embedded EJB container is intended for testing EJBs so should start fast and have the least possible outside containers started (e.g. unless a WAR file is being deployed, the web container should not start). You can find all the transformations that are done in ejb/ejb-container/src/main/java/org/glassfish/ejb/embedded/DomainXmlTransformer.java. They were discussed back then with Jerome and Ken Saks.

Also note that there is no way to get currently to the GlassFish API when using embeddable EJB container (http://docs.oracle.com/javaee/6/api/javax/ejb/embeddable/EJBContainer.html).

Comment by Tom Mueller [ 08/Feb/12 ]

The root cause of this was the addition of the AdminConsoleStartupService which was added to the trunk on 2/2/12 in revision 52405.

Assigning to Siraj for an immediate fix since this is breaking the embedded EJB tests.

Siraj, the AdminConsoleStartupService must take into account a configuration where no admin-listener is configured. With the current implementation, AdminConsoleStartupService eventually causes a call to ServerHelper.getAdminListener which throws an exception if there is no admin listener configured. AdminConsoleStartupService needs to handle this exception.

This fix is needed on the trunk.

Comment by sirajg [ 09/Feb/12 ]

The test passes in 3.1.2. In the embedded case, the adapter code is not invoked in 3.1.2, but it is invoked on the trunk.

Comment by sirajg [ 13/Feb/12 ]

Handle the case when no network listeners are found. Revision 52563

Comment by marina vatkina [ 15/Mar/12 ]

The latest change to ServerHelper broke it again





[GLASSFISH-15104] duplicate names between different resource types aren't detected Created: 10/Dec/10  Updated: 28/Feb/13

Status: Reopened
Project: glassfish
Component/s: naming
Affects Version/s: V3
Fix Version/s: future release

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

Tags: 3_1-exclude

 Description   

I can have an environment entry and a resource reference both with the JNDI name "foo"
and nothing seems to detect this error. Part of the problem is that these entries
are stored in separate buckets based on the type of the entry, as seen in the
WritableJndiNameEnvironment interface. Instead, there should be a base class for
all these entries (EnvironmentProperty almost does that, but it mixes in semantics
for simple environment entries) and they should be stored indexed by their canonical
JNDI name, with the ability to retrieve a set of entries of a certain subtype.



 Comments   
Comment by Hong Zhang [ 29/Aug/12 ]

Naman is working on something similar (resource validation for unique jndi name), per discussion with him, assign this issue to him.

Comment by naman_mehta [ 27/Nov/12 ]

Made changes to support AS-ARCH requirement 'Not to allow two resources by same name, irrespective of the resource-type. All resources part of the domain must have the unique name.'.
ie., we would not allow a connector-resource and jdbc-resource by same name.

To support this requirement I added new annotation @UniqueResourceNameConstraint for all resources which validates the resource name is unique across the domain.

@Retention(RUNTIME)
@Target(

{METHOD, FIELD, TYPE}

)
@Documented
@Constraint(validatedBy = UniqueResourceNameValidator.class)
public @interface UniqueResourceNameConstraint

{ .... }

Run all required tests: QL web, QL classic, jdbc, connector, resource, admin-cli.

SVN commit: 55938

Comment by naman_mehta [ 21/Jan/13 ]

The code what I had check-in is part of unique jndi name across all resource type and which is not related to this thing. So re-opening this issue again.

It's related to ,

<resource-ref>
<res-ref-name>MyDB</res-ref-name>
<jndi-name>java:app/env/myString</jndi-name>
</resource-ref>

and

<env-entry>
<env-entry-name>java:app/env/myString</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>myString</env-entry-value>
</env-entry>

We need to identify uniqueness between env-entry-name and jndi-name here. If you check javaee_7.xsd, this is just one scenario and same may be applicable for addEnvironmentProperty, addEjbReferenceDescriptor, addResourceReferenceDescriptor, addResourceEnvReferenceDescriptor under WritableJndiNameEnvironment. We need to check uniqueness between all this.

So it needs to be handle by JNDI Naming team while adding them so assigning this bug to them for there comment and further investigation.

Comment by Kim Haase [ 22/Feb/13 ]

I assume everyone has weighed the merits of this change against the fact that it will break upward compatibility for anyone trying to port glassfish-resources.xml files to GlassFish 4.

For example, for several releases of GlassFish, the way in which the "asadmin create-jms-resource" command created a JMS connection factory was, under the covers, to create a connector connection pool and a connector resource, both with the name specified for the connection factory. I have noticed that the command now appends "-Connection-Pool" to the name of the connection pool.

However, users will now have to edit any glassfish-resources.xml files for GF 3 applications if they want them to work on GF 4. They're likely to find this out the hard way, by getting a duplicate-resource error when they run the add-resources command and then finding that while the connection pool has been created, the connector resource has not, and so the connection pool has to be deleted by hand.

So this change will require a prominent release note, I believe.

Comment by Bill Shannon [ 22/Feb/13 ]

There's a bit of confusion here...

Some change was made that didn't actually address the point of this issue.
If that change introduced a compatibility issue, that's probably a mistake.

This issue is about the JNDI names in the application's JNDI namespace.

Some other administered objects are created in the global JNDI namespace.

Yet other administered objects are created in their own namespaces, unrelated
to the global JNDI namespace. While that may've been a mistake originally,
I'm not sure we should be changing that, for the compatibility reason you state.
And certainly this issue doesn't address that at all.

Comment by Hong Zhang [ 28/Feb/13 ]

Scrub bugs for HCF.
Did not get a chance to work on this yet, as the changes for this issue will be fairly extensive, retarget it for later release.





[GLASSFISH-6208] graphical installer needs ability to enter proxy authorization data Created: 22/Sep/08  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: writtmeyer Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: PNG File gf_v3_install.png     PNG File proxy_authentication_required.png    
Issuezilla Id: 6,208
Status Whiteboard:

gfv3-prelude-excluded


 Description   

The graphical installer fails when a user is behind a proxy that needs
authorization. The last message of the installer is s.th. like "407 -
Authorization necessary" - which is probably the return code of the proxy.

There is neither the ability to enter these data beforehand nor to enter these
when the installer gets this return code.

Best solution IMHO would be to ask the user for authorization data only when a
407 has occurred. The second best would be to allow the user to enter these data
at the same place where he enters the proxy server and port.



 Comments   
Comment by kumara [ 22/Sep/08 ]

v3 defect tracking

Comment by dochez [ 23/Sep/08 ]

need installer improvement to support the feature

Comment by scatari [ 25/Sep/08 ]

Actually, if you are behind firewall, you would have entered proxy information for installing and enabling
update client. In this case, this proxy information is used for registration.

Yes, there is no separate proxy information screen for installer. Next release, we will consolidate the
screens or have a new ui to get this data.

Comment by writtmeyer [ 26/Sep/08 ]

When I use the graphical installer I did not use anything before. Thus the
screen of the attached screenshot is the first possibility to enter any
proxy-information.

Comment by writtmeyer [ 26/Sep/08 ]

Created an attachment (id=1888)
Graphical installer, proxy setup

Comment by writtmeyer [ 26/Sep/08 ]

Due to your comment I have also tried the updatetool itself:

On Linux there is no possibility to enter authorization information in this
tool. And on Windows updatetool fails. While Internet Explorer pops up a box to
enter proxy authentication information, the updatetool does not.

Comment by scatari [ 23/Dec/08 ]

The enhancement request will be addressed as part of the fix for 5117, hence marking this as a duplicate.

      • This issue has been marked as a duplicate of 5117 ***
Comment by writtmeyer [ 26/Oct/09 ]

I'm sorry, I do not agree with the "duplicate" marker. These are two unrelated
issues.

The one is, that it is not possible to enter authorization information at all
(this one). The other is, that you cannot go back some steps during installation
to re-enter any proxy-information (the other bug doesn't mention username/pwd) -
issue 5117.

The real issue at hand here is that without username/pwd neither updatetool nor
registration work. Registration gives 407 authorization message where it
actually should ask the user for a username and password (as any other windows
program does).

This is IMHO a serious issue for GlassFish's adoption in big companies that very
often use proxy authorization.

Reopened as part of my FishCAT testing.

Comment by writtmeyer [ 26/Oct/09 ]

Created an attachment (id=3618)
Dialog box showing the error message (HTTP status code 407)

Comment by Snjezana Sevo-Zenzerovic [ 13/Nov/09 ]
      • Issue 9200 has been marked as a duplicate of this issue. ***




[GLASSFISH-13762] translation issue for wsgen, wsimport and schemagen Created: 01/Oct/10  Updated: 11/Feb/13

Status: Reopened
Project: glassfish
Component/s: l10n
Affects Version/s: 3.1
Fix Version/s: not determined

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

Operating System: All
Platform: All


Issuezilla Id: 13,762

 Description   

run those command will show some messages, but we couldn't find them in
glassfish workspace:

C:\glassfish3\glassfish\bin>wsgen
JDK's tools.jar was not found in C:\Program Files\Java\lib\tools.jar. Usually th
is means you are running JRE, not JDK. Please use the java command in JDK 5.0 or
later (not JRE.)

  • This command executes com.sun.tools.ws.WsGen could not find iWsGen.java in
    source code
    -------------------------------------------------

C:\glassfish3\glassfish\bin>wsimport
JDK's tools.jar was not found in C:\Program Files\Java\lib\tools.jar. Usually th
is means you are running JRE, not JDK. Please use the java command in JDK 5.0 or
later (not JRE.)

-same, could not find com.sun.tools.ws.WsImport.java
-------------------------------------------------

C:\glassfish3\glassfish\bin>schemagen
JDK's tools.jar was not found in C:\Program Files\Java\lib\tools.jar. Usually th
is means you are running JRE, not JDK. Please use the java command in JDK 5.0 or
later (not JRE.)

-same, could not find com.sun.tools.jxc.SchemaGeneratorFacade.java



 Comments   
Comment by gmurr [ 01/Oct/10 ]

we need to find where the .java files come from first.

Comment by Lukas Jungmann [ 09/Feb/13 ]

wsgen and wsimport are in JAX-WS RI workspace - https://svn.java.net/svn/jax-ws~sources/branches/jaxws22

schemagen and xjc are in JAXB RI workspace - https://svn.java.net/svn/jaxb~version2/branches/jaxb-2_2-branch/





[GLASSFISH-12564] Cannot set null string property on Object Message Created: 07/Jul/10  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: jms
Affects Version/s: v3.0.1
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: exabrial Assignee: Nigel Deakin
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
depends on MQ-165 Cannot set null message property Open
Issuezilla Id: 12,564
Tags: 3_1-exclude

 Description   

glassfish v3.0.1
sun jdk 1.6.0_20
windows xp 32bit

The JMS Message interface javadoc states that null is valid value for a string
property on a message.

If you invoke this code in a stateless ejb, you receive the stack trace below

Connection connection = connectionFactory.createConnection();
Session session = connection.createSession(true, Session.AUTO_ACKNOWLEDGE);
MessageProducer producer = session.createProducer(destination);
ObjectMessage message = session.createObjectMessage();
message.setObject(new Object());
message.setStringProperty("aStringProperty", null);

Caused by: java.lang.NullPointerException
at
com.sun.messaging.jms.ra.DirectPacket._checkAndSetProperty(DirectPacket.java:157
9)
at
com.sun.messaging.jms.ra.DirectPacket.setStringProperty(DirectPacket.java:1390)



 Comments   
Comment by Satish Kumar [ 06/Oct/10 ]

Setting target milestone and reassigning this to Nigel ..

Comment by Nigel Deakin [ 11/Oct/10 ]

Updating target milestone to M5 to confirm that this is already fixed.

Comment by Nigel Deakin [ 12/Oct/10 ]

Oops, ignore previous comment added to the wrong issue in error. Setting target
milestone back to M7.

Comment by Nigel Deakin [ 12/Oct/10 ]

In GlassFish 3.1 the error is

SEVERE: Error processing message
javax.jms.MessageFormatException: [C4040]: Invalid ObjectProperty type for
property aStringProperty
at
com.sun.messaging.jmq.jmsclient.MessageImpl.checkAndSetProperty(MessageImpl.java:818)
at
com.sun.messaging.jmq.jmsclient.MessageImpl.setStringProperty(MessageImpl.java:2041)

Comment by Nigel Deakin [ 12/Oct/10 ]

(previous stack trace was for LOCAL brokers),

And in GlassFish 3.1 the stack trace is

Caused by: java.lang.NullPointerException
at
com.sun.messaging.jms.ra.DirectPacket._checkAndSetProperty(DirectPacket.java:1581)
at
com.sun.messaging.jms.ra.DirectPacket.setStringProperty(DirectPacket.java:1392)

which matches what the submitted reported.

Comment by Nigel Deakin [ 12/Oct/10 ]

I've read the JMS 1.1 specification and the JavaDoc for javax.jms.Message, and
have not seen anything which suggests setting a String property can be set to
null. (Feel free to argue).

The behaviour when using a LOCAL broker is correct, which is to throw a
MessageFormatException.

The behaviour when using a EMBEDDED broker is incorrect. A NullPointerException
should not be thrown; a MessageFormatException should be thrown instead. I will
make this change.

Comment by Nigel Deakin [ 12/Oct/10 ]

The exception that is thrown when an embedded broker is used has been changed to:

javax.jms.MessageFormatException: MQJMSRA_DM4001:
setStringProperty():name=aStringProperty:value=null:Bad property value: null

Comment by Nigel Deakin [ 18/Oct/10 ]

Section 3.12 of the JMS spec "Provider Implementations of JMS Message
Interfaces" states:

"The JMS message interfaces provide write/set methods for setting object
values in a message body and message properties. All of these methods must
be implemented to copy their input objects into the message. The value of an
input object is allowed to be null and will return null when accessed."

Reopening this issue and setting target milestone to M7.

Comment by Nigel Deakin [ 26/Oct/10 ]

This does seem a valid complaint, though as it's a spec misinterpretation rather
than a bug, and MQ has almost certainly had this behaviour for many years,
fixing it can't be considered a priority for 3.1.

I'm leaving this as a P3 priority, but deferring it until 3.2 (MQ 4.6).

Comment by vladchuk [ 11/Dec/11 ]

Why is this not being addressed in 3.1.2? It seems that 3.2 has been abandoned (superseded by 4.0) and 4.0 is far away.
Please consider fixing it in 3.1.2.

Comment by exabrial [ 09/Jan/12 ]

any chance this could be fixed in 3.1.2? I can't imagine this is a difficult fix.

Comment by Nigel Deakin [ 03/May/12 ]

I've logged MQ-165 and made this issue dependent on it.

Comment by Nigel Deakin [ 15/Feb/13 ]

In accordance with the project triage guidelines this is not needed for 4.0 and so has been deferred until 4.0.1. Setting "fix version" accordingly.





[GLASSFISH-11233] Installer fails to recognize JDK 1.6 on FreeBSD Created: 02/Dec/09  Updated: 06/Mar/12

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

Type: New Feature Priority: Major
Reporter: vladperl Assignee: scatari
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: FreeBSD
Platform: All


Issuezilla Id: 11,233

 Description   

During installation on FreeBSD v8.0 installer didn’t recognize JDK path from the
page “Select JDK�. Manual setting path to JDK didn’t help to move installation
further (“Next� button was disabled). The following messages probably will
provide some clue what happen:

-----------------------------------------------------------------
Using the user defined JAVA_HOME : /usr/local/diablo-jdk1.6.0
Entering setup...
WARNING: Warning: Could not detect OS Architecture, falling back to os.arch
[Type=UNDEFINED Name=UNDEFINED ]
WARNING: Warning : Could not detect OS Type [Type=FreeBSD ]
WARNING: Warning: Could not detect OS Name [Name=FreeBSD ]
SwixML 1.5 (#144)
// Error: Exception in runnable:Method Invocation theJava.getInstalledJDKDetails
: at Line: 98 : in file: inline evaluation of: `` import java.io.File;
import java.util.List; import java.util.ArrayList; . . . '' : theJava
.getInstalledJDKDetails ( )

Called from method: run : at Line: -1 : in file: <Called from Java Code> :
<Compiled Java Code>
Target exception: java.lang.NullPointerException

SEVERE: Internal Error: Can not continue reliably. Shutting down
Beanshell script not invokable Component=JDK_FROM_LIST_CHOICE
root@bsdserver#
---------------------------------------------------------------

In the end I was able to successfully install Glassfish from zip distribution.



 Comments   
Comment by scatari [ 02/Dec/09 ]

This platform is not supported. Please use the jar based installer.

Comment by judytangs [ 03/Dec/09 ]

I am reopening and changing this issue to FEATURE and to Version V3.1, so we can
evaluate this feature when we plan for v3.1.

I talked with FishCAT member Vladimir he filed this issue, following is what he
said about FreeBSD. Let me include it here:

"I believe the most internet providers using this OS because of very high
scalability and reliability level comparing to typical Linux system.

http://www.ibm.com/developerworks/opensource/library/os-freebsd/

"Summary: The FreeBSD operating system is the unknown giant among free
operating systems. Starting out from the 386BSD project, it is an extremely fast
UNIX®-like operating system mostly for the Intel® chip and its clones. In many
ways, FreeBSD has always been the operating system that GNU/Linux®-based
operating systems should have been. It runs on out-of-date Intel machines and
64-bit AMD chips, and it serves terabytes of files a day on some of the largest
file servers on earth."

It looks like FreeBSD quite popular among the biggest players in area of
internet service. It is definitely distinguish segment of the market. It's make
sense for Sun MicroSystem to aggressively promote Glassfish to the big market
of internet hosting services."





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

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

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

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


Attachments: JPEG File truncat_es_install.jpg     JPEG File truncat_install_it.jpg     JPEG File truncat_install_pt.jpg     JPEG File truncat_uninstall_pt.jpg     JPEG File UPDATED_ES_PACKED.jpg     JPEG File UPDATED_FR_PACKED.jpg     JPEG File UPDATED_US_PACKED_EXTREME.jpg    
Tags: 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

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

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



 Comments   
Comment by sunny-gui [ 11/Jan/11 ]

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

Comment by scatari [ 11/Jan/11 ]

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

Comment by scatari [ 17/May/11 ]

Approved for 3.1.1.

Comment by scatari [ 24/May/11 ]

Too late to fix for 3.1.1.

Comment by scatari [ 13/Oct/11 ]

To be considered for 3.1.2.

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

Assigning to Romain, fix required in Open Installer.

Comment by Romain Grécourt [ 09/Jan/12 ]

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

Comment by Romain Grécourt [ 09/Jan/12 ]

Attaching screenshots to show how it looks now.

Comment by Romain Grécourt [ 13/Jan/12 ]

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

Comment by Joe Di Pol [ 18/Jan/12 ]

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

Comment by Snjezana Sevo-Zenzerovic [ 15/Feb/13 ]

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





[GLASSFISH-15490] IIOP failover Dev Test is failing Created: 07/Jan/11  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_b37
Fix Version/s: 4.1

Type: Bug 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

Attachments: Text File orb-iiop-folb-multinode-build7.log    
Tags: 3_1-exclude, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

IIOP failover Dev Test is failing on multi node cluster, with secure admin enabled

Config 1: Single node, three instance cluster, with no secure admin: IIOP failover works fine.

Config 2: Two node, three instance cluster, with secure admin enabled: The tests fails with following exception:

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

[failOverTest] result[50]= in1
Command stop-instance for instance in1
javax.ejb.NoSuchEJBException
at orb.folb._LocationBeanRemote_Wrapper.getLocation(orb/folb/_LocationBeanRemote_Wrapper.java)
at orbfailover.Main.failOverTest(Main.java:136)
at orbfailover.Main.main(Main.java:104)
Caused by: java.rmi.NoSuchObjectException: CORBA OBJECT_NOT_EXIST 1398079490 No; nested exception is:
org.omg.CORBA.OBJECT_NOT_EXIST: ---------BEGIN server-side stack trace---------
org.omg.CORBA.OBJECT_NOT_EXIST: FINE: IOP02500002: Failed to create or locate Object Adaptor vmcid: SUN minor code: 2 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy140.noObjectAdaptor(Unknown Source)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:228)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.findObjectAdapter(CorbaServerRequestDispatcherImpl.java:361)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:192)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:220)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:496)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:537)
Caused by: org.omg.PortableServer.POAPackage.AdapterNonExistent: IDL:omg.org/PortableServer/POA/AdapterNonExistent:1.0
at com.sun.corba.ee.impl.oa.poa.POAImpl.doActivate(POAImpl.java:1115)
at com.sun.corba.ee.impl.oa.poa.POAImpl.find_POA(POAImpl.java:1048)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:224)
... 12 more

---------END server-side stack trace--------- vmcid: SUN minor code: 2 completed: No
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:269)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:213)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at orb.folb._LocationBeanRemote_Remote_DynamicStub.getLocation(orb/folb/_LocationBeanRemote_Remote_DynamicStub.java)
... 3 more
Caused by: org.omg.CORBA.OBJECT_NOT_EXIST: ---------BEGIN server-side stack trace---------
org.omg.CORBA.OBJECT_NOT_EXIST: FINE: IOP02500002: Failed to create or locate Object Adaptor vmcid: SUN minor code: 2 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy140.noObjectAdaptor(Unknown Source)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:228)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.findObjectAdapter(CorbaServerRequestDispatcherImpl.java:361)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:192)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:220)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:496)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:537)
Caused by: org.omg.PortableServer.POAPackage.AdapterNonExistent: IDL:omg.org/PortableServer/POA/AdapterNonExistent:1.0
at com.sun.corba.ee.impl.oa.poa.POAImpl.doActivate(POAImpl.java:1115)
at com.sun.corba.ee.impl.oa.poa.POAImpl.find_POA(POAImpl.java:1048)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:224)
... 12 more

---------END server-side stack trace--------- vmcid: SUN minor code: 2 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.MessageBase.getSystemException(MessageBase.java:900)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.ReplyMessage_1_2.getSystemException(ReplyMessage_1_2.java:131)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.getSystemExceptionReply(CorbaMessageMediatorImpl.java:637)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.processResponse(CorbaClientRequestDispatcherImpl.java:499)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete(CorbaClientRequestDispatcherImpl.java:373)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:243)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:200)
... 6 more
[failOverTest] FAIL

=========================



 Comments   
Comment by Harshad Vilekar [ 09/Jan/11 ]

The same test (with no changes) passed with latest nightly build.

Comment by Ken Cavanaugh [ 10/Jan/11 ]

As this is now passing, I'm closing this issue. I suspect there was a problem
with EJB deployment on a cluster in secure admin mode, which would result in
the observed exception.

Comment by Harshad Vilekar [ 18/Jan/11 ]

Reopening the issue, since the exception is seen intermittently with nightly hudson runs.

1. The pattern is:

  • The FailOver test fails when the instance - running on the remote node - is stopped.
  • The FailOver test works fine, when the instance - running on the same node as DAS node - is stopped.

2. The cluster state is looking fine:

$asadmin list-instances --long c1
NAME HOST PORT PID CLUSTER STATE
in2 localhost 8363 6738 c1 running
in1 intg2t1000 8107 3474 c1 running
in3 localhost 8619 6630 c1 running
Command list-instances executed successfully.

3. OrbFailOver-ejb is deployed on the cluster, and looks fine:
------------------
$ asadmin list-applications c1
OrbFailOver-ejb <ejb>
------------------

Comment by Ken Cavanaugh [ 18/Jan/11 ]

Moving to next release: not a release blocker for 3.1.

Comment by Tom Mueller [ 07/Feb/13 ]

Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.





[GLASSFISH-15429] Modifying keyfile path in a newly created config does not properly list the users Created: 04/Jan/11  Updated: 16/Nov/11

Status: Reopened
Project: glassfish
Component/s: security
Affects Version/s: 3.1_ms07
Fix Version/s: future release

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

Issue Links:
Dependency
blocks GLASSFISH-15406 Unable to edit custom admin-realm in ... Closed
Tags: 3_1-exclude, 3_1-next, 3_1-release-note-added, 3_1-release-notes, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

1. asadmin copy-config default-config new-config
2. asadmin get new-config.security-service.auth-realm.admin-realm.property.file
new-config.security-service.auth-realm.admin-realm.property.file=$

{com.sun.aas.instanceRoot}

/config/admin-keyfile
3. asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
Command set executed successfully.
4. file /tmp/v3/admin-keyfile is not currently created.
5. asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.
6. cat /tmp/v3/admin-keyfile
test;

{SSHA256}mjyhJFWxU8xUnGMY5bt+ngwj3tf6v6yOTKB7DgGKJUu6Neky/GVOsQ==;asadmin
user1;{SSHA256}

rImtlHJuqi6AMSypIUyBdcs2CUEPQq3pIEHSEsndYQmhBl4ZBT+fJA==;user1
<user test is properly added to admin-keyfile under /tmp/v3 as expected.>
8. asadmin list-file-users --authrealmname admin-realm new-config
user1
Command list-file-users executed successfully.
<Expected is test,user1 but it lists user1 which it takes from $

{instance_root}

/domains/domain1/config/keyfile but it should list from /tmp/v3/admin-keyfile>

The list-file-users needs to be fixed to list from /tmp/v3/admin-keyfile



 Comments   
Comment by kumarjayanti [ 04/Jan/11 ]

Srini,

Either there is no bug or you have not given me the complete set of steps. With the steps that you provided it is not clear how the user :"user1" is already present in the /tmp/v3/admin-keyfile.

Also are you using the latest builds. Here are the steps that i executed and i see no problems

1.)

$ ./asadmin start-domain
Waiting for domain1 to start ..........
Successfully started the domain : domain1
domain Location: /Users/vbkumarjayanti/Documents/workspace/glassfish/glassfish3/glassfish/domains/domain1
Log File: /Users/vbkumarjayanti/Documents/workspace/glassfish/glassfish3/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.

2.)
$ ./asadmin copy-config default-config new-config

Command copy-config executed successfully.

3)
$ ./asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
Command set executed successfully.

4)
$ mkdir /tmp/v3
$ > /tmp/v3/admin-keyfile

5)
$ ./asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.

6)
$ cat /tmp/v3/admin-keyfile
test;

{SSHA256}

H0J8mMtMJp1BcPynsBqyDw8r0WWI30796BaFrsdmei3eBh3YDILKKg==;asadmin

7)
$ ./asadmin list-file-users --authrealmname admin-realm new-config
test
Command list-file-users executed successfully.

8)
$ ./asadmin create-file-user --authrealmname admin-realm --target new-config user1
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.

9)
$ ./asadmin list-file-users --authrealmname admin-realm new-config
test
user1
Command list-file-users executed successfully.

Comment by kumarjayanti [ 04/Jan/11 ]

Cannot reproduce. Make sure you are using the very latest glassfish build. And please provide the exact steps to reproduce.

I will try some other combination in the meantime to see if i can reproduce anything like what u mention.

Comment by srinik76 [ 04/Jan/11 ]

I have not created the file. As per the requirement do we need to create the file.

If not created we see this problem.

Comment by kumarjayanti [ 04/Jan/11 ]

The Keyfile needs to be created physically and ideally this should be done before even the set command is executed to change the keyfile property.

That said, if the keyfile is not created then when i test purely from CLI i do not get the problem you see. I see the create-file-user fails.

Comment by Anissa Lam [ 04/Jan/11 ]

It is the responsibility of the user to create the keyfile ( I hope the documentation specifies that) or the security code should be smart enough to detect that the keyfile doesn't exist and create that for the user.
GUI should NOT create the keyfile.

As commented in GLASSFISH-15406, there is error given if the keyfile doesn't exist.
$ ./asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
remote failure: Adding User test to file realm admin-realm failed.
Command create-file-user failed.

GUI should show the error to the user.
However, there is no reason given to the user WHY the creation failed. It should tell user that the keyfile doesn't exist. Thus I am re-opening this bug but downgrading it. The error message needs to be clear.

Comment by srinik76 [ 04/Jan/11 ]

Tested with the latest build, create-file-user fails with following message

asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
remote failure: Adding User test to file realm admin-realm failed. /tmp/v3/admin-keyfile (No such file or directory)
/tmp/v3/admin-keyfile (No such file or directory)

list-file-users also should report that /tmp/v3/admin-keyfile is not found, but it lists the user (admin)

asadmin list-file-users --authrealmname admin-realm new-config
admin
Command list-file-users executed successfully.

Comment by kumarjayanti [ 05/Jan/11 ]

Anissa Said :
----------

GUI should show the error to the user.
However, there is no reason given to the user WHY the creation failed. It should tell user that the keyfile doesn't exist. Thus I am re-opening this bug but downgrading it. The error message needs to be clear.

--------

I checked the code and the CLI command tried to do the following :
report.setMessage(
localStrings.getLocalString("create.file.user.useraddfailed",
"Adding User

{0}

to the file realm

{1}

failed",
userName, authRealmName) + " " + localalizedErrorMsg);
report.setActionExitCode(ActionReport.ExitCode.FAILURE);
report.setFailureCause(e);

It appears when the Message is set it takes priority over setFailureCause in the admin framework. I can remove the setMessage for the next release. Or if you think it is important for you since this message has to be displayed in the GUI then please reopen the bug and i will ask for approval.

I see a similar problem with list-file-users as well where it sets all the 3 items on the report object and hence the message that was set takes priority and that message is currently not very good.

I can fix both of them as part of this. The question is would you like messages fixed for V3.1.

Comment by srinik76 [ 05/Jan/11 ]

Reopening issue after discussing with kumar.

Now from the security side it will check for the keyfile existence while listing file users.

Comment by kumarjayanti [ 05/Jan/11 ]

1) How bad is its impact? (Severity)
While we are unable to reproduce it by pure CLI operations it appears GUI seems to observe some incorrect file-user listing in this case. Also the message log for the Failure can be improved to indicate the real cause.

2) How often does it happen? (Frequency)
This will occur only when keyfile of a file-realm points to a non-existent File.

3) How much effort is required to fix it? (Cost)
Minor : the fix is to add a check for non-existent keyfile and throw an error.

4) What is the risk of fixing it? (Risk)

None (does not affect the Runtime). GUI wants these enhancements.

Comment by Anissa Lam [ 05/Jan/11 ]

Approved.

Comment by kumarjayanti [ 05/Jan/11 ]

fixed

Comment by srinik76 [ 05/Jan/11 ]

Fix works fine, but when the key file is created

list-file-users should report none, but lists admin user.

Waiting for comments from kumar to reopen the issue.

Comment by srinik76 [ 06/Jan/11 ]

After changing the key file and restarting the server, it works fine.

Comment by srinik76 [ 06/Jan/11 ]

Comments from Kumar in email

Hi Srini, Anissa,

I think i understand what is happening.

1. default-config is copied as new-config
2. Now the admin-realm is selected in the GUI from this new-config
3. Its KeyFile property is changed to some XYZ and the change is saved. Using an asadmin set-command
4. A physical XYZ file is created
5. Now again ManageUsers is clicked on the admin-realm of new-config
5.1. At this time ListFileUsers command still shows the original admin user that is part of the admin-realm in default-config

Is this a correct description of the issue ?. If that is true then yes that can happen.

1. Step 2 loads the admin-realm in the Backend.
2. Setp 3 modifies the property of the realm in the Config-Layer
3. Backend is not informed of this change. And since the new-config is not the running config of the Server (DAS) the ConfigListener Mechanism (which is in place) does not come into picture. So the backend realm is never updated.
4. ListFileUsers command which executes as part of step (5) above does a refresh of the keyfile contents but it never goes back to the config-layer to see if the keyfile has changed. And it does not make sense for ListFileUsers to do that (checking for changes to the realm definition in config-layer). Things would have worked if it did that but really the syncing between Config-Layer and Backend should have happened when step (3) above invoked the "asadmin set" command to modify the keyfile property.

There are 4 solutions :

1. I can provide a new hidden command which has to be executed by GUI whenever they do a asadmin set on any realm (and file-realm in particular). This command would then try to sync the Config change made by the set to the backend. For some realms this inplace update cannot be performed for-example

  • if it is an LDAPRealm of the active server config and there are applications currently using that realm and the set command tries to modify the URL of the LDAP server or the base-dn of the LDAPRealm. Such changes will require a RESTART of the Application Server.

2. Fix ListFileUsers to re-read the config-layer. Not a good idea and not the right fix.

3. GUI can indicate after the set-command that Appserver should be restarted.

4. GUI should not use an asadmin set to modify the keyfile location. Instead it should delete the existing Realm and create a New Realm with modified properties.

Let me know which approach would be best for V3.1.

regards,
kumar

Waiting for Anissa's comments to decide what approach (1 out of 4 suggested by kumar) to be taken for the solution.
Anissa/Kumar, Can I reopen the bug?

Comment by kumarjayanti [ 06/Jan/11 ]

I am also not sure if a Property change in realm (using asadmin set) in an active server config will cause the Config Change Event which can be received by a registered ConfigListener.

Comment by Anissa Lam [ 06/Jan/11 ]

As i understand it, only GUI user sees this problem. CLI user will not have such an issue. Correct me if i am wrong. But i just tried using CLI to do all the steps and list-file-user reports the correct list.
So, what exactly is missing in GUI code, compared to CLI, that causes this error in GUI only ? I want to understand this, and that maybe how we should fix it.

The corresponding steps in CLI works perfectly fine, and list-file-user is reporting the list of users from the new key file correctly.

~ 1) asadmin copy-config default-config TEST-config
Command copy-config executed successfully.
~ 2)
~ 2) asadmin list-file-users --authrealmname admin-realm server-config
admin
Command list-file-users executed successfully.
~ 3)
~ 3)
~ 3) asadmin get configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file
configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file=$

{com.sun.aas.instanceRoot}

/config/admin-keyfile
Command get executed successfully.
~ 4)
~ 4) asadmin set configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file=/tmp/keyFile
configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file=/tmp/keyFile
Command set executed successfully.
~ 5)
~ 5)
~ 5) touch /tmp/keyFile
~ 6)
~ 6) asadmin list-file-users --authrealmname admin-realm TEST-config
Command list-file-users executed successfully.
~ 7)
~ 7)

Comment by Anissa Lam [ 06/Jan/11 ]

Re-open issue as this is still under active discussion and GUI depends on the fix.

Comment by kumarjayanti [ 06/Jan/11 ]

Your step two :
~ 2) asadmin list-file-users --authrealmname admin-realm server-config

should be changed to

2) asadmin list-file-users --authrealmname admin-realm TEST-config

and IMO that will reproduce the problem in CLI

Comment by kumarjayanti [ 06/Jan/11 ]

I retested after implementing solution 1. Here is the output :

$ ./asadmin start-domain
Waiting for domain1 to start ..........
Successfully started the domain : domain1
domain Location: /Users/vbkumarjayanti/Downloads/glassfish3/glassfish/domains/domain1
Log File: /Users/vbkumarjayanti/Downloads/glassfish3/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.

$ ./asadmin copy-config default-config new-config
Command copy-config executed successfully.

$ ./asadmin list-file-users --authrealmname admin-realm new-config
admin
Command list-file-users executed successfully.

$ ./asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/mykeyfile
new-config.security-service.auth-realm.admin-realm.property.file=/tmp/mykeyfile
Command set executed successfully.

$ ./asadmin __synchronize-realm-from-config --realmname admin-realm new-config
Synchronization of Realm admin-realm from Configuration Successful.
Command __synchronize-realm-from-config executed successfully.

$ ./asadmin list-file-users --authrealmname admin-realm new-config
Command list-file-users executed successfully.

$ cat /tmp/mykeyfile

$ ./asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.

$ ./asadmin list-file-users --authrealmname admin-realm new-config
test
Command list-file-users executed successfully.

Comment by kumarjayanti [ 06/Jan/11 ]

The new hidden command will set RESTART required if the change was done to an active server config

$ ./asadmin set server-config.security-service.auth-realm.file.property.file=/tmp/mykeyfile
server-config.security-service.auth-realm.file.property.file=/tmp/mykeyfile
Command set executed successfully.

$ ./asadmin __synchronize-realm-from-config --realmname file server-config
Restart required for configuration updates to active server realm: file.
Command __synchronize-realm-from-config executed successfully.

And here is how the code in the command sets the information required for GUI for a restart. I picked up this code from :

core/kernel/src/main/java/com/sun/enterprise/v3/admin/GetRestartRequiredCommand.java

private void setRestartRequired(ActionReport report) {
report.setActionExitCode(ActionReport.ExitCode.SUCCESS);
ActionReport.MessagePart mp = report.getTopMessagePart();

Properties extraProperties = new Properties();
Map<String, Object> entity = new HashMap<String, Object>();
mp.setMessage(_localStrings.getLocalString("RESTART_REQUIRED",
"Restart required for configuration updates to active server realm:

{0}

.",
new Object[]

{realmName}

));
entity.put("restartRequired","true");
extraProperties.put("entity", entity);
((ActionReport) report).setExtraProperties(extraProperties);
}

Comment by kumarjayanti [ 06/Jan/11 ]

checked in the Partial Fix which will make the GUI work.

GUI has to invoke the new hidden command whenever an asadmin set is invoked on any realm.

The CLI this bug still remains if someone does the following sequence of operations :

1. asadmin copy-config default-config new-config
2. asadmin list-file-users --authrealmname admin-realm new-config
admin
Command list-file-users executed successfully.
3. asadmin get new-config.security-service.auth-realm.admin-realm.property.file
new-config.security-service.auth-realm.admin-realm.property.file=$

{com.sun.aas.instanceRoot}

/config/admin-keyfile
4. asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
Command set executed successfully.
5. create the physical keyfile at /tmp/v3/admin-keyfile

After doing these steps, the following command will give a wrong answer :

1. asadmin list-file-users --authrealmname admin-realm new-config
admin
Command list-file-users executed successfully.

This is because the asadmin set command in step-4 above updates the Configuration Layer but does not update the Backend Realm which was loaded while executing step 2. So the list command will continue to list the user admin which was present in the original realm's keyfile (one that it was referring to before the set command changed it).

Summary of the CLI Bug : If an asadmin set command is executed to change a realm-property for a realm that was loaded by the backend (due to an earlier CLI command targeted at the realm) , then the realm continues to behave as if the set command was not executed. The workaround is to restart Appserver after a set command has been used to change a property of an already loaded realm.

Comment by Scott Fordin [ 15/Apr/11 ]

Issue added to 3.1 Release Notes.





[GLASSFISH-15424] [BigApps] [STRESS] ~17 occurences of "EOFException" warnings coming from JMS Created: 03/Jan/11  Updated: 19/Sep/14  Due: 18/Jan/11

Status: Reopened
Project: glassfish
Component/s: jms
Affects Version/s: 3.1_b34
Fix Version/s: 4.1

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

Attachments: Text File eof-issue.log     File server.log-instance101-24x1-gf-b37    
Issue Links:
Dependency
blocks GLASSFISH-15423 [STRESS] [BigApps] [Umbrella-Issue] 2... Closed
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes, 3_1_1-scrubbed, 3_1_2-exclude, 3_1_2-release-note-added, 3_1_2-release-notes

 Description   

See parent issue 15423 for details of the BigApps run that causes this issue to appear in the server logs. A server log that shows the issue has been attached.



 Comments   
Comment by Satish Kumar [ 04/Jan/11 ]

This is a bug in MQ. See http://java.net/jira/browse/MQ-72 for the corresponding MQ issue. Amy Kang is currently working on it and based on her feedback, a fix for this issue will be a part of the next MQ integration ...

Comment by varunrupela [ 04/Jan/11 ]

Satish,

This is a different issue from the MQ-72 issue. The log is attached to the issue. We need to check on the cause for the log.

Comment by Satish Kumar [ 04/Jan/11 ]

As I had mentioned in my earlier comment, I suspect this issue may be caused due to http://java.net/jira/browse/MQ-72.

Lowering the priority of this issue to Minor as discussed with Varun. We will need to have a re-look at this once MQ-72 is fixed and then decide if any further action is required here or if we can close this issue.

Comment by Satish Kumar [ 05/Jan/11 ]

Bumping-up the priority to Major based on Nazrul's feedback.

We plan to leave this issue open until the fix for MQ 72 has been integrated and the stress tests have been run again and observe if the exceptions are reappearing in the new test run.

Comment by Nazrul [ 10/Jan/11 ]

Please confirm if MQ-72 resolved this problem.

Comment by varunrupela [ 12/Jan/11 ]

The issue continues to exist in build 37.

Comment by varunrupela [ 13/Jan/11 ]

Added one of the instance's server log after a 24x1 run of the same scenario.

Comment by Satish Kumar [ 13/Jan/11 ]

Assigning this issue to Nigel as per our discussion this evening...

Comment by Nigel Deakin [ 14/Jan/11 ]

These messages

[#|2011-01-13T11:14:06.600+0530|WARNING|glassfish3.1|javax.jms|_ThreadID=29;_ThreadName=Thread-1;|[I500]: Caught JVM Exception: java.io.EOFException: Trying to read 72 bytes. Already read 0 bytes.|#]

are warning messages. No errors or other messages were seen and there are no reports of the application behaving unexpectedly other than these messages.

Other users have reported receiving these messages periodically in earlier versions of MQ. There is a discussion here:
http://markmail.org/message/hh2ejjuxp5mo6njp#query:+page:1+mid:rumu3mg7unqbgm25+state:results
to which MQ team members responded.

This warning message is logged by the MQ client thread that is reading messages from a socket connected to the broker. (Note that even though the broker is embedded, since the broker is clustered, the client uses TCP to connect to the broker). The exception suggests that the client had received a "zero-length packet" from the broker. This message is often seen when the broker has failed, though this is not the case here. In that email discussion the MQ technical lead speculates that it is "probably a side effect of destination limits or TTL" and suggests that if there are no other problems the messages can be ignored.

Note that after this exception has been logged the client will attempt to recover the connection and carry on. This appears to have been the case here since no further messages were logged.

This is just a warning message, and is logged as such. Arguably GlassFish should never log warnings, but to suppress it might cause useful information to be lost if there are other problems. So it is proposed to close this bug as "not being a bug".

Comment by varunrupela [ 17/Jan/11 ]

Based on the analysis, the issue can be waived for GF 3.1. The issue should remain open as it appears in GF build 37 and as the MQ team will fix it in the long-term. It is useful to keep this issue open as opposed to creating a new one, since it contains quite some information around the bug.

Comment by Nigel Deakin [ 17/Jan/11 ]

Adding 3_1-exclude 3_1-release-notes tags. Note that this issue now only concerns the EOFExceptions and no other messages.

The release note should mention that very occasionally WARNING messages "java.io.EOFException: Trying to read 72 bytes. Already read 0 bytes" may be observed in the server log. If no other messages or exceptions are logged at the same time in either the server or broker logs these messages may be ignored.

Comment by varunrupela [ 18/Jan/11 ]

set the target release

Comment by easarina [ 18/Jan/11 ]

Was used b38 01/14. richAccess + SSL stress test on Win 2008 machines. Saw multiple "java.io.EOFException: Trying to read 72 bytes. Already read 0 bytes" warnings in server.log files. Was used jdk 1.6.0_23, 64 bit.

Comment by Nigel Deakin [ 19/Jan/11 ]

Updated summary to make it clear that it relates to warning messages, not exceptions.

Comment by Scott Fordin [ 23/Mar/11 ]

Need more info to add issue to 3.1 Release Notes. Is a release note still necessary?

Comment by Nigel Deakin [ 25/Mar/11 ]

Please add the following text (which I gave in my comment on 17 Jan) to the release note:

Issue 15424: Very occasionally WARNING messages "java.io.EOFException: Trying to read 72 bytes. Already read 0 bytes" may be observed in the server log. If no other messages or exceptions are logged at the same time in either the server or broker logs these messages may be ignored.

Nigel

Comment by Scott Fordin [ 15/Apr/11 ]

Added issue to 3.1 Release Notes.

Comment by Nigel Deakin [ 14/Dec/11 ]

Excluding from 3.1.2 for the same reason it was excluded from 3.1.1. It should continue to be mentioned in the release note.

Comment by Rebecca Parks [ 24/Jan/12 ]

If it's in the 3.1.1 Release Notes, it's carried over to 3.1.2 unless it's fixed in 3.1.2. There's no need to flag it for 3.1.2.

Comment by Nigel Deakin [ 15/Feb/13 ]

In accordance with the project triage guidelines this is not needed for 4.0 and so has been deferred until 4.0.1. Setting "fix version" accordingly.





[GLASSFISH-15651] Unable to install lb-plugin using lbconfigurator on Windows 2008 & iWS 7. Created: 21/Jan/11  Updated: 21/Oct/11

Status: Reopened
Project: glassfish
Component/s: load_balancer
Affects Version/s: None
Fix Version/s: None

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

Windows 2008, iWS 7 web server.


Tags: 3_1, 3_1-exclude, 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude, glassfish

 Description   

LB configurator fails with this exception on the next screen after collecting web server information.

$ java -jar glassfish-lbconfigurator-3_1-b04.jar
Condition already registered.
Condition already registered.
Condition already registered.
Condition already registered.
Condition already registered.
Condition already registered.
Condition already registered.
java.io.FileNotFoundException: C:\Program Files (x86)\LBPlugin\Uninstaller\unins
taller.jar (The system cannot find the path specified)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
at java.io.FileOutputStream.<init>(FileOutputStream.java:70)
at com.izforge.izpack.installer.UnpackerBase.putUninstaller(Unknown Sour
ce)
at com.izforge.izpack.installer.Unpacker.run(Unknown Source)
at java.lang.Thread.run(Thread.java:662)

I checked and the specified file does not exist. But I guess the installer should create it.

C:\Program Files (x86)>dir
Volume in drive C has no label.
Volume Serial Number is F46D-A90A

Directory of C:\Program Files (x86)

01/21/2011 11:07 AM <DIR> .
01/21/2011 11:07 AM <DIR> ..
01/21/2011 11:08 AM <DIR> Common Files
01/11/2011 10:12 PM <DIR> Internet Explorer
01/21/2011 11:07 AM <DIR> Java
01/12/2011 08:53 AM <DIR> Mozilla Firefox
01/12/2011 08:48 AM <DIR> Symantec AntiVirus
01/12/2011 03:15 AM <DIR> Windows Mail
07/13/2009 09:37 PM <DIR> Windows NT
0 File(s) 0 bytes
9 Dir(s) 87,917,252,608 bytes free



 Comments   
Comment by Homer Yau [ 04/Feb/11 ]

We may need to release note that the user who install load-balancer Configurator need to have full system installation right. "Administrator" usually should have the right to create directory in the restricted path.

Comment by Scott Fordin [ 03/Mar/11 ]

Instructions added to HA Admin Guide.

Comment by Scott Fordin [ 24/Mar/11 ]

Information was added to HA Admin Guide, but as this was not a doc issue, I should not have closed it.

Comment by Nazrul [ 09/May/11 ]

Windows 2008 is useful to support.

Comment by scatari [ 10/Jun/11 ]

Fix already documented and it is well known that most installations on Windows require Admin privileges.

Comment by kshitiz_saxena [ 08/Jul/11 ]

Changing priority to Major





[GLASSFISH-15637] IIOP Loadbalancing not happening Created: 20/Jan/11  Updated: 13/Feb/13  Due: 01/Feb/11

Status: Reopened
Project: glassfish
Component/s: rmi_iiop_load_balancer
Affects Version/s: 3.1_b38
Fix Version/s: future release

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

Attachments: File patch.tgz    
Tags: 3_1-exclude, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

IIOP Loadbalancing not happening with certain apps

The Initial context is created as follows

public void createContextForACC()
{
try

{ InitialContext initial = new InitialContext(); myEnv = (InitialContext)initial.lookup("java:comp/env/ejb"); }

catch(NamingException ne)

{ System.err.println("Caught an unexpected exception!"); ne.printStackTrace(); }

}

All new ic creations are going to same instance



 Comments   
Comment by Ken Cavanaugh [ 21/Jan/11 ]

I don't understand what is failing here. Is this an issue about some of the failover
tests? Which ones?

Or is it an issue about how the InitialContext is created?

I also have no idea what a lookup of java:comp/env/ejb is supposed to do.
This is not part of IIOP or FOLB.

Please clarify or close this issue.

Comment by gopaljorapur [ 21/Jan/11 ]

The loadbalancing is not happening, all new ic creations happen on one random instance in the cluster

Comment by Ken Cavanaugh [ 25/Jan/11 ]

This issue does not currently correctly describe the observed problem.
I THINK (from email and conversation with Gopal) that the problem is
that loadbalancing does not happen when the endpoints property is specified
in the app client command, but DOES happen when the endpoints property
is passed to the (first) new InitialContext call.

I will investigate that question in my testing shortly.

Comment by Ken Cavanaugh [ 26/Jan/11 ]

My test (same as the 14867 existing instance case) works with -Dcom.sun.appserver.iiop.endpoints specified,
but fails with appclient -targetserver. I've sent email to Tim to see if this is a configuration error in
my code, or an error in the ACC argument parsing.

Comment by Ken Cavanaugh [ 30/Jan/11 ]

This patch contains two fixes:

1. The sticky context reference count has been fixed to avoid extra increments, which
creates a "stuck" condition in which the same SerialContext underlying the InitialContext
call is used all the time. This fix is in glassfish-naming.

2. I added code to the ORB to detect and specially label name service implementations.
The FOLB server group manager then arranges to always send a membership label
update on the reply to any name server invocation. This means that the
lookup call on the new InitialContext will get any updates to the cluster shape.
This in turn prevents the situation where the client is always obtaining up-to-date
references from naming, but the new InitialContext call is not informed of the changes
(which happens only the the ClientGroupManager receives a response contains an
updated IOR for a membership label change).

Just unpatch the patch into the modules directory as usual.

Comment by Ken Cavanaugh [ 31/Jan/11 ]

How bad is its impact? (Severity)
Regression in IIOP FOLB from GF 2.1.

How often does it happen? (Frequency)
Happens all the time in the following test scenario (which should have
been added earlier to this issue):

0. Start with com.sun.appserv.iiop.endpoints referring to two elements, the one to start in step 2
and another in the cluster.
1. Stop the cluster.
2. Start 1 instance (inst) in the cluster.
3. LB to one instance
4. Start cluster
5. Kill inst
6. LB test

This fails because LB happens to only one instance.

How much effort is required to fix it?
I have the fixes made, and the IIOP FOLB dev test passes.
Fixes are in the ORB (new support for labelling object implementations as being in a name service)
and in glassfish-naming (Fixes in how endpoint lists are merged in RoundRobinPolicy,
and fixes in sticky context reference counting in SerialContext)

What is the risk of fixing it? (Risk)
Low. We have good test coverage for all areas. The only likely impact is on IIOP FOLB.
Other functions of the ORB are unaffected by these changes.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
I don't think a reasonable workaround exists.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
N/A

How long has the bug existed in the product?
Since the beginning of GF 3.1 FOLB development (roughly 6 months)

Do regression tests exist for this issue?
Yes: IIOP FOLB dev test test15736.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
The various tests that were failing that caused this issue to be filed (Gopal has the tests).

When will a tested fix be ready for integration?
Probably 1/31/11-2/1/11.

Comment by gopaljorapur [ 31/Jan/11 ]

he issue in 15637 is about IIOP Loadbalancing not happening , Scenario is as follows (I will update the issue with this scenario)

1. Start Cluster with 5 instances
2. Create 12 InitialContext in a loop, create SFSB reference by looking ejb
3. grep for "SFSB Bean!" in server.log of all instances, you will see 12 of them in only one instance (incorrect behavior, load should be loadbalanced across cluster)

The test code is as follows

/// When we run appclient, we provide test id as RMIIIOPFOTC4, this creates 12 ic and 12 sfsb remote ref

if(testid.equals("RMIIIOPFOTC4"))
{
for(int i=0;i<12;i++)

{ client.createContextForACC(); client.createSFSBRemoteRef(); }

System.out.println("Test Passed");
}

//// Here is how ic is created

public void createContextForACC()
{
try

{ Context initial = new InitialContext(); myEnv = (Context)initial.lookup("java:comp/env/ejb"); }

catch(NamingException ne)

{ System.err.println("Caught an unexpected exception!"); ne.printStackTrace(); }

}

///// Here is how sfsb remote ref is
public void createSFSBRemoteRef()
{
try

{ Object sfsbobjref = myEnv.lookup("TestSFSB"); sfsbhomeref = (SFSBRemoteHomeRef)PortableRemoteObject.narrow(sfsbobjref, SFSBRemoteHomeRef.class); sfsbref = sfsbhomeref.create("SFSB Bean!"); System.out.println(sfsbref.validate()); }
catch(Exception exc)
{ exc.printStackTrace(); }
}




*******************************************************************************************************************************************************

The scenario that works:

The variation of the test, RMIIOPFOTC4A

1. Start Cluster with 5 instances
2. Create 12 InitialContext with endpoint properties in the argument in a loop, create SFSB reference by looking ejb
3. grep for "SFSB Bean!" in server.log of all instances, you will see load distributed across all instances in the cluster (correct behavior)

Test code is as follows


/// When we run appclient, we provide test id as RMIIIOPFOTC4A, this creates 12 ic and 12 sfsb remote ref
if(testid.equals("RMIIIOPFOTC4A"))
{
for(int i=0;i<12;i++)
{ client.createContextForStandalone(); client.createSFSBRemoteRef(); }
System.out.println("Test Passed");
}

//// This is how createContextForStandalone

public void createContextForStandalone()
{
try
{ myEnv = new InitialContext(properties); }
catch(Exception exc)
{ System.err.println("Caught an unexpected exception!"); exc.printStackTrace(); }
}



///// This is how createSFSBRemoteRef is done ( its same as scenario when test fails)

public void createSFSBRemoteRef()
{
try
{ Object sfsbobjref = myEnv.lookup("TestSFSB"); sfsbhomeref = (SFSBRemoteHomeRef)PortableRemoteObject.narrow(sfsbobjref, SFSBRemoteHomeRef.class); sfsbref = sfsbhomeref.create("SFSB Bean!"); System.out.println(sfsbref.validate()); }

catch(Exception exc)

{ exc.printStackTrace(); }

}

Here is how to deploy
asadmin --user admin deploy --retrieve /export/DecCVS/agentrepo//appclient --availabilityenabled=true --target st-cluster --force=true RMIIIOPFailover.ear

appclient execution
/export/DecCVS/glassfish3/glassfish/bin/appclient -Dcom.sun.appserv.iiop.endpoints=hat2k1.us.oracle.com:23700,hat2k1.us.oracle.com:23701,hat2k2.us.oracle.com:23700,hat2k2.us.oracle.com:23701,hat2k2.us.oracle.com:23702 -client /export/DecCVS/agentrepo/appclient/RMIIIOPFailoverClient/rmi-iiop-client2Client.jar -mainclass samples.rmiiiopclient.client.ACC_Standalone_Client

Comment by Chris Kasso [ 31/Jan/11 ]

Approved for RC2.

Comment by Ken Cavanaugh [ 31/Jan/11 ]

At this point, for tracking purposes, 15637 is for the scenario I outlined above:

0. Start with com.sun.appserv.iiop.endpoints referring to two elements, the one to start in step 2
and another in the cluster.
1. Stop the cluster.
2. Start 1 instance (inst) in the cluster.
3. LB to one instance
4. Start cluster
5. Kill inst
6. LB test (which should show LB across running instances)

It's TOO LATE to change the test scenario for 15637, especially since you did not include a sufficient
description initially. I have clearly identified some defects here that need to be fixed,
so please file a NEW issue for the scenarios you have identified above. Please also indicate in any
new issues whether or not stateful vs. stateless EJBs make any difference. This does not matter
to the ORB at all, but some of your tests seem to indicate failures on the SFSB side only.
If this matters, I'll also need to add SFSB support to the dev tests.

Comment by gopaljorapur [ 31/Jan/11 ]

I have opened an issue 15768 for the Loadbalancing issue mentioned in my earlier comment

Comment by Ken Cavanaugh [ 31/Jan/11 ]

Fixed in GF rev 44807.
This includes integration of ORB version 3.1.0-b025.

Comment by gopaljorapur [ 17/Feb/11 ]

With old styled apps, this issue is not fixed

Comment by Ken Cavanaugh [ 17/Feb/11 ]

I was certain I fixed this, but I'll test it again, and target it for
3.2.





[GLASSFISH-263] Use a properties file for persistence provider specific properties Created: 15/Feb/06  Updated: 07/Mar/12

Status: Reopened
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: future release

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

Operating System: All
Platform: All


Issuezilla Id: 263

 Description   

Have a property file which look like this:
<provider-class-name1>.<provider-property-A>=<valueA>
<provider-class-name1>.<provider-property-B>=<valueB>
<provider-class-name2>.<provider-property-C>=<valueC>
<provider-class-name2>.<provider-property-D>=<valueD>

This can be loaded in PersistenceUnitLoaderImpl and then we can just pass the
properties specific to a provider in the map paremeter of
createContainerEntityManagerFactory().

Thanks,
Sahoo



 Comments   
Comment by djclarke [ 29/Sep/06 ]

I am unsure of the value of this enhancement. Currently the persistence.xml
provides properties where vendor specific details can be provided. Going forward
as more advanced extensions are supported additional implementation specific
files will be required. I don't see the need to add in yet another file.

If there is some concrete usecases that would warrant this additional file
please provide them and re-open.

Comment by Mitesh Meswani [ 29/Sep/06 ]

This enhancement was filled as a reminder to generalize handling of various
persistence provider in Glassfish. Reopening.
Please note that this is not an issue with Toplink

Comment by Sanjeeb Sahoo [ 07/Mar/12 ]

Assigning to jpa team for taking due action





[GLASSFISH-4629] [UB]Some wrong MDB warnings at startup when attribute value is 0 Created: 06/Apr/08  Updated: 15/Mar/13

Status: Reopened
Project: glassfish
Component/s: docs
Affects Version/s: 4.0
Fix Version/s: 4.0

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

Operating System: Windows XP
Platform: PC


Issuezilla Id: 4,629

 Description   

There were a couple of observed WARNING messages during cluster startup when
some of the EJB attribute settings were 0:

For example,

error 3
[#|2008-03-27T13:32:19.175+1100|WARNING|sun-appserver9.1|javax.enterprise.system.container.ejb.mdb|_ThreadID=10;_ThreadName=main;ejbtuning_server:MDB;0;max-pool-size;1;_RequestID=6dc41603-cc8f-44d9-85d5-75abf1fc7963;|MDB00060:
[ejbtuning_server:MDB]: Invalid value [0] for [max-pool-size] , use [1] instead|#]

...

error 3
[#|2008-03-27T15:55:07.433+1100|WARNING|sun-appserver9.1|javax.enterprise.system.container.ejb.mdb|_ThreadID=10;_ThreadName=main;ejbtuning_server:MDB;0;idle-timeout-in-seconds;1;_RequestID=6dd3f8e6-6a6d-4945-b61c-c2f2b9b17f27;|MDB00060:
[ejbtuning_server:MDB]: Invalid value [0] for [idle-timeout-in-seconds] , use
[1] instead|#]

...

It seems to me that there may be a bug in the code for
MessageBeanContainer.validateValue method because the validation code is not
accounting for the fact that 0 has a special meaning for some of the MDB
attributes (accounting to the administration manual)



 Comments   
Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by ksak [ 28/Jan/09 ]

Reassigning bugs from Mahesh

Comment by Cheng Fang [ 03/Jun/11 ]

This issue exists in 3.x too.

With <mdb-container idle-timeout-in-seconds="0">

there is this warning in server.log when running mdb tests:

[#|2011-06-03T14:47:05.425-0400|WARNING|glassfish3.2|javax.enterprise.system.container.ejb.mdb.com.sun.ejb.containers|_ThreadID=14;_ThreadName=Thread-1;|MDB00060: [ejb-ejb30-hello-mdbApp:MessageBean]: Invalid value [0] for [idle-timeout-in-seconds] , use [600] instead|#]

According to dev guide:

Idle Timeout
Specifies the maximum time in seconds that a bean can remain idle in the pool. After this
amount of time, the bean is destroyed. The default is 600 (10 minutes). A value of 0 means a
bean can remain idle indefinitely.

Comment by Nigel Deakin [ 27/Jun/11 ]

This constraint is enforced in two places, both of which need to be changed to allow a value of 0.

com.sun.ejb.containers.MessageBeanContainer (part of the EJB container in GlassFish)

com.sun.messaging.jms.ra.ActivationSpec (part of JMSRA which is part of MQ)
MQ bug MQ-103 has been opened to cover this second change.

Comment by marina vatkina [ 27/Jun/11 ]

One more note from the email discussion, that will need to go into the docs when 0 is fixed: (Nigel adds: make clear that this applies only when JMSRA is used)

If endpointPoolMaxSize < max-pool-size then the maximum number of MDB instances used at any given time will be limited to endpointPoolMaxSize

If endpointPoolMaxSize > max-pool-size then JMSRA will attempt to create more MDBs than there are in the pool, and you will see lots of messages of the form:
INFO: MQJMSRA_MR1101: createEndpoint-UnavailableException:Sleeping for:1000

So generally, users should set endpointPoolMaxSize only (or set both to the same value) since settings them to different values either has no effect or generated errors.

Comment by Nigel Deakin [ 28/Jun/11 ]

MQ bug MQ-103 has been resolved in MQ 4.6 (which will be delivered in GlassFish 3.2).

Comment by Cheng Fang [ 17/Aug/11 ]

Fixed ejb-container MessageBeanContainer in 3.2 trunk
Committed revision 48856

Comment by Cheng Fang [ 17/Aug/11 ]

re-assign to docs team to adjust GlassFish dev guide, according to Nigel and Marina's comments above.

Comment by Rebecca Parks [ 28/Nov/11 ]

Does this apply to 3.1.2?

Comment by Paul Davies [ 20/Dec/11 ]

[UB]: Unbundled documentation

Comment by Mike Fitch [ 15/Mar/13 ]

Changed fix version to 4.0 so this issue gets picked up by OSE 4.0 release queries.

Nigel & Cheng:
Given that GL 3.2 is now 4.0 and MQ 4.6 is now 5.0, am I right in assuming that this issue is applicable to GF 4.0 (which bundles MQ 5.0)?
Thanks,
--Mike





[GLASSFISH-16616] ReadMe.UserDefinedLB needs an update for 64-bit compilation and correct gcc. This doc should perhaps be moved to GF user guides. Created: 12/May/11  Updated: 24/Jan/12

Status: Reopened
Project: glassfish
Component/s: load_balancer
Affects Version/s: 3.1.1
Fix Version/s: None

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

Solaris Sparc 10 + Apache2.2 64 bit + glassfish lb plugin 3.1.1


Issue Links:
Dependency
depends on GLASSFISH-17106 [UB]Add userdefined library informati... In Progress
Tags: 3_1_1-scrubbed, 3_1_2-exclude

 Description   

I compiled roundrobin.so file for the user-defined testsand generated the .so file with -m64 flag in gcc command and still the library could not be read.

Setup is on aroot@sf-171s-163.india.sun.com:/export/ha/64-bit/apache2.2



 Comments   
Comment by kshitiz_saxena [ 17/May/11 ]

This issue is not reproducible. I compiled roundrobin.c with below command and it works fine :
gcc -m64 -shared -fPIC -I glassfish-lbplugin/lib/install/templates roundrobin.c -o roundrobin.so

Comment by varunrupela [ 01/Jul/11 ]

Apache/LB is unable to load the user-defined policy file - roundrobin.so after it is correctly compiled with the above instructions.

The following messages appear in apache error log:
"FGRP1009: Error in loading the library /space/gf-ha/dft/controller-repository/glassfish-samples/roundrobin.so, check the library is present and has proper permissions"

******
[Fri Jul 01 15:57:35 2011] [info] LBInstance created on virtual server 10.12.171.163 ...
[Fri Jul 01 15:57:35 2011] [info] is_virtual = 1 defn_name = /export/ha/64-bit/apache2.2/conf/extra/httpd-vhosts.conf ...
[Fri Jul 01 15:57:35 2011] [warn] lb.configurator: XML_VALIDATOR_WARNING: Cookies will not be rewritten by web server. All cookie updates will be handled by application server. If you are using older version of application server, then failover will not work.
[Fri Jul 01 15:57:35 2011] [warn] lb.configurator: Preferred failover instance feature is enabled.
[Fri Jul 01 15:57:35 2011] [crit] lb.failovermanager: FGRP1009: Error in loading the library /space/gf-ha/dft/controller-repository/glassfish-samples/roundrobin.so, check the library is present and has proper permissions
[Fri Jul 01 15:57:35 2011] [warn] lb.runtime: RNTM2019: Daemon http://sf-171s-163.india.sun.com:28080 has been intialized.
[Fri Jul 01 15:57:35 2011] [warn] lb.runtime: RNTM2019: Daemon https://sf-171s-163.india.sun.com:28181 has been intialized.
[Fri Jul 01 15:57:35 2011] [warn] lb.runtime: RNTM2019: Daemon http://sf-171s-163.india.sun.com:28081 has been intialized.
[Fri Jul 01 15:57:35 2011] [warn] lb.runtime: RNTM2019: Daemon https://sf-171s-163.india.sun.com:28182 has been intialized.
[Fri Jul 01 15:57:35 2011] [warn] lb.runtime: RNTM2019: Daemon http://sf-171s-163.india.sun.com:28082 has been intialized.
[Fri Jul 01 15:57:35 2011] [warn] lb.runtime: RNTM2019: Daemon https://sf-171s-163.india.sun.com:28183 has been intialized.
[Fri Jul 01 15:57:35 2011] [warn] lb.runtime: RNTM2019: Daemon http://sf-171s-163.india.sun.com:28083 has been intialized.
[Fri Jul 01 15:57:35 2011] [warn] lb.runtime: RNTM2019: Daemon https://sf-171s-163.india.sun.com:28184 has been intialized.
[Fri Jul 01 15:57:35 2011] [notice] lb.runtime: RNTM2003:After LBDaemonManager::init()
[Fri Jul 01 15:57:35 2011] [info] This virtual server already exists in map; Hence just retrieving the pointer to LBInstance...
[Fri Jul 01 15:57:36 2011] [info] This virtual server already exists in map; Hence just retrieving the pointer to LBInstance...
[Fri Jul 01 15:57:36 2011] [error] [client 129.146.11.110] File does not exist: /export/ha/64-bit/apache2.2/htdocs/favicon.ico
[Fri Jul 01 16:03:44 2011] [info] This virtual server already exists in map; Hence just retrieving the pointer to LBInstance...
[Fri Jul 01 16:03:44 2011] [error] [client 129.146.11.110] File does not exist: /export/ha/64-bit/apache2.2/htdocs/favicon.ico
********

Comment by kshitiz_saxena [ 01/Jul/11 ]

It works with library created using given command :

gcc -m64 -shared -fPIC -I glassfish-lbplugin/lib/install/templates roundrobin.c -o roundrobin.so

OR

cc -m64 -G -xcode=pic32 -I glassfish-lbplugin/lib/install/templates roundrobin.c -o roundrobin.so

Issue was with version of gcc used. It works when compiled with following gcc :
sparc-sun-solaris2.10-gcc (GCC) 4.0.4 (gccfss)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

However it fails when compiled with following gcc :
gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

It is better to use sun studio compiler on solaris.

Docs need to be updated to reflect the same.

As of now instructions to compile of user defined library is bundled as ReadMe.UserDefinedLB along with GlassFish load-balancer plugin, making it difficult to be updated frequently. It can be probably added to GlassFish load-balancer documentation itself.

Comment by varunrupela [ 01/Jul/11 ]

Kshitiz figured out that the gcc we needed to use was sparc-sun-solaris2.10-gcc and it was available from /usr/bin/gcc. We were earlier using gcc from "/usr/sfw/bin/gcc". This issue now becomes one of updating the ReadMe for user-defined.

  • We found that the ReadMe.UserDefinedLB available under glassfish-lbplugin/lib/install/templates location also needs an update for 64 bit compilation.
Comment by varunrupela [ 01/Jul/11 ]

Updated the summary to reflect findings.

Comment by kshitiz_saxena [ 26/Jul/11 ]

Readme is actually bundled with load-balancer plugin. So to update it, a new load-balancer plugin library need to be generated. It is not possible to generate and integrate new load-balancer plugin library now.

It will be better to add this readme to documentation itself as it is easy to update and maintain it there. I will create a new documentation bug to track it.

Comment by kshitiz_saxena [ 26/Jul/11 ]

Marking this issue as being dependent on GLASSFISH-17106

Comment by Joe Di Pol [ 24/Jan/12 ]

Scrubbing from the 3.1.2 list assuming docs is fixing 17106 (which is on the 3.1.2 list)





[GLASSFISH-15856] Report server instance and application startup warnings to user Created: 04/Feb/11  Updated: 22/May/13

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

Type: Improvement Priority: Major
Reporter: lidiam Assignee: kumara
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File instance-restarted-domain.xml     Text File instance-server.log     File scrumtoys.war     Text File server.log    
Tags: 3_1-exclude

 Description   

Steps to reproduce (performed these on a fresh install):

1. Create a standalone instance and start it.
2. Stop the instance.
3. Deploy an application (e.g. the attached scrumtoys application). A warning is displayed that deployment was not replicated to the instance, which is expected.
4. Start instance.
5. Go to the deployed application page and click Launch button - issue: 404 error is displayed. There are no errors in the server.log (see attached). I'm also attaching domain.xml at this point (named instance-restarted-domain.xml). When you view the targets, in Admin GUI, for this application the instance is listed as enabled.

I tried the same scenario with clusterjsp.ear application and it worked fine, so not sure why scrumtoys does not work. Please note, that this is the first time deployment, so no errors are expected for this application during deployment - it should work just fine. Also, scrumtoys is one of the sample applications shipped with SDK.



 Comments   
Comment by Anissa Lam [ 04/Feb/11 ]

I am not familiar with this application, and as you stated, other application 'clusterjsp' works fine.
The bug doesn't seem to be in GUI when the application doesn't run.
Transfer to Hong for her evaluation.

Comment by Hong Zhang [ 04/Feb/11 ]

lidia: I was able to reproduce the problem with the steps you described. When I looked at the server.log, I noticed the application failed to load during the instance restart (your server.log has the same exception):

[#|2011-02-04T11:36:31.970-0800|SEVERE|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|ThreadID=1;_ThreadName=Thread-1;|javax.naming.NamingException: Lookup failed for 'jdbc/_default' in SerialContext[myEnv=

{com.sun.enterprise.connectors.jndisuffix=__pm, java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NameNotFoundException: jdbc]
java.lang.RuntimeException: javax.naming.NamingException: Lookup failed for 'jdbc/__default' in SerialContext[myEnv={com.sun.enterprise.connectors.jndisuffix=__pm, java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

[Root exception is javax.naming.NameNotFoundException: jdbc]
at org.glassfish.persistence.jpa.PersistenceUnitInfoImpl.<init>(PersistenceUnitInfoImpl.java:111)
...

So seems the resource jdbc/__default need to be available on the instance for the application to successfully load during server restart. I have tried to create the necessary resource before deployment, and things worked as expected afterwards (the application loaded successfully as part of the instance restart, and I can launch application successfully afterwards without any problem).

Comment by lidiam [ 04/Feb/11 ]

Thank you Hong, I missed this part! However, this failure should be reported to the user in Admin Console. It is discovered during instance startup and a warning message should be displayed to the user if there is any problem with application deployment/replication.

I think this should be addressed for v3.2.

Comment by Anissa Lam [ 04/Feb/11 ]

"It is discovered during instance startup and a warning message should be displayed to the user if there is any problem with application deployment/replication. "

Transfer to 'admin' since you are requesting instance startup to detect if there is any problem and provide warning to user.
If the warning is in action report, GUI should be able to show that to user already.

Comment by Tom Mueller [ 07/Feb/11 ]

Changing the summary to reflect the intent of this issue.

The root cause of this issue is that there were four SEVERE log messages output to the log file during instance startup, but the start-instance command did not report this information to the user, and therefore the information wasn't available in the console either.

Marking this as an improvement because there isn't anything in the system that is supposed to be doing this at this point, i.e., this would be a new feature.

Comment by Tom Mueller [ 05/Apr/11 ]

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





[GLASSFISH-16372] Not able to make toString() a final method in EJB with no-interface view Created: 17/Apr/11  Updated: 01/Apr/13

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

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

Tags: 3_1_1-scrubbed

 Description   

EJB 3.1 spec says the following in section #4.9.8:
/All public methods of the bean class and any superclasses are exposed as business methods
through the no-interface view.

All methods of the bean class and any superclasses must not be declared final./

Nowhere do I find that methods of "java.lang.Object" are excluded from being part of no-interface view of the bean. This can't be true, because Object class has quite a few final methods in it. So, I am assuming that all methods of java.lang.Object are automatically excluded from being part of no-interface view of the EJB. But, then I am surprised to see an exception while trying to deploy the following EJB:

@Stateless
@LocalBean
public class FooBean {

public String test(String s)

{return s.toUpperCase();}

@Override public final String toString()

{return "FooBean";}

}

I got following exception:

Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.EjbOptionalIntfGenerator.makeClass(EjbOptionalIntfGenerator.java:460)
... 27 more
Caused by: java.lang.VerifyError: class org.glassfish.fighterfish.test.app11.ejb._EJB31_GeneratedFooBeanIntf__Bean_ overrides final method toString.()Ljava/lang/String;
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
... 32 more

I think GlassFish is incorrectly making toString() a part of no-interface view of this bean.



 Comments   
Comment by marina vatkina [ 18/May/11 ]

We do not know if toString() will be called by the client. If it will, it should be a proxy call

Comment by Cheng Fang [ 19/Oct/11 ]

This issue was fixed as part of 17235 (Dependency Injection doesn't work for overloaded methods accepting generic-type parameter)

Comment by Mark Struberg [ 27/Mar/13 ]

Folks, I humbly recommend to reopen this issue.

final methods cannot get proxied, thus this method will always just hit the proxy instance instead of the proxied EJB instances. I think users will just not be aware what happens.

> Nowhere do I find that methods of "java.lang.Object" are excluded from being part of no-interface view of the bean.

That's true and should get fixed. I recommend to explicitly define the expected behaviour for Object.class methods and exclude them from the standard 'business methods' definition. Maybe this is already even in the spec implicitly? Not sure...

  • toString() -> should get proxied
  • equals, hashCode -> should not get proxied
  • clone -> should not get proxied
    etc
Comment by marina vatkina [ 29/Mar/13 ]

reopening...





[GLASSFISH-16304] domain.xml should be in UTF-8 Created: 01/Apr/11  Updated: 22/May/13

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

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

Issue Links:
Dependency
blocks GLASSFISH-16700 Could not upgrade from ogs-3.1-window... Closed
Tags: 3_1_1-scrubbed, 3_1_2-release-note-added, 3_1_2-release-notes, 3_1_x-exclude

 Description   

currently domain.xml is in native encoding. This could lead to invalid byte sequence and the server will fail to start.
domain.xml should be in UTF-8 to avoid this issue. It is also recommended to have the prolog in the file:
<?xml version="1.0" encoding="UTF-8"?> this way the users are aware of it.



 Comments   
Comment by Tom Mueller [ 04/Apr/11 ]

There have been two issues recently related to this issue:

GLASSFISH-15150 modified the writing of the domain.xml so that it always uses UTF-8. It did not add the header that is suggested in this bug report.

GLASSFISH-15319 requested that UTF-8 encoding for the domain.xml be removed. With this change, the file is written using the default encoding that is in effect for the server.

There was a discussion at the admin iteam meeting on Dec 22, 2010 about these where the consensus was to remove the hard-coding. See:
http://wikis.sun.com/pages/viewpage.action?pageId=235180885

I'm marking this issue as incomplete because the description does not provide any details about the circumstances that "could lead to invalid byte sequence". Clearly one circumstance is that if the user has an incorrect default encoding set for the server. However, that is considered a user error rather than a bug. Are there other circumstances that trigger this problem? If so, please document them and reopen the bug.

Comment by gmurr [ 04/Apr/11 ]

Here are some scenarios that will lead to issues:

1- The server is sunning in EN locale. The user inputs JA data from the admin console. A description field for instance. Since the server is running in EN locale, the default encoding can not handle JA data. domain.xml will contain invlaid byte sequence and the server will fail to restart.

2- The user can always change the system locale. If the new system locale can not handle the domain.xml previous encoding. The server will also fail to start.

3- If we have a cluster with nodes running in different locales. Let's suppose domain.xml contain Chinese data and one of the cluster nodes is running in a non Chinese locale. This node will not be able to handle the Chinese data correctly.

If domain.xml is in UTF-8, we will not face any portability issues with its content. Since UTF-8 supports all languages, we do not need to worry about the system locale as long as we read and write the data in UTF-8.

Comment by Tom Mueller [ 04/Apr/11 ]

Scenario #1 is the scenario that was mentioned in the previous comment. The user has an incorrect default encoding set for the server. This is considered a user error.

Scenario #2 is a difficult one to deal with. When this happens, it is currently necessary for the user to manually convert the encoding of the domain.xml file.

Scenario #3 is not a supported configuration.

I agree that storing the file in UTF-8 with the proper header would be a better solution. Some of the issues raised with this during the admin iteam meeting are:

1. How to deal with users that edit the domain.xml file with an editor that doesn't pay attention to the header? Or, if the header isn't there, it is likely that the editor is going to use some native encoding rather than UTF-8.

2. How to upgrade from previous releases that did not save the file in UTF-8? One solution for this is to assume that the file is using the default encoding if there is no header, and UTF-8 (or whatever encoding is specified) if there is a header.

Comment by scatari [ 17/May/11 ]

Approved for 3.1.1.

Comment by apcuk [ 17/Aug/11 ]

This is still a valid and very serious issue. I just registered to explain my problem. I spent weeks trying to find the solution with no luck, so I'm glad that finally I've found this page.

I am using Windows 7 with Hungarian locale. If I download glassfish and start it, it works fine. After a while, it won't restart/start even if I don't edit domain.xml manually (I don't even open it with a text editor). After this if I add something like <?xml version="1.0"?> as the first line, glassfish will be able to start up again, but this header gets deleted immediately. Also, after editing it can't find my app anymore (when undeploying for example), since I have accents in my name which is in the path of NetBeansProjects.

Comment by Tom Mueller [ 17/Aug/11 ]

Do you have any information about what happened between when it was working and when it stopped working? Was the console used to modify the configuration? Were asadmin commands used? Was an application deployed? Are there configuration changes that involve non-ASCII characters?

Presumably you are using an editor to add the <?xml version="1.0"?>. Is this editor changing the encoding? (Maybe it is the use of the editor rather than the header that is making it work.)

Comment by apcuk [ 18/Aug/11 ]

I used the admin console at localhost:4848 to modify some settings, adding a JAAS context for example. I did not use asadmin commands. Yes, I deployed a web application. The configuration changes did not involve non-ASCII characters. The only non-ASCII characters are in the path of NetBeansProjects (in my name), but I'm not sure if it has anything to do with domain.xml, NetBeans is able to deploy the app (at least for the first time).

I don't think the editor changes the encoding. If I want to save it notepad says the encoding is ANSI. Is there a way to check how the file has been encoded?

I will try to test what happens when in the next few days for more information.

Comment by Tom Mueller [ 18/Aug/11 ]

It would be helpful to see the error message that you get when starting the server (when it fails to start). If this is an encoding problem, you should be receiving some sort of encoding failure message or a parsing error messages for the domain.xml.

When the server fails to start, it would be helpful to see the domain.xml file, if that is something that you can share. By looking at the file, it is possible to tell what encoding is being used (if there are non-ascii characters). If the file is entire ascii characters, then the encoding doesn't matter. Generally, to do this you need an editor which can look at the binary values in the file.

Comment by apcuk [ 18/Aug/11 ]

There are indeed non-ASCII characters in the domain.xml, I didn't realize that before.

<applications>
<application context-root="/" location="file:/C:/Users/Szabó%20András/Documents/NetBeansProjects/.../build/web/" name="..." directory-deployed="true" object-type="user">
<property name="appLocation" value="file:/C:/Users/Szabó%20András/Documents/NetBeansProjects/.../build/web/"></property>
<property ... ></property>
...
</application>
</applications>

When the server fails to start, there is nothing in the log (simply nothing happens when I click "start" in NetBeans). Eclipse says port is out of range, but I guess it is some side effect because of the invalid domain.xml. If I want to open it in Google Chrome, it says "This page contains the following errors: error on line 11 at column 5: Encoding error / Below is a rendering of the page up to the first error." Then it shows nothing. Firefox, however, opens it perfectly.

I found a way to determine the encoding: Visual Studio says it's Central European (Windows) (which is normal if Glassfish uses native encoding, I guess). If I want to save it however, it switches to UTF-8. Weird.

I currently cannot share the xml with you, but I will create one from scratch without my personal data with a new glassfish installation.

Comment by Tom Mueller [ 18/Aug/11 ]

To see the error from GlassFish, use the Command Prompt window to start the domain with the -v option:

...\glassfish\bin\asadmin start-domain -v

You will see the output from the server in the command prompt window. This will probably include a message about finding an invalid character in the domain.xml file.

To work-around this issue, GlassFish must be started with a locale setting that has a default encoding that matches the encoding that is being used to specify the filename.

Comment by apcuk [ 18/Aug/11 ]

"asadmin start-domain -v" says:
... Parse error at [row,col]:[11,64]
Message: invalid byte 2 of 4 byte UTF-8 sequence. ...

So it seems that GlassFish writes the files using Central European encoding but then tries to read it with UTF-8.

The global "locale" textbox in the admin console is blank, since then (if I'm correct) GlassFish will be started using the default OS locale. So it will use the default encoding. I don't see where is the problem, to be honest.

What settings should I change?

Comment by Tom Mueller [ 19/Aug/11 ]

More investigation will be required to understand this fully, specifically to determine how a non-UTF-8 sequence is being written to the file when it is being read with UTF-8. GlassFish uses the same encoding to read and write the file, i.e., the default encoding for the JVM. If the JVM is being started in different ways with different default encodings, that might explain what is happening here.

Comment by apcuk [ 25/Sep/11 ]

Do you have any update on this issue? It seems that it's only me who is facing this problem, which is quite wierd, since I have default settings in Neatbeans, Glassfish, JVM etc.

I set both en_GB and hu_HU to override the default locale in Glassfish, but neither had any effect. Adding <?xml version="1.0" encoding="UTF-8"?> to domain.xml doesn't help either since it gets deleted during startup. So now I have to resave the xml with UTF-8 before every startup.

Thank you for your previous responses.

Comment by Tom Mueller [ 26/Sep/11 ]

I found an easy way to corrupt the GlassFish domain.xml file that produces a failure similar to yours. Just deploy an application, for example named helloworld, and then do the following:

asadmin set applications.application.helloworld.description=hióhi

If GlassFish is configured to use the default encoding on Windows, Cp1252, this command will succeed and the domain.xml file will be written, but the ó will be encoded in Central European Encoding rather than in Cp1252. The next time GlassFish is restarted, it will be unable to read the domain.xml file and the startup will fail.

This is actually a different bug than the one that is recorded here. I created GLASSFISH-17352 to track that bug. See the description of that bug for details about a workaround to the issue reported in the comments of this bug.

Comment by Tom Mueller [ 19/Oct/11 ]

Excluding this from 3.1.x releases. Will consider for 4.0.





[GLASSFISH-16064] javax.ejb.EJBException Caused by: org.omg.CORBA.OBJECT_NOT_EXIST: FINE: IOP02500002 Created: 21/Feb/11  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_b43
Fix Version/s: 4.1

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

$ java -version
java version "1.6.0_23"
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode)

$ uname -a
Linux 2.6.18-194.17.4.el5 #1 SMP Mon Oct 25 15:50:53 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux


Tags: 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

Often I see following messages in server.log:

[#|2011-02-21T14:31:11.233+0300|WARNING|glassfish3.1|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=142;_ThreadName=Thread-1;|A system e
xception occurred during an invocation on EJB ChukchiManSlotMachineBean method public byte openbox.chukchiman.ChukchiManSlotMachineBean.setPickedLineCount(byte)
javax.ejb.EJBException
at openbox.session._SessionFacade_Wrapper.setSessionData(openbox/session/_SessionFacade_Wrapper.java)
at openbox.core.component.GameComponent.setData(GameComponent.java:217)
at openbox.chukchiman.ChukchiManSlotMachineBean.setPickedLineCount(ChukchiManSlotMachineBean.java:345)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:4155)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5347)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5327)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:206)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
at $Proxy268.setPickedLineCount(Unknown Source)
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.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:144)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:174)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: org.omg.CORBA.OBJECT_NOT_EXIST: FINE: IOP02500002: Failed to create or locate Object Adaptor vmcid: SUN minor code: 2 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy189.noObjectAdaptor(Unknown Source)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:228)
at com.sun.corba.ee.impl.protocol.ServantCacheLocalCRDBase.updateCachedInfo(ServantCacheLocalCRDBase.java:86)
at com.sun.corba.ee.impl.protocol.ServantCacheLocalCRDBase.getCachedInfo(ServantCacheLocalCRDBase.java:77)
at com.sun.corba.ee.impl.protocol.FullServantCacheLocalCRDImpl.internalPreinvoke(FullServantCacheLocalCRDImpl.java:64)
at com.sun.corba.ee.impl.protocol.LocalClientRequestDispatcherBase.servant_preinvoke(LocalClientRequestDispatcherBase.java:240)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.servant_preinvoke(CorbaClientDelegateImpl.java:574)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:218)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at openbox.session._SessionFacade_Remote_DynamicStub.setSessionData(openbox/session/_SessionFacade_Remote_DynamicStub.java)
... 32 more
Caused by: org.omg.PortableServer.POAPackage.AdapterNonExistent: IDL:omg.org/PortableServer/POA/AdapterNonExistent:1.0
at com.sun.corba.ee.impl.oa.poa.POAImpl.doActivate(POAImpl.java:1115)
at com.sun.corba.ee.impl.oa.poa.POAImpl.find_POA(POAImpl.java:1048)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:224)
... 41 more

#]


 Comments   
Comment by Ken Cavanaugh [ 21/Feb/11 ]

This is logged at FINE level. If you enabled FINE level logging, you will see more
log messages, and those from the ORB will have stack traces. This is not a bug.

Did you observe any failures, or are you just reporting a log message?

Do you have FINE logging enabled, either for everything, or for logger
javax.enterprise.resource.corba?

Comment by marina vatkina [ 21/Feb/11 ]

Let's investigate this - the user reported a WARNING in the log.

Comment by marina vatkina [ 21/Feb/11 ]

Are there any other messages in the log? What kind of EJBs are used in this call stack?

Comment by lft [ 24/Feb/11 ]

This message can repeat several times.
The EJBs are staetful.

Comment by marina vatkina [ 24/Feb/11 ]

Can it be that you are trying to access a SFSB instance after it was discarded because of an exception in the previous call?

Comment by lft [ 27/Feb/11 ]

Right now I have only one occurance of this exception in logs (old server logs was cleared). And there is another exception above this one - IOP00710134, that I reported in another thread, - but it's related to another bean. There is no another exceptions related to bean that produced IOP02500002.

Comment by Tom Mueller [ 07/Feb/13 ]

Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.





[GLASSFISH-16042] Need to expose the value of ${com.sun.aas.hostName} from administration. Created: 17/Feb/11  Updated: 22/May/13

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

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

Attachments: JPEG File jvm-report.jpg    

 Description   

The value of $

{com.sun.aas.hostName}

is used in backend for various purposes.
In the case of multiple host names for a given ip address, one need to know the above value in order to create other virtual servers correctly.
See http://java.net/jira/browse/GLASSFISH-15797 for more details



 Comments   
Comment by Anissa Lam [ 17/Feb/11 ]

I don't see $

{com.sun.aas.hostName}

in any of the elements in domain.xml, so i don't know how GUI will be able to find out such 'key' exist and how to resolve it.
Is this the only key that GUI should display to user ? will there ever be more such case later on ?

I request that admin team provides a command that will return a list of such 'keys' and the corresponding value, then GUI will see where such a page fits in and display that key/value pair to user.
It also depends if the key and value pair is different for each instance. If so, maybe a target option is needed too.

I am transferring this to 'admin'. When such command is available, please transfer to REST so that it can be exposed through REST and then GUI can start implementing such enhancement.

Comment by Anissa Lam [ 17/Feb/11 ]

Sorry, I was just looking at domain.xml and didn't realize that the default value for hostName of Virtual Server is "$

{com.sun.aas.hostName}

" and thus won't get written out to domain.xml.

But this is not the only variable that is used in Virtual Server. $

{com.sun.aas.instanceRoot}

is also used for docroot attribute.
And there maybe other variable used in other config element as well.
So, my request for a command to get the key/value pair is still valid. Please provide such a command, and user can go to one single page to look at all this variables.

Comment by Tom Mueller [ 18/Feb/11 ]

Issue 15797 does not describe the use case for using this information in sufficient detail. Please provide a description of the use case here. When creating a virtual server, what information does the user need to look at, and what situation needs to be avoided in order to have a correct configuration? For example, is it necessary to look at the list of host names for all other virtual servers, on each target and make sure that there are no duplicates?

(If yes, then the virtual server logic could validate this at virtual server creation time, and print out the duplicate names in the error message.)

If the names do need to be unique, and one or more of them uses a system property, such as com.sun.aas.hostName or any other system property, what happens if the value for that property is changed later such that the hosts for the virtual servers are no longer unique? Does the virtual server implementation handle that properly with a suitable error message? If it does, why isn't that message sufficient for catching the configuration error that we are trying to prevent?

Note: the asadmin generate-jvm-report command outputs the values of all of the properties that are defined within the JVM, including com.sun.aas.hostName. So this command already exists. However, the variable values are just in the message and are not returned as properties within the response.

Please reopen the bug when the additional use case details are provided.

Comment by Shing Wai Chan [ 18/Feb/11 ]

When creating virtual servers, one need to specify the list of hosts and listeners. If the host is not specifiedd, it will take a default host value, $

{com.sun.aas.hostName}

.

It is a good idea to let user have the correct the information at the time of creation of the virtual server rather than waiting for information from configuration error.

Checking host names is not sufficient.
See the examples in http://blogs.sun.com/jluehe/entry/virtual_hosting_features_in_glassfish

Comment by Tom Mueller [ 21/Feb/11 ]

The first step in implementing this is to make the output of generate-jvm-report available as properties, so that the REST interface can pick it up.

Then the issue needs to be reassigned to the REST category to get the rest interface to generate-jvm-options.

Then it needs to be reassigned to admingui to design an interface in the console where there information can be made available.

Comment by Anissa Lam [ 21/Feb/11 ]

generate-jvm-report is available through GUI in 3.1. Please see attached.
For DAS and any instance, user can look at the jvm report, with the 4 different type like CLI.





[GLASSFISH-16018] AdminConsole: Logger Settings page is missing Load Defaults button Created: 16/Feb/11  Updated: 17/Oct/12

Status: Reopened
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b43
Fix Version/s: future release

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

Issue Links:
Dependency
depends on GLASSFISH-19169 need REST API for _load-default-log-a... Resolved
Tags: ee7ri_cleanup_deferred

 Description   

Go to default config (or any other config), Logger Settings page. Notice that Load Defaults button is missing. Is it present on other config pages that have default values, such as JVM Settings, JMS and others.

Here is comment from Anissa on this:

---------------------
Logger Settings are different than other config elements, it is in logging.properties.
You can file an RFE against logging to provide default value, and then we can implement that in GUI.

thanks
Anissa.
---------------------

Thus I'm logging this against logging module, please reassign to admin_gui once the default values are provided.



 Comments   
Comment by naman_mehta [ 05/Aug/11 ]

Added two new command which allows to load default values from log levels and attributes. This can be used by REST and then GUI to provide load default button under logger settings page.

Commands are _load-default-log-attributes and _load-default-log-levels.

SVN Commit: 48593.

Comment by shreedhar_ganapathy [ 01/Sep/11 ]

Could you also look into whether this fix should go into 3.1.2 and update issue and fix version to release and build number?

Comment by naman_mehta [ 02/Sep/11 ]

If GUI and REST are ready to consider for 3.1.2 then I will commit same changes on 3.1.2 branch also.

Comment by rajendra_inamdar [ 16/Oct/12 ]

Transfering to Console as per Anissa's comments:

On 10/16/12 5:05 PM, Anissa Lam wrote:
>
> I believe the REST resource for this is not available yet, cc'ing Jason to confirm.
> You can go ahead and transfer this to Console, and I will open one for Jason to provide the REST endpoint, and made that the dependence.
>
> thanks
> Anissa.

Comment by Tom Mueller [ 17/Oct/12 ]

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





[GLASSFISH-16140] server running as a service on Windows exits when user logs out (need -Xrs JVM option) Created: 03/Mar/11  Updated: 17/Oct/12

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

Type: Improvement Priority: Major
Reporter: Tom Mueller Assignee: Byron Nevins
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Issue Links:
Dependency
blocks GLASSFISH-16311 Improve operating service (OS) integr... Open
Duplicate
duplicates GLASSFISH-5263 Platform Services and the -Xrs option Resolved
Tags: ee7ri_cleanup_deferred

 Description   

From the GlassFish forum:
http://www.java.net/forum/topic/glassfish/glassfish/glassfish-v31-rc-and-asadminbat-oracle?force=200

If Oracle would like the asadmin create-service feature to be useful on Windows, then two things should be done to the default installation of GlassFish 3.1 to prevent the GlassFish Windows service from being shut down when the user logs out:
1) asadmin.bat's call to the java.exe needs -Xrs JVM option.
2) domain.xml needs a new <jvm-options>-Xrs</jvm-options>

Ryan



 Comments   
Comment by Tom Mueller [ 03/Mar/11 ]

Updated summary to read like a bug.

Comment by Byron Nevins [ 03/Mar/11 ]

I've blogged about this well-known issue:

http://blogs.sun.com/foo/entry/how_to_make_v3_platform

=================

We decided to keep this step for the user to do in 3.1. The main problem was that if I just plopped it in there you would not get stack traces with a KILL signal. Then users would be confused about that. Of course all known Java SE 6 implementations now have a jstack command [1] so that problem has mostly gone away.

Another problem is that there is no official delete-service command. So – if we added -Xrs to the server config as part of create-service, there would be no corresponding way to undo that.

Yet another problem is adding -Xrs to asadmin.bat The proper solution here, is to have a clone of asadmin.bat "start-service.bat" or something like that. Adding a new bat file to the installation is also a BIG deal.

So that left the only clean solution to be adding -Xrs to ALL server configs. This was decided to be unacceptable.

In 3.2 we will revisit this issue. I think we will probably add -Xrs to the config for all servers. After all it *is* an application server!

[1] it took FOREVER for Apple to implement it.

Comment by Byron Nevins [ 03/Mar/11 ]

D:\gf\v3\packager\nucleus-base>svn commit -F ..\svn-commit.tmp
Sending nucleus-base\bin\asadmin
Sending nucleus-base\bin\asadmin.bat
Sending nucleus-base\lib\templates\domain.xml
Transmitting file data ...
Committed revision 45384.

Comment by Byron Nevins [ 03/Mar/11 ]

Note that this does not just affect GF as a service. On the contrary! It is much much more likely to occur when running GF not-as-service!

I.e. most users will have GF-as-a-service run as system account – which never logs out. A non-service GF server, on the other hand, is almost always running as a user account and will immediately exit if the user logs out.

As of today – all GF servers will, by default, ignore all signals.

I added "-Xrs" to asadmin, asadmin.bat and to the 2 config elements in the default domain.xml

Comment by Byron Nevins [ 11/Mar/11 ]

I have heard negative feedback. I'll restore the code to the way it was, and keep this bug alive so it can be dealt with permanently for the next release.

===========================================

Hi, bnevins.

Adding -Xrs, kill -QUIT for getting threads dump must be ignored onUNIX
Systems.

So, Can you add the option just only Windows System?

How about adding it as variable on asenv.bat?

Thanks,

Comment by Byron Nevins [ 11/Mar/11 ]

http://blogs.sun.com/foo/entry/how_to_make_v3_platform

Comment by Byron Nevins [ 11/Mar/11 ]

Documentation:
http://download.oracle.com/docs/cd/E18930_01/html/821-2416/gglqp.html#giurf

Comment by Byron Nevins [ 22/Mar/11 ]

It's not feasible to put -Xrs oly for Windows. In order to do that I'd have to hide it in code and the user could not get rid of it. We can't have different default domain.xml files either.

One option is to add it as a jvm-option when the service is created on Windows but that's also a huge deal (requires the server(s) to be running. Yet more code for delete-service)

Comment by Byron Nevins [ 22/Mar/11 ]

reopen as RFE

Comment by Tom Mueller [ 22/Mar/11 ]

How about adding $

{Xrs} to the JVM options, and then in asenv.bat, add set Xrs=-Xrs, but don't add it to asenv.conf so that the ${Xrs}

doesn't expand to anything?

One problem with this is that the $

{Xrs}

could not be removed using delete-jvm-options because it wants every option to start with a dash.

Comment by Tom Mueller [ 17/Oct/12 ]

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





[GLASSFISH-16264] Embedded GF 3.1 (re)deployment with EJBContainer causes exception: Error linking security policy for ejb-timer-service-app Created: 24/Mar/11  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: security
Affects Version/s: 3.1
Fix Version/s: 4.1

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

Windows 7 Premium 64 bit; Glassfish 3.1; JDK 1.6.0_22 32 bit


Tags: 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude, bug, ejb31, embedded

 Description   

I have a JUnit test that starts up embedded glassfish 3.1 and deploys a module which contains EJBs. I placed the container init code in a @Before method so that it will be started fresh for each test like so:

//Set up the embedded EJB containers env properties
Map<String, Object> p = new HashMap<String, Object>();
p.put(EJBContainer.APP_NAME, "myapp");
p.put(EJBContainer.MODULES, new File("out/production/myapp"));
p.put("org.glassfish.ejb.embedded.glassfish.installation.root", "C:/glassfish3/glassfish");
ejbC = EJBContainer.createEJBContainer(p);

I also have a @After method which closes the container after each test like :

@After
public void tearDown() throws Exception

{ if (ejbC != null) ejbC.close(); }

The problem I am having is that the first test method deploys and runs fine, however, subsequent test methods fail on deployment with the following exception thrown by the EJBContainer.createEJBContainer(p) line of code above:

Mar 24, 2011 10:21:32 AM com.sun.ejb.containers.EjbContainerUtilImpl deployEJBTimerService
INFO: Loading EJBTimerService. Please wait.
classLoader = WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)
SharedSecrets.getJavaNetAccess()=java.net.URLClassLoader$7@167a209
Mar 24, 2011 10:21:32 AM org.hibernate.validator.engine.resolver.DefaultTraversableResolver detectJPA
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
Mar 24, 2011 10:21:32 AM org.eclipse.persistence.session.file:/C:/Users/nwhite/AppData/Local/Temp/gfembed8734725078398943370tmp/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App
INFO: EclipseLink, version: Eclipse Persistence Services - 2.2.0.v20110202-r8913
Mar 24, 2011 10:21:36 AM org.eclipse.persistence.session.file:/C:/Users/nwhite/AppData/Local/Temp/gfembed8734725078398943370tmp/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App
INFO: file:/C:/Users/nwhite/AppData/Local/Temp/gfembed8734725078398943370tmp/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App login successful
Mar 24, 2011 10:21:36 AM com.sun.ejb.containers.TimerBeanContainer <init>
INFO: [TimerBeanContainer] Created TimerBeanContainer: TimerBean
Mar 24, 2011 10:21:36 AM com.sun.ejb.containers.BaseContainer initializeHome
INFO: Portable JNDI names for EJB TimerBean : [java:global/ejb-timer-service-app/TimerBean, java:global/ejb-timer-service-app/TimerBean!com.sun.ejb.containers.TimerLocal]
classLoader = WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)
SharedSecrets.getJavaNetAccess()=java.net.URLClassLoader$7@167a209
Mar 24, 2011 10:21:36 AM org.glassfish.api.ActionReport failure
SEVERE: Exception while loading the app
Mar 24, 2011 10:21:36 AM org.eclipse.persistence.session.file:/C:/Users/nwhite/AppData/Local/Temp/gfembed8734725078398943370tmp/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App
INFO: file:/C:/Users/nwhite/AppData/Local/Temp/gfembed8734725078398943370tmp/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App logout successful
Mar 24, 2011 10:21:36 AM com.sun.ejb.containers.EjbContainerUtilImpl deployEJBTimerService
WARNING: Cannot deploy or load EJBTimerService:
org.glassfish.deployment.common.DeploymentException: Error in linking security policy for ejb-timer-service-app – Inconsistent Module State
at com.sun.enterprise.security.SecurityUtil.linkPolicyFile(SecurityUtil.java:335)
at com.sun.enterprise.security.SecurityDeployer.linkPolicies(SecurityDeployer.java:279)
at com.sun.enterprise.security.SecurityDeployer.access$100(SecurityDeployer.java:81)
at com.sun.enterprise.security.SecurityDeployer$AppDeployEventListener.event(SecurityDeployer.java:114)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:262)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at com.sun.ejb.containers.EjbContainerUtilImpl.deployEJBTimerService(EjbContainerUtilImpl.java:547)
at com.sun.ejb.containers.EjbContainerUtilImpl.getEJBTimerService(EjbContainerUtilImpl.java:289)
at com.sun.ejb.containers.EjbContainerUtilImpl.getEJBTimerService(EjbContainerUtilImpl.java:284)
at com.sun.ejb.containers.EjbContainerUtilImpl.getEJBTimerService(EjbContainerUtilImpl.java:269)
at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:755)
at com.sun.ejb.containers.AbstractSingletonContainer.<init>(AbstractSingletonContainer.java:141)
at com.sun.ejb.containers.CMCSingletonContainer.<init>(CMCSingletonContainer.java:77)
at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:115)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:234)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:290)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:101)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:249)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:193)
at org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:142)
at org.glassfish.ejb.embedded.EJBContainerImpl.deploy(EJBContainerImpl.java:135)
at org.glassfish.ejb.embedded.EJBContainerProviderImpl.createEJBContainer(EJBContainerProviderImpl.java:132)
at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:127)

During the shutdown process after the first test runs I noticed the following:

Mar 24, 2011 10:21:19 AM com.sun.ejb.containers.TimerBeanContainer doConcreteContainerShutdown
INFO: [TimerBeanContainer] Shutdown() called....
Mar 24, 2011 10:21:19 AM com.sun.ejb.containers.EJBTimerService onShutdown
INFO: EJB5122:EJB Timer Service shutdown at [2011/03/24 10:21:19]
Mar 24, 2011 10:21:19 AM com.sun.enterprise.web.WebContainer unloadWebModule
SEVERE: WEB0162: [WebContainer] Undeployment failed for context [/ejb-timer-service-app]
Mar 24, 2011 10:21:19 AM org.eclipse.persistence.session.file:/C:/Users/nwhite/AppData/Local/Temp/gfembed671660783214676050tmp/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App
INFO: file:/C:/Users/nwhite/AppData/Local/Temp/gfembed671660783214676050tmp/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App logout successful



 Comments   
Comment by marina vatkina [ 24/Mar/11 ]

Note that the same error can be observed by uncommenting lines marked "** Run the 2nd time **" in client/Client.java under v2/appserv-tests/devtests/ejb/ejb31/embedded/timertest (updated today) and do 'ant all'

Comment by kumarjayanti [ 18/May/11 ]

Please provide us a testcase.

Comment by scatari [ 25/Jun/11 ]

Closing this issue as a reproducible test case hasn't been provided. Please reopen once you have the test case.

Comment by emailnbw [ 25/Jun/11 ]

I am confused by scatari's actions. It appears from that history that kumarjayanti has marked this bug as fixed in 3.1.1 with checkin 14740. Is this not the case?

If this is not the case then there are plenty of details in the original bug report to set up your own test case. In addition Marina has also described how to reproduce this issue.

What more needs to be spoon fed?

This bug makes it impossible to effective unit test with isolated JUnit tests using Embedded Glassfish. Considering one of Embedded Glassfish's important use cases is to make unit testing your EJB easier I think this is a rather important bug to fix.

Comment by scatari [ 25/Jun/11 ]

No updates to the bug since 18/May with the final comment being a request to send a test case. I don't see a comment about 14740 in this tool.

Comment by emailnbw [ 25/Jun/11 ]

@scatari If you click on the 'All' tab in JIRA (I assume you must being using the same JIRA web interface?!) you will see on May 18th right below kumarjayanti's comment about requesting a test case he set the "Fix Version/s" field to 3.1.1 [14740]. To me, that implies a fix was checked in. Does it not?

Once again, there is plenty of detail in my original submission for kumarjayanti (or anyone else) to write a test for this. And again, Marina's comments on 3/24 also spell out how to reproduce this issue using your own devtests!

Comment by kumarjayanti [ 26/Jun/11 ]

The security team and Marina are actively discussing how to fix this...

Comment by marina vatkina [ 27/Jun/11 ]

As everybody said, it was wrong to close it

Comment by scatari [ 27/Jun/11 ]

Can we update the bug as when we have information to show the progress? Not seeing any update to the bug for a month does not prove that it is being worked on.

Comment by marina vatkina [ 06/Jul/11 ]

patch for static refs in the ejb-container

Comment by marina vatkina [ 06/Jul/11 ]

With the currant security hack in 3.1.1, and my patch attached to this issue, the 2nd TS start fails with:

[java] Jul 6, 2011 2:07:11 PM com.sun.enterprise.security.provider.BasePolicyWrapper logMsg
[java] INFO: JACC Policy Provider:Failed Permission Check: context (" ejb-timer-service-app/ejb-timer-service-app_internal ") , permission (" (javax.security.jacc.EJBMethodPermission TimerBean findActiveTimersOwnedByThisServer,Local,) ")
[java] Jul 6, 2011 2:07:11 PM com.sun.ejb.containers.BaseContainer postInvoke
[java] WARNING: A system exception occurred during an invocation on EJB TimerBean method public java.util.Set com.sun.ejb.containers.TimerBean.findActiveTimersOwnedByThisServer()
[java] javax.ejb.AccessLocalException: Client not authorized for this invocation.

Comment by marina vatkina [ 06/Jul/11 ]

The patch is checked in into trunk with rev 47893.

Comment by marina vatkina [ 07/Jul/11 ]

The patch is checked in with rev 47907 to 3.1.1 branch

Comment by scatari [ 11/Jul/11 ]

Fixed in B11.

Comment by marina vatkina [ 11/Jul/11 ]

The security part is not fixed. The EJB part is.

Comment by Cheng Fang [ 13/Jul/11 ]

Assign it to me.

Comment by Cheng Fang [ 15/Jul/11 ]

Stacktrace for the permission check error:

     [java] WARNING: A system exception occurred during an invocation on EJB TimerBean method public java.util.Set com.sun.ejb.containers.TimerBean.findActiveTimersOwnedByThisServer()
     [java] javax.ejb.AccessLocalException: Client not authorized for this invocation.
     [java] 	at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1885)
     [java] 	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
     [java] 	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
     [java] 	at $Proxy130.findActiveTimersOwnedByThisServer(Unknown Source)
     [java] 	at com.sun.ejb.containers.EJBTimerService.restoreEJBTimers(EJBTimerService.java:486)
     [java] 	at com.sun.ejb.containers.EjbContainerUtilImpl.getEJBTimerService(EjbContainerUtilImpl.java:307)
     [java] 	at com.sun.ejb.containers.EjbContainerUtilImpl.getEJBTimerService(EjbContainerUtilImpl.java:289)
     [java] 	at com.sun.ejb.containers.EjbContainerUtilImpl.getEJBTimerService(EjbContainerUtilImpl.java:274)
     [java] 	at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:755)
     [java] 	at com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:155)
     [java] 	at com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:149)
     [java] 	at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:105)
     [java] 	at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:230)
     [java] 	at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:290)
     [java] 	at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:101)
     [java] 	at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
     [java] 	at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:257)
     [java] 	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
     [java] 	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
     [java] 	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:382)
     [java] 	at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
     [java] 	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
     [java] 	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1064)
     [java] 	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
     [java] 	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1244)
     [java] 	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1232)
     [java] 	at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:129)
     [java] 	at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:105)
     [java] 	at org.glassfish.ejb.embedded.EJBContainerImpl.deploy(EJBContainerImpl.java:140)
     [java] 	at org.glassfish.ejb.embedded.EJBContainerProviderImpl.createEJBContainer(EJBContainerProviderImpl.java:134)
     [java] 	at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:127)
     [java] 	at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:102)
     [java] 	at com.acme.Client.test(Client.java:81)
     [java] 	at com.acme.Client.main(Client.java:70)
Comment by Cheng Fang [ 15/Jul/11 ]

After applying Kumar's hack (related to inService check) to 3.1.1 build, the ejbdev test embedded/timertest passed when running the second timer tests. I tried the test run several times w/ the same result.

The ejb error Kumar was seeing before (Caused by: java.lang.NoSuchFieldError: moduleName) looks like a setup issue. moduleName field was recently added to 3.2, but not to 3.1.1. When runnign w/ 3.1.1, there should be no trace of it. With 3.2, it should be resolved correctly.

Re-assign to security team to pursue a formal fix.

Comment by syvalta [ 15/Jun/12 ]

Could the "Fix version" be updated as this is still open and 3.1.2 has already been released?

Comment by markds [ 10/Jan/13 ]

Can I ask what is happening with this bug? It still occurs in 3.1.2.2





[GLASSFISH-16999] Either PKG_CLIENT_READ_TIMEOUT is too small or Oracle's servers are too slow Created: 08/Jul/11  Updated: 06/Nov/12

Status: Reopened
Project: glassfish
Component/s: update_center
Affects Version/s: 3.1
Fix Version/s: None

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

Win7 Pro SP1 64 Bit de_DE


Issue Links:
Dependency
depends on UPDATECENTER2-2197 Increase PKG_CLIENT_READ_TIMEOUT in J... Closed
Tags: 3_1-next, 3_1-next_release-note, 3_1-next_release-note-added, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

Installation of update tool fails due to timeout (every time we tried it in the past seven days). Either the timeouts programmed into the installer are too small, or Oracle's servers providing the downloads are too slow.

Sometimes no connection at all is possible, but most of the time the download fails:

Proxy: Using system proxy settings.
Install image: C:\glassfish3
Installing updatetool packages.
Downloading 2 packages.
Downloading updatetool (564 files, 4.630.541 bytes).
File 564/564
Downloading wxpython2.8-minimal (346 files, 13.763.618 bytes).
File 46/346Input/output error: Read timed out

Could not download application packages. This could be because:

  • a proxy server is needed to access the internet. Please ensure that
    the system proxy server settings in your Internet Options control panel
    (under Connections:LAN Settings) are correct, or set the HTTP_PROXY
    environment variable to the full URL of the proxy server.
  • the package server is down or otherwise inaccessible or it is
    generating invalid data. Please contact the provider of the package
    server.

The negative side effect is that the graphical installer which internally tries to do this download will fail without clearly telling that actual cause of the problem (just says it cannot install the update tool), so people don't know what to do!

When increasing the timeout we could install without any problem, so this clearly proofs that either the default timeout is too small or Oracle's servers are just too slow. There is nothing wrong with our internet connection and while the download fails, a test drive proofs a FREE bandwith of 1,5 Mb/s (so it is not related to our infrastructure or net access).

C:\>set PKG_CLIENT_CONNECT_TIMEOUT=300
C:\>set PKG_CLIENT_READ_TIMEOUT=300

Proxy: Using system proxy settings.
Install image: C:\glassfish3
Installing updatetool packages.
Downloading 2 packages.
Downloading updatetool (564 files, 4.630.541 bytes).
File 564/564
Downloading wxpython2.8-minimal (346 files, 13.763.618 bytes).
File 346/346
Executing 1.095 install actions.
Registering notifier: Not able to register. Returned exit code 3.
Starting notifier.
Initialization complete.

Please either upgrade your download facilities or increase the default timeouts.

But in any case, please provide a clear message to the user that it is not HIS fault, particularly in the graphical installer.

We have rated this bug as CRITICAL since it prevents a successful complete default installation using the graphical installer.



 Comments   
Comment by Joe Di Pol [ 08/Jul/11 ]

This requires a change to the Update Center bootstrap Java client. I've created UPDATECENTER2-2197 to track that change.

Comment by Joe Di Pol [ 08/Jul/11 ]

This is too late to fix in 3.1.1. I've tagged for inclusion in the Release Notes. We should state that if the installation of update center fails in the installer (or if it fails when running 'pkg' or 'updatetool' from the command line the first time) the user should try the following from the command line:

C:\>set PKG_CLIENT_CONNECT_TIMEOUT=300
C:\>set PKG_CLIENT_READ_TIMEOUT=300
C:\>glassfish3\bin\updatetool

This will bootstrap updatetool using the increased timeouts.

Comment by mkarg [ 11/Jul/11 ]

Looking at the long timeout values needed, I would say this is not a problem of too small timouts, but more of too slow Oracle servers. And, it would be much better for Oracle's reputation to set up more machines instead of asking a user to try again with ridiculously large timeout values.

Comment by Joe Di Pol [ 11/Jul/11 ]

Actually both aspects need to be addressed. The default timeouts should be longer to handle transient network slowness, but I agree we do need to address the operational aspect of this as well.

mkarg, what is your geographic location? Are you located in Germany?

Comment by Rebecca Parks [ 11/Jul/11 ]

Added the following to the 3.1.1 Release Notes:

PKG_CLIENT_READ_TIMEOUT is too small (16999)

Description

Installation of the Update Center sometimes times out and fails.

Workaround

If Update Center installation fails in the installer or when running pkg or updatetool from the command line, enter the following from the command line:

> set PKG_CLIENT_CONNECT_TIMEOUT=300
> set PKG_CLIENT_READ_TIMEOUT=300
> glassfish3\bin\updatetool

Comment by mkarg [ 12/Jul/11 ]

Joe,

yes I am located in Germany. Our overall connectivity to US servers is great, but especially Oracle pages are getting served rather slow. Maybe Oracle Germany could set up some local mirror to overcome this issue?

Regards
Markus

Comment by mkarg [ 13/Jul/11 ]

Just tried out the graphical installer of 3.1.1_b11 having set the above environment variables. In fact, the installer runs well then, but it needs about half an hour to install. In all that time, the progress bar shows 41%. I expect most people to kill that process...

Comment by Joe Di Pol [ 16/Nov/11 ]

The update center bug to increase the client timeouts has been implemented, and we've increased the number of download threads in the client as well. This will mitigate the problem some, but we still have the issue that our IPS package servers are not mirrored geographically which means non-US locations will continue to see slower download speeds (the IPS repository protocol is sensitive to latency in addition to bandwidth).





[GLASSFISH-16874] Faster restart time Created: 16/Jun/11  Updated: 04/Feb/13

Status: Reopened
Project: glassfish
Component/s: ide-integration
Affects Version/s: 3.1_b10
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: cowwoc Assignee: Tomas Kraus
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The time it takes to shutdown Glassfish and restart it is extremely slow. It is at least an order of magnitude greater than Tomcat, Grizzly and Jetty.

There are two reasons I'd like to see this resolve:

  1. I am modifying JNI code between restarts: http://stackoverflow.com/questions/6333056/running-webapps-in-separate-processes
  2. I want a stripped-down servlet server. I don't use the rest of the J2EE stack and I don't want it loaded for no reason.

I expect to be able to restart Glassfish in 3 seconds or less. Remember, every time I modify the webapp I need to redeploy it by restarting the server. Anything longer than 3 seconds will seriously hamper development productivity.



 Comments   
Comment by Tim Quinn [ 16/Jun/11 ]

I see that you filed this as affecting release 3.1. Has your experience been the same with recent builds of 3.1.1?

If you want only a web container, you should try using the GlassFish Web distribution (instead of the full Java EE distribution) and see if that is faster for you.

On the GlassFish download site, navigate to the release you are interested in (for example, http://dlc.sun.com.edgesuite.net/glassfish/3.1.1/promoted/ for the latest builds of 3.1.1) and you'll see (again, for example)

latest-web-ml.zip 09-Jun-2011 14:06 56M
latest-web-unix-ml.sh 09-Jun-2011 14:08 38M
latest-web-unix.sh 09-Jun-2011 13:43 32M
latest-web-windows-ml.exe 09-Jun-2011 14:10 38M
latest-web-windows.exe 09-Jun-2011 13:44 32M
latest-web.zip 09-Jun-2011 13:41 44M

What specific release of GlassFish are you using (is it released 3.1 which is 3.1-b43)?

What times are you seeing for restart?

Comment by Hong Zhang [ 10/Oct/12 ]

Closed the RFE as there was no response from user (assuming the issue no longer exists).

Comment by cowwoc [ 10/Oct/12 ]

Please reopen this issue.

Using Glassfish 3.1.2 which ships with Netbeans 7.2 I get:

16 seconds to shut down
4 seconds to start up
A total of 20 seconds, whereas the stated goal is 3 seconds. Start-up time is very encouraging but it's not clear why shutdown takes so long.

Comment by Hong Zhang [ 10/Oct/12 ]

I have re-opened the issue based on your request. Can you provide some additional information so we can try to reproduce it from our side, what were the steps/applications you used?

Have you tried to use web profile as Tim suggested earlier to see if it makes a difference?

I am not sure why you would need to restart server each time after you redeploy application, that should not be necessary. Is this related to that you need to modify JNI code between restarts?

As this is more web app specific, I am reassigning to web team for them to further evaluate.

Comment by cowwoc [ 10/Oct/12 ]

To reproduce simply install Netbeans 7.2, open any web project, launch Glassfish, then hit the "restart" button to restart the server.

Yes. As stated above, I need to restart the server anytime I modify native code (because there is no other way to get Glassfish to unload it before loading a new instance of the webap).

Here is what I see for the web profile of 3.1.2.2: Shutdown in 2 seconds, sleep for 13 seconds (nothing seems to be happening), Startup in 4 seconds. Looking back at the full version of 3.1.2 I see a similar behavior.

So, overall start/shutdown is roughly 6 seconds (not bad, but could certainly be improved) and it's not clear where this 13 second delay is coming from (is it Glassfish? is it the Netbeans plugin?)

Comment by vince kraemer [ 01/Feb/13 ]

this looks like it is more an ide integration issue than a web container issue.

I did some quick experiments with NB 7.2.1 and GF 3.1.2.2....

1. restart server using restart menu item on server node: about 10 seconds.

2. restart using the restart button in the server logs output window: about 12 seconds

3. restart the server using asadmin stop-domain then start-domain : about 11 seconds

4. restart the server using asadmin restart-domain : about 6 seconds

It seems the IDE is using stop/start instead of restart-domain... There may be reasons for that choice, but it is worth looking at a second time.

Comment by cowwoc [ 01/Feb/13 ]

That might be part of the problem, but the other part is the 6 seconds you're seeing. 6 seconds is an eternity when you restart a server 100s of times a day. Like I said, anything above 3 seconds is bad (and even 3 seconds isn't great).

I ended up solving my problem by using Jetty (restart time under 1 second!) but clearly this isn't really a solution.

Comment by vince kraemer [ 04/Feb/13 ]

I agree. Once the restart from the IDE is going as fast as the server will allow, we can reassign the issue to the server to make their restart faster.





[GLASSFISH-18169] Log not displayed in Raw Log Viewer for instance on a remote config node Created: 11/Jan/12  Updated: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: lidiam Assignee: andriy.zhdanov
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ogs-3.1.2-b17-01_09_2012.zip, DAS on Windows XP, config node on solaris


Attachments: JPEG File empty-raw-log.JPG     Text File server.log.txt    
Tags: 312_gui_new, 312_qa, 3_1_2-exclude

 Description   

Log is not displayed in Raw Log Viewer for an instance that's running on a remote CONFIG node. See attached screenshot and server.log, that contains the following exception:

[#|2012-01-10T17:23:57.281-0800|SEVERE|glassfish3.1.2|com.sun.jersey.spi.contain
er.ContainerResponse|_ThreadID=63;_ThreadName=Thread-2;|The RuntimeException could not be mapped to a response, re-throwing to the HTTP container
java.lang.NullPointerException
at com.sun.enterprise.server.logging.logviewer.backend.LogFilter.getLogF
ileForGivenTarget(LogFilter.java:320)
at org.glassfish.admin.rest.resources.custom.LogViewerResource.get(LogVi
ewerResource.java:121)
at sun.reflect.GeneratedMethodAccessor197.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMe
thodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMeth
odDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchPr
ovider.java:205)

Steps to reproduce:

1. Create a CONFIG node on a remote machine in Admin Console (enter name and host only to make it easy).
2. Log in to the remote machine and create standalone instance locally via:

asadmin --host <das host> create-local-instance inty1

3. Start local instance on the remote machine via:

asadmin start-local-intsnce --host <das host> inty1

4. Go to Admin Console and navigate to the Instance General page. Click on View Raw Log - the server.log file content is not displayed.



 Comments   
Comment by Anissa Lam [ 11/Jan/12 ]

Assign to Andriy so he can evaluate the issue.
However, it has passed HCF, we will not be fixing this for 3.1.2. This is based on the reason that this seems to be a corner/not so common case.
The feature works on

  • instance with localhost CONFIG nodes
  • remote instance with SSH nodes
  • remote instance with DCOM nodes

The case that is not working is for case of CONFIG node on remote system, where user needs to login to the remote system to create a local instance and also start that local instance on that machine.

I am adding the exclude tag. If you think otherwise, please bring that up to Joe and the GUI team.

Andriy, if this is a backend bug, please reassign to logging. thanks

Comment by andriy.zhdanov [ 26/Jan/12 ]

I think this can not be supported for remote config nodes - as far as I understand, remote config nodes do not support any communication.

Comment by lidiam [ 27/Jan/12 ]

If we cannot display content of a log file for instances on remote, CONFIG nodes, then the View Raw Log button should not be displayed for those instances.

Comment by Anissa Lam [ 12/Feb/13 ]

Issues need to be addressed before 4.0 HCF (3/25)

Comment by Anissa Lam [ 15/Feb/13 ]

Move to 4.0.1 according to project triage guidelines.





[GLASSFISH-20699] GlassFish returns 500 instead of 404 upon WebApplicationException Created: 14/Jul/13  Updated: 11/Dec/13

Status: Reopened
Project: glassfish
Component/s: jax-rs
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

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

OSX Mavericks Preview 3


Attachments: Text File cdi-transaction-rollback.patch     Zip Archive GlassFish-20699.zip     Zip Archive GlassFish-20699_updated.zip    
Issue Links:
Related
is related to JAX_RS_SPEC-440 WebApplicationException contract coul... Open

 Description   

The following method does not return a status of 404 Not Found, but instead returns a 500 Internal Server Error.

@Path("something")
public class Something {

@GET
public String getSomething()

{ throw new WebApplicationException(Status.NOT_FOUND); }

}

This used to work fine with GlassFish 3.1.
I do not have this problem when returning Status.BAD_REQUEST.



 Comments   
Comment by svanimpe [ 11/Sep/13 ]

Can someone please take a look at this ? Two months later and this issue is still exactly the same.

I can also add that the same thing happens with "throw new WebApplicationException(Status.FORBIDDEN)", as well as with "throw new NotFoundException()" and "throw new ForbiddenException()".

Comment by TangYong [ 11/Sep/13 ]

I made a sample the same as you said, however, my sample ran well, and 404 error can be displayed normally.

[Steps]
1. mvn clean install
2. asadmin deploy ...
3. accessing "http://localhost:8080/glassfish-20699/webapi/test/"

So, pl. seeing whether having any wrong config in your sample.

Then, I will close the jira.

Thanks
Tang

Comment by svanimpe [ 11/Sep/13 ]

Hi Tang,

The problem seems to be reproducible if you add @Transactional to the class in the sample.
In that case you no longer get a 404 but a 500 with a RollbackException.

Comment by TangYong [ 11/Sep/13 ]

Surly, if adding javax.transaction.Transactional into TestService class(GlassFish-20699_updated.zip), 500 error happened, and in the server.log,

[2013-09-11T19:01:03.780+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.resource.jta.org.glassfish.cdi.transaction] [tid: _ThreadID=39 _ThreadName=http-listener-1(4)] [timeMillis: 1378893663780] [levelValue: 800] [[
In REQUIRED TransactionalInterceptor]]

[2013-09-11T19:01:03.952+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.resource.jta.org.glassfish.cdi.transaction] [tid: _ThreadID=39 _ThreadName=http-listener-1(4)] [timeMillis: 1378893663952] [levelValue: 800] [[
Managed bean with Transactional annotation and TxType of REQUIRED called outside a transaction context. Beginning a transaction...]]

[2013-09-11T19:01:03.999+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.resource.jta.org.glassfish.cdi.transaction] [tid: _ThreadID=39 _ThreadName=http-listener-1(4)] [timeMillis: 1378893663999] [levelValue: 800] [[
About to setRollbackOnly from @Transactional interceptor on transaction:JavaEETransactionImpl: txId=1 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[]]]

[2013-09-11T19:01:04.015+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.resource.jta.org.glassfish.cdi.transaction] [tid: _ThreadID=39 _ThreadName=http-listener-1(4)] [timeMillis: 1378893664015] [levelValue: 800] [[
Managed bean with Transactional annotation and TxType of REQUIRED encountered exception during commit javax.transaction.RollbackException: Transaction marked for rollback.]]

[2013-09-11T19:01:04.015+0900] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=39 _ThreadName=http-listener-1(4)] [timeMillis: 1378893664015] [levelValue: 900] [[
StandardWrapperValve[javax.ws.rs.core.Application]: Servlet.service() for servlet javax.ws.rs.core.Application threw exception
javax.transaction.RollbackException: Transaction marked for rollback.
at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:445)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:854)
at com.sun.enterprise.transaction.TransactionManagerHelper.commit(TransactionManagerHelper.java:81)
at org.glassfish.cdi.transaction.TransactionalInterceptorRequired.transactional(TransactionalInterceptorRequired.java:99)
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.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30)
at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:93)
at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:78)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41)
at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53)
at org.jboss.weld.proxies.TestService$Proxy$_$$_WeldSubclass.greet(Unknown Source)
at org.jboss.weld.proxies.TestService$Proxy$_$$_WeldClientProxy.greet(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 org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:140)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:158)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$TypeOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:195)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:101)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:353)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:343)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:237)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:318)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:211)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:982)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:359)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:372)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:335)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:218)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
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.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:359)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:496)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:175)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:187)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:837)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:722)
]]

So, forwarding to jta comp firstly to evaluate the issue.

Comment by TangYong [ 11/Sep/13 ]

According to the JTA 1.2 specification, any unchecked Exception will automatically rollback the transaction. So, for the sample, "throw new WebApplicationException(Status.NOT_FOUND);" will cause rollback the transaction.

Then, the exception stack should be right, however, a point needs to be confirmed, whether 500 error is right?

Thanks
Tang

Comment by svanimpe [ 11/Sep/13 ]

I can verify that this does indeed happen with all my WebApplicationExceptions. In the past (Java EE 6, so no @Transactional), this did not happen when returning a Bad Request, but now it does too. I can work around it by returning a Response object from every method, but that's very cumbersome.

The API docs for WebApplicationException say the following:
This exception may be thrown by a resource method, provider or StreamingOutput implementation if a specific HTTP error response needs to be produced.

So a 500 response is not what one would expect when using these exceptions.

Comment by marina vatkina [ 11/Sep/13 ]

Assigning to the web-container to check which response code is appropriate

Comment by Shing Wai Chan [ 11/Sep/13 ]

This is a jaxrs application. Assign to jaxrs team.

Comment by Shing Wai Chan [ 11/Sep/13 ]

This is a jaxrs application. Assign to jax-rs team.

Comment by TangYong [ 11/Oct/13 ]

Waiting the fix of https://java.net/jira/browse/JERSEY-2137.

Comment by Jakub Podlesak [ 06/Dec/13 ]

Just to confirm, the expected behaviour should be: 404 is returned back a no rollback happens, right?

Comment by TangYong [ 06/Dec/13 ]

Jakub,

IMHO, based on the following and [1], while specifying Status.NOT_FOUND, an user should see 404 rather than 500. As for rollback, this should be guaranteed by JTA 1.2 Spec, even if the sample can not demostrate the point well.

@GET
public String getSomething()

{ throw new WebApplicationException(Status.NOT_FOUND); }

[1]: http://docs.oracle.com/javaee/7/api/javax/ws/rs/core/Response.Status.html

Tang

Comment by Jakub Podlesak [ 09/Dec/13 ]

We could probably fix this in JAX-RS/CDI integration layer. However, i believe this should be fixed in the application itself.
The problem is, combination of JTA/JAX-RS is not covered by either of the spec. Now, you complain JAX-RS WebApplicationException
contract is broken. If we fixed the runtime, someone else could complain the JTA @Transactional contract is broken, i.e. a non-checked exception
is thrown and no rollback happens.

I believe the right thing to do in your case is to fix the application code as follows:
Instead of plain

@Transactional

annotation, you should rather
be using

@Transactional(dontRollbackOn=WebApplicationException.class)
Comment by Jakub Podlesak [ 09/Dec/13 ]

Please see my earlier comment on how to fix this.

Comment by Jakub Podlesak [ 09/Dec/13 ]

Tang,

I only see your comment now. My suggested solution would then unfortunately not work for you. Going to re-open this one.
I will keep JAX_RS_SPEC-440 open, as i think this could still be covered in the spec.

~Jakub

Comment by Jakub Podlesak [ 09/Dec/13 ]

Hmm, suggested solution does not seem to work as requested, going to try to fix this in the JAX-RS integration layer.

Comment by svanimpe [ 09/Dec/13 ]

Can I ask what the difference is between:

@Path("test")
@Stateless
public class Test
{
    @PersistenceContext
    private EntityManager em;
    
    @GET
    public void test()
    {
        // ...
        throw new BadRequestException("Some message");
    }
}

and

@Path("test")
@Transactional(dontRollbackOn=BadRequestException.class)
public class Test
{
    @PersistenceContext
    private EntityManager em;
    
    @GET
    public void test()
    {
        // ...
        throw new BadRequestException("Some message");
    }
}

with regard to transactions? Is the transaction rolled back in the EJB case? Are the changes in

// ....

ever committed?

Comment by Jakub Podlesak [ 09/Dec/13 ]

Not sure about the above. It is a question for JTA guys.

My plan regarding fixing the original issue is as follows.
[1] is quite clear on how the @Transactional support is implemented.
From the Jersey runtime side, i apparently need to make sure that:

  • JTA interceptor will still see the WebApplicationException thrown
  • but after the above happens, Jersey runtime makes sure the original WebApplicaitonException gets propagated further

I need to make sure the HTTP response is driven by the WebApplicationException regardless value of the dontRollbackOn parameter.

Please let me know, if your understanding of how the issue should be fixed is different.

[1]https://javaee-spec.java.net/nonav/javadocs/javax/transaction/Transactional.html

Comment by TangYong [ 10/Dec/13 ]

Jakub,

Yes, whether needing to roll back should be JTA interceptor doing. Here's focus is HTTP response which is driven by the WebApplicationException.

Best Regards
Tang

Comment by TangYong [ 10/Dec/13 ]

I guess this fixing should have some difficulties as following:

There is a large risk that whether such fixing will be related to JTA. After all, javax.transaction.RollbackException causes 500 Internal Server Error. Then, while trying to fix Jersey runtime and propagate WAE, how to handle RollbackException's propagation and WAE's propagation will be a hard point.

Tang

Comment by Jakub Podlesak [ 11/Dec/13 ]

I have a fix ready, that works around the JTA issue. It involves an additional CDI interceptor that retains the original

{WebApplicationException}

and Jersey extended exception mapper that handles the unfortunate

{TransactionalException}

. I must say that i do not like the fix, as it is IMHO rather
a workaround for a bug in GlassFish JTA/CDI integration code.

The workaround should be only used temporarily (for running newer Jersey version on a stable GF release) until a fixed GF version is available.

Comment by Jakub Podlesak [ 11/Dec/13 ]

Patch for JTA/CDI integration code: rollback transactions marked for rollback rather then doing commit on each and every transaction.





[GLASSFISH-20564] [fishcat] GF b89 : WARNING: Class 'javax.ejb.PostActivate' not found, interception based on it is not enabled Created: 21/May/13  Updated: 11/Jun/14

Status: Reopened
Project: glassfish
Component/s: ide-integration
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: survivant Assignee: Tomas Kraus
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Product Version: NetBeans IDE Dev (Build 201305052300)
Java: 1.7.0_13; Java HotSpot(TM) Client VM 23.7-b01
Runtime: Java(TM) SE Runtime Environment 1.7.0_13-b20
System: Windows XP version 5.1 running on x86; Cp1252; fr_CA (nb)
User directory: C:\Documents and Settings\sdionne1\Application Data\NetBeans\dev
Cache directory: C:\Documents and Settings\sdionne1\Local Settings\Application Data\NetBeans\Cache\dev


Attachments: Zip Archive WebApplication1.zip    
Tags: cdi, ejb, fishcat

 Description   

INFO: WELD-000900 2.0.0 (SP1)
WARNING: Class 'javax.ejb.PostActivate' not found, interception based on it is not enabled
WARNING: Class 'javax.ejb.PrePassivate' not found, interception based on it is not enabled
INFO: Registering the Jersey servlet application, named org.netbeans.rest.application.config.ApplicationConfig, at the servlet mapping /resources/*, with the Application class of the same name.
INFO: Initialisation de Mojarra 2.2.0 ( 20130502-2118 https://svn.java.net/svn/mojarra~svn/tags/2.2.0@11930) pour le contexte «/WebApplication1»
INFO: Loading application [WebApplication1] at [/WebApplication1]
INFO: WebApplication1 was successfully deployed in 19 546 milliseconds.

source : HelloResource.java

package com.demo;

import javax.annotation.PostConstruct;
import javax.inject.Inject;
import javax.ws.rs.Consumes;
import javax.ws.rs.GET;
import javax.ws.rs.POST;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;

/**
*

  • @author sdionne1
    */
    @Path("hello")
    public class HelloResource {

@Inject
CDIManagedBean bean;

@Inject
EJBManagedBean ejb;

@PostConstruct
public void init()

{ System.out.println(HelloResource.class + " post construct"); }

@GET
@Produces("text/plain")
public String getHello()

{ return "hello : " + bean.getOutput() + " : " + ejb.getOutput(); }

@POST
@Consumes("text/plain")
public void sayHello(String message)

{ System.out.println("Say Hello : " + message); }

@POST
@Consumes("application/json")
public void helloJson(User user)

{ System.out.println("helloJson user : " + user); }

}



 Comments   
Comment by jjsnyder83 [ 22/May/13 ]

Please attach the application with source code.

Comment by survivant [ 22/May/13 ]

Where the link to attach source code in Jira ?

for now.. I send you the source code by email.

Comment by jjsnyder83 [ 22/May/13 ]

It appears that NetBeans is putting a bunch of jersey jars into the WEB-INF/lib directory of the application when it is built. These jars should not be placed in WEB-INF/lib

Comment by vince kraemer [ 22/May/13 ]

Tomas needs to look at this.

Comment by marina vatkina [ 22/May/13 ]

I think it's a Weld issue - there are similar warnings in the ejb devtests log:

[2013-05-22T06:00:59.911-0700] [glassfish 4.0] [WARNING] [] [org.jboss.weld.interceptor.util.InterceptionTypeRegistry] [tid: _ThreadID=46 _ThreadName=admin-listener(1)] [timeMillis: 1369227659911] [levelValue: 900] [[
Class 'javax.ejb.PostActivate' not found, interception based on it is not enabled]]

[2013-05-22T06:00:59.913-0700] [glassfish 4.0] [WARNING] [] [org.jboss.weld.interceptor.util.InterceptionTypeRegistry] [tid: _ThreadID=46 _ThreadName=admin-listener(1)] [timeMillis: 1369227659913] [levelValue: 900] [[
Class 'javax.ejb.PrePassivate' not found, interception based on it is not enabled]]

And I think they are reported if a SFSB (in this case) does not define @PostActivate or @PrePassivate callbacks (which are not required)

Comment by Tomas Kraus [ 27/May/13 ]

There is no bug in GlassFish or GlassFish plugin in NetBeans. It's just project configuration issue.

Right click on project: Properties :: Libraries

  • There is Jersey 1.13 listed with Package check box on.

This is wrong because Jersey shall not be bundled. Just turn this check box off and everything will be OK.

...
compile-jsps:
In-place deployment at /users/tomas/WS/WebApplication1/build/web
run-deploy:
Browsing: http://localhost:8080/WebApplication1
run-display-browser:
run:
BUILD SUCCESSFUL (total time: 4 seconds)

Please can you provide more accurate reproduction scenario?

  • How did you open project in NetBeans?
  • What kind of project it was?
  • Did you change anything in Properties :: Libraries settings?

I remember, that we were fixing similar bug few months ago to have Package check box turned off for Jersey when it was used with Glassfish. Maybe there is some regression or it is not working correctly in some cases.

Comment by vanuatoo [ 14/Oct/13 ]

I'm running Netbeans 7.4rc2 with Glassfish 4.0 and Primefaces 4.0
I've created web project and when I deployed it to Glassfish I'm receiving this warning in a log
There is no Jersey in libraries just glassfish

Comment by Romain Grécourt [ 15/Oct/13 ]

I've opened the attached webapplication, I can see "jersey-1.13" with "package" checkbox checked.
When building the war this result into jersey-1.13 being bundled inside the jar.

User bundled library take precedence over appserver provided library, jersey-1.13 can not be used instead of jersey-2.0.
You need to make sure you're not bundling anything in your application that is already provided by the server.

Project propertis / Libraries settings / uncheck jersey.

If you application differs from the one attached, please host it somewhere and share the link.

thanks.

Comment by slominskir [ 23/Jan/14 ]

This issue is not specific to Jersey. If you use Netbeans 7.4 and use the "new Java web application" wizard and just click through the defaults except be sure to check the box to include "contexts and dependency injection", then run it on GlassFish 4 and you'll get the warning.

Comment by spmurphy [ 11/Jun/14 ]

Am also seeing these warning messages logged when our application is deployed. Our ear is built with ant (no jersey or netbeans). Could this be because of update to CDI 1.1 which is more restrictive on what can be injected (from http://apache-wicket.1842946.n4.nabble.com/wicket-cdi-6-9-0-on-Glassfish-4-Warning-WELD-001529-td4659978.html)





[GLASSFISH-20540] PSR:PERF Implicit CDI causing 30% performance regression Created: 16/May/13  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b89_RC5
Fix Version/s: 4.1

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

Tags: 4_0_1-reviewed, PSRBUG

 Description   

Micro benchmarks on EJB local session beans have regressed by 30% in current build. This is because of implicit CDI; if I set cdi-enable-implicit=false, performance reverts to previous levels.

I suspect this is a new weld integration to fix for https://java.net/jira/browse/GLASSFISH-20474 – and the memory leak is fixed, but we are left with the new performance regression.

The WeldListnener is consuming about 30% of total CPU now, particularly in the WeldListener.requestDestroy() method.



 Comments   
Comment by jjsnyder83 [ 22/May/13 ]

I'm not sure there's much we can do about this. As you stated, when you disable implicit cdi you get the same results as before. With implicit cdi enabled cdi is getting involved with the ejbs and so additional processing is happening. If cdi is not required then it should be turned off for maximum performance.

Comment by Scott Oaks [ 22/May/13 ]

I don't think "work as intended" is an accurate description – I don't think the intention of enabling CDI by default is to introduce a 30% performance regression in EJB operations.

We need to look into and optimize the Weld implementation here. If we conclude that it cannot be improved on, then we can figure out next steps. But I suspect, given the size of the penalty, that there is some optimizing we can do. I'll get PSR staff to do some initial analysis (but also, can we check with the Weld implementors and see if they are aware of this, as they were already aware of the memory leak)?

Comment by jjsnyder83 [ 22/May/13 ]

Enabling CDI causes CDI to get involved in all EJB requests so if there's a lot of EJB "action" happening then there's going to be a performance hit when CDI is involved. I agree 30% seems drastic!

It's entirely possible that Weld can improve the implementation and I'll be glad to open a Weld Jira. It would be very helpful if I could provide some more information as well as an application that when run emphasizes the performance hit...Can the PSR staff provide that info?

(btw, The weld guys were not aware of the memory leak until we pointed it out )

Comment by phil.zampino [ 24/Jun/13 ]

After a brief exchange with the Weld lead, I've filed https://issues.jboss.org/browse/WELD-1443

Comment by phil.zampino [ 26/Jun/13 ]

The associated Weld issue is scheduled to be included in Weld 2.0.3.Final





[GLASSFISH-21110] cdi tck failures caused by Jersey Created: 27/Jun/14  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: jax-rs
Affects Version/s: 4.1
Fix Version/s: None

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

Tags: 4_0_1-mustfix

 Description   

testDecoratorsInWebInfClasses(org.jboss.cdi.tck.tests.decorators.ordering.global.EnterpriseDecoratorOrderingTest): null: lists don't have the same size expected:<7> but was:<1>
testDecoratorsInWebInfClasses(org.jboss.cdi.tck.tests.decorators.ordering.global.GlobalDecoratorOrderingTest): null: lists don't have the same size expected:<10> but was:<1>
testScopeTypeDeclaredInheritedIsBlockedByIntermediateScopeTypeNotMarkedInherited(org.jboss.cdi.tck.tests.definition.scope.ScopeDefinitionTest)
arquillianBeforeClass(org.jboss.cdi.tck.tests.extensions.lifecycle.bbd.DeploymentTest): exit_code: FAILURE, message: Error occurred during deployment: Exception while loading the app : CDI definition failure:Type org.jboss.cdi.tck.tests.extensions.lifecycle.bbd.lib.Pro not present. Please see server.log for more details. [status: CLIENT_ERROR reason: Bad Request]
arquillianBeforeClass(org.jboss.cdi.tck.tests.implementation.producer.field.lifecycle.ProducerFieldLifecycleTest): exit_code: FAILURE, message: Error occurred during deployment: Exception while loading the app : CDI deployment failure:WELD-001409: Ambiguous dependencies for type Tarantula with qualifiers @Tame
testNonStaticProducerFieldNotIndirectlyInherited(org.jboss.cdi.tck.tests.implementation.producer.field.definition.ProducerFieldDefinitionTest): WELD-001318: Cannot resolve an ambiguous dependency between:
testNonStaticProducerFieldNotInherited(org.jboss.cdi.tck.tests.implementation.producer.field.definition.ProducerFieldDefinitionTest): WELD-001318: Cannot resolve an ambiguous dependency between:



 Comments   
Comment by Jakub Podlesak [ 30/Jun/14 ]

This has been fixed in Jersey 2.10.1 workspace. Michal is actually cutting the 2.10.1 Jersey release and going to integrate the fix into GF.

Comment by Jakub Podlesak [ 21/Jul/14 ]

The original fix caused regression, which needs to be fixed in Jersey 2.10.2.





[GLASSFISH-21025] Expired certificate: GTE CyberTrust Created: 01/Apr/14  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: security
Affects Version/s: 4.0
Fix Version/s: 4.1

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

GF 4.0 GA ZIP, Win 7 Pro SP1 (64 Bit), JDK 1.8.0 (32 Bit)


Tags: 4_0_1-review

 Description   

After starting GlassFish 4.0 on JDK 1.8.0 I got the following SEVERE message in the server.log. I do not think that it is nice that a freshly installed brand-new GlassFish prints a SEVERE message... Would be better in GlassFish bundles an updates certificate instead.

[2014-04-01T14:45:11.671+0200] [glassfish 4.0] [SEVERE] [java_security.expired_certificate] [javax.enterprise.system.ssl.security.com.sun.enterprise.security.ssl.impl] [tid: _ThreadID=111 _ThreadName=admin-listener(7)] [timeMillis: 1396356311671] [levelValue: 1000] [[
SEC5054: Certificate has expired: [
[
Version: V3
Subject: CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

Key: Sun RSA public key, 2048 bits
modulus: 23741889829347261660812437366387754385443431973861114865490414153884050331745811968523116847625570146592736935209718565296053386842135985534863157983128812774162998053673746470782252407673402238146869994438729551246768368782318393878374421033907597162218758024581735139682087126982809511479059100617027892880227587855877479432885604404402435662802390484099065871430585284534529627347717530352189612077130606642676951640071336717026459037542552927905851171460589361570392199748753414855675665635003335769915908187224347232807336022456537328962095005323382940080676931822787496212635993279098588863972868266229522169377
public exponent: 65537
Validity: [From: Fri Aug 14 16:50:00 CEST 1998,
To: Thu Aug 15 01:59:00 CEST 2013]
Issuer: CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
SerialNumber: [ 01b6]

Certificate Extensions: 4
[1]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:5
]

[2]: ObjectId: 2.5.29.32 Criticality=false
CertificatePolicies [
[CertificatePolicyId: [1.2.840.113763.1.2.1.3]
[] ]
]

[3]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
Key_CertSign
Crl_Sign
]

[4]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 76 0A 49 21 38 4C 9F DE F8 C4 49 C7 71 71 91 9D v.I!8L....I.qq..
]
]

]
Algorithm: [SHA1withRSA]
Signature:
0000: 41 3A D4 18 5B DA B8 DE 21 1C E1 8E 09 E5 F1 68 A:..[...!......h
0010: 34 FF DE 96 F4 07 F5 A7 3C F3 AC 4A B1 9B FA 92 4.......<..J....
0020: FA 9B ED E6 32 21 AA 4A 76 C5 DC 4F 38 E5 DF D5 ....2!.Jv..O8...
0030: 86 E4 D5 C8 76 7D 98 D7 B1 CD 8F 4D B5 91 23 6C ....v......M..#l
0040: 8B 8A EB EA 7C EF 14 94 C4 C6 F0 1F 4A 2D 32 71 ............J-2q
0050: 63 2B 63 91 26 02 09 B6 80 1D ED E2 CC B8 7F DB c+c.&...........
0060: 87 63 C8 E1 D0 6C 26 B1 35 1D 40 66 10 1B CD 95 .c...l&.5.@f....
0070: 54 18 33 61 EC 13 4F DA 13 F7 99 AF 3E D0 CF 8E T.3a..O.....>...
0080: A6 72 A2 B3 C3 05 9A C9 27 7D 92 CC 7E 52 8D B3 .r......'....R..
0090: AB 70 6D 9E 89 9F 4D EB 1A 75 C2 98 AA D5 02 16 .pm...M..u......
00A0: D7 0C 8A BF 25 E4 EB 2D BC 98 E9 58 38 19 7C B9 ....%..-...X8...
00B0: 37 FE DB E2 99 08 73 06 C7 97 83 6A 7D 10 01 2F 7.....s....j.../
00C0: 32 B9 17 05 4A 65 E6 2F CE BE 5E 53 A6 82 E9 9A 2...Je./..^S....
00D0: 53 0A 84 74 2D 83 CA C8 94 16 76 5F 94 61 28 F0 S..t-.....v_.a(.
00E0: 85 A7 39 BB D7 8B D9 A8 B2 13 1D 54 09 34 24 7D ..9........T.4$.
00F0: 20 81 7D 66 7E A2 90 74 5C 10 C6 BD EC AB 1B C2 ..f...t\.......



 Comments   
Comment by Nithya Ramakrishnan [ 02/Apr/14 ]

Removed the expired trustedcert entry from the cacerts.jks in the source repository.

Transmitting file data ....
Committed revision 63173.

Comment by David Delabassee [ 27/Jun/14 ]

The Embedded Container still carry the expired CyberTrust Cert





[GLASSFISH-20081] [UB] javax.ejb.NoSuchEJBException in unsyncpcsfsb with ha Created: 27/Mar/13  Updated: 01/May/13

Status: Reopened
Project: glassfish
Component/s: docs
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: sherryshen Assignee: Mike Fitch
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   

The problem was reported in
http://java.net/jira/browse/GLASSFISH-20020
which can't be accessed for a few days.
Hence, file this bug for failure analysis.
Will close the 20020 later.



 Comments   
Comment by sherryshen [ 27/Mar/13 ]

glassfish-4.0-b82-03_23_2013.zip
During the test dev and failure analysis for
http://java.net/jira/browse/GLASSFISH-20011
I observed javax.ejb.NoSuchEJBException in unsyncpcsfsb with ha.

To run tests, to see env in
http://java.net/jira/browse/GLASSFISH-20011

test2, persist, joinTx, no flush

test2 without ha, passed.
do "ant ee all-dbg"

test2 with ha, failed.
web.xml has <distributable/>
deploy war with --availabilityenabled=true
do "ant ee all-dbg-ha"

server.log from instance2

Error during checkpoint ([TestEJB]. Key:
[1f0090099dfa82de-ce0085b80d45218a-1])
[com.sun.ejb.containers.StatefulSessionContainer$EMNotSerializableException:
java.io.NotSerializableException:
org.eclipse.persistence.internal.jpa.EntityManagerImpl

.....
javax.ejb.NoSuchObjectLocalException: The EJB does not exist.
session-key: 1f0090099dfa82de-ce0085b80d45218a-1
at
com.sun.ejb.containers.StatefulSessionContainer._getContext(StatefulSessionContainer.java:1616)
at
com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2518)
at
com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1908)
.....
javax.ejb.NoSuchEJBException

Comment by sherryshen [ 27/Mar/13 ]

The JPA2.1 test info can be found at
http://aseng-wiki.us.oracle.com/asengwiki/display/ASQA/GF+4.0+Test+Development+Page
As a summary for the bugs on cluster.
1) SFSB tests passed on DAS.
Verified the fix for
http://java.net/jira/browse/GLASSFISH-19597
2) To wrap up my test dev, I ran SFSB tests on a cluster with using
different instances and reported
http://java.net/jira/browse/GLASSFISH-20011
3) Next, I enabled HA to see if it helps for 20011, but it failed with
http://java.net/jira/browse/GLASSFISH-20081
4) After, I tried a simple SFSB tests without JPA, it passed.

I have a hudson run to show to test env and problems.
http://sqe-hudson.us.oracle.com:8080/hudson/view/Sherry_core/job/sherry-lc-d/

#8 dbg failures
http://sqe-hudson.us.oracle.com:8080/hudson/view/Sherry_core/job/sherry-lc-d/8/artifact/appserver-sqe/reports/pe-ee/amd64_easqezorro5_Linux/html/test_results_ejb.html
The 3 tests are executed in the order below.
A) appserver-sqe/pe/ejb/ejb31/fo/sfsb, SFSB with HA, passed
B) appserver-sqe/pe/ejb/jpa20/war/unsyncpcsfsb, SFSB without HA, test2, passed.
C) appserver-sqe/pe/ejb/jpa20/war/unsyncpcsfsb, SFSB with HA, test2, failed. GLASSFISH-20081

#2, ejb-cluster with 1 failure, GLASSFISH-20011
http://sqe-hudson.us.oracle.com:8080/hudson/view/Sherry_core/job/sherry-lc-d/2/artifact/appserver-sqe/reports/pe-ee/amd64_easqezorro5_Linux/html/test_results_ejb.html

Comment by Mitesh Meswani [ 29/Mar/13 ]

As this is related to clustering, deferring this for 4.0.1. Ethan and Quiang will investigate further.

Comment by qiang.l.liu [ 17/Apr/13 ]

If the HA enabled, the SFSB container will try to store the ejb's session context for replication. When the container tries to serialize the context object, a NotSerializableException is thrown up:
com.sun.ejb.containers.StatefulSessionContainer$EMNotSerializableException: java.io.NotSerializableException: org.eclipse.persistence.internal.jpa.EntityManagerImpl, and the EJB is marked with destroyed. This is because the TestEJB has a reference of EntityManager. The EJB's context will be removed after it is marked destroyed. So, when a subsequence call to the EJB, the client will get NoSuchObjectLocalException.

Comment by qiang.l.liu [ 17/Apr/13 ]

After I putting "passivationCapable=false" on TestEJB, the test passed.

So, I'd like resolve the issue as work as designed.

Comment by sherryshen [ 18/Apr/13 ]

Thanks Qiang and Mitesh for the analysis for
http://java.net/jira/browse/GLASSFISH-20081

Here is what I understand the problem.

1) HA Limitation:
EntityManager can't be serialized as a context object in SFSB container for HA replication.
2) Workaround:
Update the @Stateful annotation on TestEJB
to @Stateful(passivationCapable=false), then
JPA will work in ha env without replication
or in non-ha env.

Where are these 2 points in the documents?

I verified the test passed on ha env without replication or non-ha env with b85 nightly.
http://javaweb.us.oracle.com/net/asqe-logs.us.oracle.com/export1/4.0/Results/build85/core/b20081/t1/html/test_results_ejb.html

Comment by sherryshen [ 18/Apr/13 ]

Copy the discussion about doc update.

On 4/17/2013 12:19 PM, Paul Davies wrote:
> Hi Mitesh,
>
> The corresponding section in the GlassFish 3.1.2 High Availability Administration guide is at:
>
> http://docs.oracle.com/cd/E26576_01/doc.312/e24934/session-persistence-and-failover.htm#abdlc .
>
> I have copied Mike Fitch on this response as he is leading the documentation effort for GF 4.0 and he should be able to advise how to proceed.
>
> Regards,
> -Paul
>
> On 4/17/2013 11:58 AM, Mitesh Meswani wrote:
>> Hi Paul,
>>
>> We would like to document the restriction that a SFSB injecting EntityManagers can not be passivated and failed over. Which document would it go to and who is the owner for that? We had a section on restrictions in GlassFish 2.1.1 High Availability Administration guide. I could not find a relevant section in GlassFish 3.1.2 High Availability Administration guide that documents such limitations.
>>
>> Thanks,
>> Mitesh

Comment by sherryshen [ 18/Apr/13 ]

Reopen for Mike Fitch to address the limitation in docs.

Comment by Mike Fitch [ 18/Apr/13 ]

Added [UB] to summary so this issue will appear in unbundled (ie, book-related) doc issues queries

Comment by Mike Fitch [ 18/Apr/13 ]

Also set Component to docs.

Comment by marina vatkina [ 18/Apr/13 ]

This behavior is per the EJB spec 3.2.





[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-20299] ResourceManager run level 2 slows down server initialization Created: 12/Apr/13  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: performance
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.1

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

Issue Links:
Dependency
depends on GLASSFISH-20206 Boot GlassFish startup services in pa... Closed
depends on GLASSFISH-20541 LogManagerService synchronization cau... Resolved
Tags: 4_0-approved, devx_web

 Description   

The ResourceManager service is currently started at run level 2:

@RunLevel( value= 2, mode=RunLevel.RUNLEVEL_MODE_NON_VALIDATING)
@Service(name="ResourceManager") // this name is used in ApplicationLoaderService
public class ResourceManager implements PostConstruct, PreDestroy, ConfigListener {

Once the changes for GLASSFISH-20206 are checked in, then the initialization for ResourceManager will occur by itself while no other initialization is happening. By moving this to @InitRunLevel (level 1), then ResourceManager can be initialize at the same time as other level 1 services and (hopefully) its initialization would not slow down the startup of the server.

This issue is for changing the run level to 1.

It is not clear yet how much of an improvement this will make. Currently, ResourceManager takes about 120 ms to initialize.



 Comments   
Comment by Tom Mueller [ 12/Apr/13 ]

Changing the run level will not result in any change until GLASSFISH-20206 is implemented.

Comment by jwells [ 16/Apr/13 ]

What is the impact on the customer of the bug?

They will see a performance improvement during startup when multi-threading is turned on

What is the cost/risk of fixing the bug?

This particular change is not very risky, it is merely changing a service from run level 2 to run level 1

Is there an impact on documentation or message strings?

No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

connector, jdbc, resources

Which is the targeted build of 4.0 for this fix?

b88

If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.

n/a

Comment by Tom Mueller [ 16/Apr/13 ]

Approved for 4.0

Comment by jwells [ 16/Apr/13 ]

Changed to RunLevel 1 at svn change 61439

Comment by Tom Mueller [ 16/May/13 ]

Backing out this change because of the logging deadlock (see issue GLASSFISH-20541)

Backed out in revision 62021.





[GLASSFISH-20298] Loading of HK2 cache data slows down server initialization Created: 12/Apr/13  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: hk2
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.1

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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-20350 Make DescriptorImpl Externalizable in... Sub-task Closed mtaube  
Tags: devx_web

 Description   

During server startup, the HK2 OSGi adapter reads in a fairly large cache file in the ModuleDefinitionCacheSingleton.loadCachedData method. Typically this is about 400KB of serialized module definition data. This takes anywhere from 100-400 ms and while the server is doing this, it is doing nothing else. The code is started via the bundle start method of the osgi-adapter.jar file.

An idea for improving server start time is to move the reading of the cache file to another thread that runs in parallel with some other initialization work that the server is doing. For example, if it would be possible to initialize just the OSGi bundle(s) that are needed to read this cache first, start the cache-reading thread, and then start then have Felix initialize the rest of the bundles. Then, when the bundles are all initialized, the code that need the cache would already have it available.

Or, if the cache were constructed purely from Java SE objects, then the cache could be read into memory without having to initialize any OSGi bundle.



 Comments   
Comment by Tom Mueller [ 17/Apr/13 ]

I've measured the time required for loadCachedData in both 4.0 and 3.1.2. This is for a subsequent restart, and is an average of 5 runs on a MBP:

4.0: 424 ms ("Felix" start time is 2726 ms), inhabitants size = 516415
3.1.2: 194 ms ("Felix start time is 1615 ms), inhabitants size = 371748

Comment by Tom Mueller [ 30/Apr/13 ]

Note that the only thing fixed here is the GLASSFISH-20350 subtask which reduced the time to read the cache by about 100 ms. This change did not move the cache reading to a parallel thread. It also did not restore the cache reading time to what it was in 3.1.2.

Comment by Tom Mueller [ 01/May/13 ]

Retargeting for 4.0.1 because we have already done what we plan to do in this area for 4.0 via GLASSFISH-20350.





[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-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 services and components to conform with configuration modularity (GLASSFISH-19408)

[GLASSFISH-19522] Diagnostic service configuration to conform with configuration modularity Created: 11/Jan/13  Updated: 01/Feb/13

Status: Reopened
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: 4.0_b71

Type: Sub-task Priority: Major
Reporter: Masoud Kalali Assignee: tvlatas
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by tvlatas [ 16/Jan/13 ]

I grabbed the changes that were listed for removing the DiagnosticService from the templates and reproduced the admin dev test failures here.

I took a look and the problem with the changes is that there apparently is also a org.glassfish.config.support.DefaultConfigUpgrade.postConstruct() which relies on both the order and existence of elements in the domain templates.

When I removed the createDiagnosticServiceConfig(defaultConfig); from the postConstruct() these tests passed.

I'm not familiar with that code, so I don't know if removing that call will have other side effects, so I may find other issues as I test this out.

Comment by tvlatas [ 18/Jan/13 ]

quick update on the testing.

The admin dev tests for upgrade are failing for me with the above mentioned change I made, but they appear to be unrelated to my change and looks more like those tests don't run properly on JDK 7:

[java] Exception in thread "main" MultiException stack 1 of 2
[java] java.lang.UnsupportedClassVersionError: com/sun/enterprise/admin/cli/optional/BackupDomainCommand : Unsupported major.minor version 51.0
[java] at java.lang.ClassLoader.defineClass1(Native Method)
[java] at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
[java] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
[java] at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)

Comment by tvlatas [ 18/Jan/13 ]

Found the problem the issue was that while the JAVA_HOME was set, the PATH was still finding an older version of the JDK (so thus the mismatch).

Setting the path to the JDK 1.7 and rerunning the tests passed.

I'm going to rerun the full set locally, but it looks like this change should be OL.

Comment by tvlatas [ 01/Feb/13 ]

Revision 58967 was committed to address this

Comment by tvlatas [ 01/Feb/13 ]

In reviewing the one-pager for config modularity, I believe that the original set of changes the config team had listed to resolve this on their wiki was insufficient. It only addressed the domain defaults.

The DiagnosticService configuration allows extensions, and the pattern for that is changing, so we also need to review and update to align with the new pattern/annotations there now as well.





[GLASSFISH-19662] [osgi/javaee-base] wab fragment deployed using deploy command is not working Created: 11/Feb/13  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 4.0_b89_RC5
Fix Version/s: 4.1

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

Attachments: Text File T2_Test_19662.patch    
Issue Links:
Duplicate
is duplicated by GLASSFISH-16096 WARNINGs during deployment: Invalid z... Closed
is duplicated by GLASSFISH-16441 WAB fragments don't work for applicat... Closed

 Description   

asadmin deploy --type osgi sample.uas.simplewab-1.0.0.war
asadmin deploy --type osgi sample.uas.simplewabfragment-1.0.0.jar
http://localhost:8080/uas/report.jsp is not accessible.

Now undeploy sample.uas.simplewabfragment-1.0.0 and deploy using:
asadmin osgi install file:.../sample.uas.simplewabfragment-1.0.0.jar
asadmin update <samplewab>
Access the URL. It will work.



 Comments   
Comment by Sanjeeb Sahoo [ 11/Feb/13 ]

Tang,

See if you can fix it.

Sahoo

Comment by TangYong [ 16/Feb/13 ]

Sahoo,

firstly, the issue can be re-produced in my env. Slightly complementing the re-produce steps in "Description",

[Steps]
1 asadmin deploy --type=osgi sample.uas.api.jar

2 asadmin deploy --type=osgi sample.uas.simplewab.war

3 asadmin deploy --type=osgi simplewabfragment\target\sample.uas.simplewabfragment.jar

4 http://localhost:8080/uas/report.jsp is not accessible.

5 asadmin undeploy sample.uas.simplewabfragment

6 asadmin osgi install file:///.../sample.uas.simplewabfragment.jar

7 asadmin osgi update <sample.uas.simplewab's bundle Id>

8 http://localhost:8080/uas/report.jsp can be accessible.

Secondly, I noticed that the result of executing step 7 made simplewabfragment's state changed into "Resolved" from "Installed" , however, after step 3, simplewabfragment's state is still in "Installed" (in theory, it should be in "Resolved"). So, I start to make an experiment as following:

After step 3, I executed step 7 and found that although simplewabfragment's state changed into "Resolved" from "Installed", http://localhost:8080/uas/report.jsp is still not accessible and in server.log, I found the following exception(Bundle291 is simplewabfragment),

[#|2013-02-16T17:23:33.109+0900|INFO|glassfish 4.0|org.glassfish.osgijavaeebase|_ThreadID=101;_ThreadName=admin-listener(2);_TimeMillis=1361003013109;_LevelValue=800;|Deleted C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\osgiapp7602417806711521704|#]

[#|2013-02-16T17:23:33.109+0900|INFO|glassfish 4.0|org.glassfish.osgijavaeebase|_ThreadID=101;_ThreadName=admin-listener(2);_TimeMillis=1361003013109;_LevelValue=800;|Undeployed bundle org.glassfish.fighterfish.sample.uas.simplewab [290]|#]

[#|2013-02-16T17:23:33.468+0900|INFO|glassfish 4.0|org.glassfish.osgijavaeebase|_ThreadID=78;_ThreadName=pool-21-thread-1;_TimeMillis=1361003013468;_LevelValue=800;|Expanded at file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/|#]

[#|2013-02-16T17:23:33.484+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=85;_ThreadName=deployment-jar-scanner;_TimeMillis=1361003013484;_LevelValue=900;_MessageID=NCLS-DEPLOYMENT-00019;|file open failure; file = file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.484+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=85;_ThreadName=deployment-jar-scanner;_TimeMillis=1361003013484;_LevelValue=900;_MessageID=NCLS-DEPLOYMENT-00020;|exception message: error in opening zip file -- invalid zip file: invalid zip file: file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.500+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=92;_ThreadName=deployment-jar-scanner;_TimeMillis=1361003013500;_LevelValue=900;_MessageID=NCLS-DEPLOYMENT-00019;|file open failure; file = file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.500+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=92;_ThreadName=deployment-jar-scanner;_TimeMillis=1361003013500;_LevelValue=900;_MessageID=NCLS-DEPLOYMENT-00020;|exception message: error in opening zip file -- invalid zip file: invalid zip file: file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.500+0900|SEVERE|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=92;_ThreadName=deployment-jar-scanner;_TimeMillis=1361003013500;_LevelValue=1000;|Exception while parsing file file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar
java.lang.NullPointerException
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$ArchiveJarEntrySource.<init>(InputJarArchive.java:581)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$ArchiveJarEntrySource.<init>(InputJarArchive.java:573)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.createEntryEnumeration(InputJarArchive.java:451)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.entries(InputJarArchive.java:203)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.entries(InputJarArchive.java:182)
at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:122)
at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:347)
at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:67)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:306)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:295)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

#]

[#|2013-02-16T17:23:33.500+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=78;_ThreadName=pool-21-thread-1;_TimeMillis=1361003013500;_LevelValue=900;|result fault org.glassfish.hk2.classmodel.reflect.Parser$Result@1cdcebc Result for /C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.515+0900|INFO|glassfish 4.0|org.glassfish.osgiweb|_ThreadID=78;_ThreadName=pool-21-thread-1;_TimeMillis=1361003013515;_LevelValue=800;|uris = file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/classes/, file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.515+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=78;_ThreadName=pool-21-thread-1;_TimeMillis=1361003013515;_LevelValue=900;_MessageID=NCLS-DEPLOYMENT-00019;|file open failure; file = file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.515+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=78;_ThreadName=pool-21-thread-1;_TimeMillis=1361003013515;_LevelValue=900;_MessageID=NCLS-DEPLOYMENT-00020;|exception message: error in opening zip file -- invalid zip file: invalid zip file: file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.531+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=78;_ThreadName=pool-21-thread-1;_TimeMillis=1361003013531;_LevelValue=900;_MessageID=NCLS-DEPLOYMENT-00019;|file open failure; file = file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.531+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=78;_ThreadName=pool-21-thread-1;_TimeMillis=1361003013531;_LevelValue=900;_MessageID=NCLS-DEPLOYMENT-00020;|exception message: error in opening zip file -- invalid zip file: invalid zip file: file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.578+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=78;_ThreadName=pool-21-thread-1;_TimeMillis=1361003013578;_LevelValue=900;_MessageID=NCLS-DEPLOYMENT-00019;|file open failure; file = file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]
...

Tomorrow, I will see the source in depth and continue to analyze the true reason.

Thanks(Happy new year!)
--Tang

Comment by TangYong [ 17/Feb/13 ]

Firstly, the true reason has been found, and simply saying as following:

While deploying or installing a wab with some fragments, osgi framework merges these fragments's metadata with the host’s and resolves the host bundle as normal. Sahoo has done it by expanding the wab(including the contents of fragment) into os's temp directory. While expanding, the fragment jar will be put into expanded directory's WEB-INF/lib), eg. on my env, liking C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\osgiapp3989882632779875557\WEB-INF\lib\Bundle290.jar. This also explained why we can see some log info liking "DOCUME~1/ADMINI~1/LOCALS~1/" in server.log.

However, Because "WEB-INF/lib/bundleXXX.jar" is not a valid jar, the issue happened.

The reason of not a valid jar is that in org.glassfish.osgijavaeebase.OSGiBundleArchive.getInputStream()(this method can be used while expanding), while using "asadmin deploying ..." to deploy a host bundle, the following code:

if (uri != null)

{ return uri.toURL().openStream(); }

else

{ ... }

uri specifies a domains/domain1/application/<fragment name>, and it is a directory form uri not jar form, so, in this case, openStream() can not return a valid inputstream.

Secondly, my fixing way is as following:

if (uri != null && !new File(uri).isDirectory()) { return uri.toURL().openStream(); }else{ ... }

Adding a judge and going "else" path.

The fixing way has passed my test and wish sahoo can confirm the fixing way(or whether having better way).

BTW: test steps have a slight change, and have two ways:

[Way1]
1 asadmin deploy --type=osgi sample.uas.api.jar

2 asadmin deploy --type=osgi sample.uas.simplewab.war

3 asadmin deploy --type=osgi simplewabfragment\target\sample.uas.simplewabfragment.jar

4 asadmin osgi update <sample.uas.simplewab's bundle Id>

5 access http://localhost:8080/uas/report.jsp

[Way2]
1 asadmin deploy --type=osgi sample.uas.api.jar

2 asadmin deploy --type=osgi simplewabfragment\target\sample.uas.simplewabfragment.jar

3 asadmin deploy --type=osgi sample.uas.simplewab.war

4 access http://localhost:8080/uas/report.jsp

--Tang

Comment by Sanjeeb Sahoo [ 18/Feb/13 ]

Tang,

Your analysis is spot on.

Can you post the diff in JIRA or email me the patch?

While I am reviewing your change, can you please run fighterfish tests (mvn clean test -f fighterfish/test/it/pom.xml) with your change?

Can you also add a test case in test/it/src/test/java/org/glassfish/fighterfish/test/it/T2_Test.java to capture this scenario? Call the test method test_GLASSFISH_19662().

Thanks,
Sahoo

Comment by TangYong [ 18/Feb/13 ]

Sahoo,

>Can you post the diff in JIRA or email me the patch?

Index: OSGiBundleArchive.java
===================================================================
— OSGiBundleArchive.java (revision 58798)
+++ OSGiBundleArchive.java (working copy)
@@ -334,8 +334,8 @@

  • @return a Jar format InputStream for this bundle's content
    */
    public InputStream getInputStream() throws IOException {
  • if (uri != null) {
  • return uri.toURL().openStream();
    + if (uri != null && !new File(uri).isDirectory()) { + return uri.toURL().openStream(); }

    else {
    // create a JarOutputStream on the fly from the bundle's content
    // Can we optimize by reading off Felix's cache? Investigate in future.

I will do other tasks.

Thanks
Tang

Comment by TangYong [ 19/Feb/13 ]

Task1:

>While I am reviewing your change, can you please run fighterfish tests (mvn clean test -f fighterfish/test
>/it/pom.xml) with your change?

This has been done.

...
Completed shutdown of GlassFish runtime
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling SLF4J API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling Jakarta Commons Logging API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling Log4J API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling Avalon Logger API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling JULI Logger API support.
Tests run: 25, Failures: 0, Errors: 0, Skipped: 4, Time elapsed: 152.312 sec

Results :

Tests run: 29, Failures: 0, Errors: 0, Skipped: 5

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
...

Comment by TangYong [ 19/Feb/13 ]

A litter change needing to commit into trunk

Index: OSGiBundleArchive.java
===================================================================
— OSGiBundleArchive.java (revision 59590)
+++ OSGiBundleArchive.java (working copy)
@@ -1,7 +1,7 @@
/*

  • DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
    *
  • * Copyright (c) 2009-2012 Oracle and/or its affiliates. All rights reserved.
    + * Copyright (c) 2009-2013 Oracle and/or its affiliates. All rights reserved.
    *
  • The contents of this file are subject to the terms of either the GNU
  • General Public License Version 2 only ("GPL") or the Common Development
Comment by TangYong [ 19/Feb/13 ]

Task2:

>Can you also add a test case in test/it/src/test/java/org/glassfish/fighterfish/test/it/T2_Test.java to capture this
>scenario? Call the test method test_GLASSFISH_19662().

Done. The following is fighterfish's test result:

...
Completed shutdown of GlassFish runtime
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling SLF4J API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling Jakarta Commons Logging API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling Log4J API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling Avalon Logger API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling JULI Logger API support.
Tests run: 26, Failures: 0, Errors: 0, Skipped: 4, Time elapsed: 213 sec

Results :

Tests run: 30, Failures: 0, Errors: 0, Skipped: 5

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5:44.954s
...

However, according to sahoo's comments:

"when you add a test, mark it @Ignore. I will remove @Ignore when I integrate the new version of osgi-javaee-base.",

I will mark the test as @Ignore and commit into trunk.

Thanks
--Tang

Comment by TangYong [ 20/Feb/13 ]

[Sahoo's comments for current test]

Adding accessing /report.jsp as well to make sure that even resource processing is happening correctly.

Comment by TangYong [ 20/Feb/13 ]

This has been done and passed my fighterfish test.

Index: T2_Test.java
===================================================================
— T2_Test.java (revision 59589)
+++ T2_Test.java (working copy)
@@ -1,7 +1,7 @@
/*

  • DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
    *
  • * Copyright (c) 2011-2012 Oracle and/or its affiliates. All rights reserved.
    + * Copyright (c) 2011-2013 Oracle and/or its affiliates. All rights reserved.
    *
  • The contents of this file are subject to the terms of either the GNU
  • General Public License Version 2 only ("GPL") or the Common Development
    @@ -801,6 +801,51 @@
    tc.destroy();
    }
    }
    +
    + /**
    + * Regression test case for GLASSFISH_19662
    + *
    + * @throws GlassFishException
    + * @throws InterruptedException
    + * @throws BundleException
    + */
    + @Test
    + @Ignore //mark it @Ignore temply until when integrating the new version of osgi-javaee-base
    + public void test_GLASSFISH_19662() throws GlassFishException, InterruptedException, BundleException, IOException {
    + logger.logp(Level.INFO, "T2_Test", "test_GLASSFISH_19662", "ENTRY");
    + TestContext tc = TestContext.create(getClass());
    + try
    Unknown macro: {+ //firstly, we install sample.uas.api bundle+ String location = "mvn}

    finally

    { + tc.destroy(); + }

    + }

//////////////////////////////////////////////////////////////////
// Various utility methods used from test methods are found below.

Comment by Sanjeeb Sahoo [ 23/Feb/13 ]

svn commit details:
#59590: osgi-javaee-base module fixed
#59560: Test case added.
#59799: RELEASENOTE.txt updated.

Comment by Sanjeeb Sahoo [ 27/Mar/13 ]

Integrated osgi-javaee-base:1.0.6 with glassfish trunk in svn #60905, so marking the bug as resolved.

Comment by TangYong [ 28/May/13 ]

FighterFish Test Case should use "deploy command" rather than using OSGi API. So, reopening the issue and will fix test case.

Comment by TangYong [ 27/Aug/13 ]

A patch has been sent into Sahoo and will wait for his reviewing.

Comment by TangYong [ 28/Aug/13 ]

Based on Sahoo's reviewing and new confirmation for util class, a new patch has been attached, the patch has passed fighterfish regression test. In addition, URLHelper has offered a method to do simple get request.

Pl. confirming the patch, thanks.

Tang

Comment by Sanjeeb Sahoo [ 28/Aug/13 ]

looks good to be checked in.

Comment by TangYong [ 28/Aug/13 ]

Done.

Revisions:
----------
62665





[GLASSFISH-18579] jar file not closed when Application is undeployed from directory Created: 30/Mar/12  Updated: 04/Apr/12

Status: Reopened
Project: glassfish
Component/s: ide-integration
Affects Version/s: 3.1.2
Fix Version/s: None

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

java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)


Attachments: Zip Archive testcase.zip    

 Description   

How to reproduce:

  • Create a 1.5.5 quickstart
  • deploy it on the GlassFish server with directory deployment (I use NetBeans which is easy)
  • open the application in the browser
  • undeploy the application
  • try to execute the maven clean goal or try to delete the target dir

Error in GlassFish log:
Unable to delete file WEB-INF\lib\wicket-core-1.5.5.jar

Please see my failed attempt to classify this as a framework issue.

It appears that the result of the tool at

https://blogs.oracle.com/quinn/entry/tool_for_diagnosing_failed_glassfish

is misleading.



 Comments   
Comment by Tim Quinn [ 30/Mar/12 ]

Please see my comments at the wicket issue: https://issues.apache.org/jira/browse/WICKET-4458

It is not yet at all clear to me that this is a GlassFish issue. The Wicket code is opening a stream using a jar: URL, and this is known to trigger behavior in Java SE which leaves the JAR open. I have suggested a possible change in the wicket code that might help this. As he mentioned, Bernard used the ZipFileMonitor tool and posted the stack trace in the wicket issue.

As I explained in the wicket issue where Bernard mentioned this and in a response to his comment on my blog, I am not convinced this is a GlassFish bug or that there is a problem in the tool. The Java SE code triggered by wicket has opened the JAR and not closed it. That's why GlassFish (or any other process) cannot delete the file and why the output from the tool shows an open file.

Comment by Shing Wai Chan [ 02/Apr/12 ]

This is a duplicate of GLASSFISH-18376.

Comment by Shing Wai Chan [ 04/Apr/12 ]

This is not related to GLASSFISH-18376 as I can deploy / access / undeploy the app in window using asadmin. The scenario under IDE may be different.





[GLASSFISH-18482] WEB9031: WebappClassLoader unable to load resource Created: 08/Mar/12  Updated: 10/Jul/12

Status: Reopened
Project: glassfish
Component/s: jax-rs
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: cowwoc Assignee: Pavel Bucek
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Netbeans 7.1.1, Glassfish 3.1.2, JDK7 update 2


Attachments: Zip Archive HomesForHumans.zip    

 Description   

I don't know if this is related to GLASSFISH-14416 but every time I deploy my webapp on a fresh Glassfish instance I get this error:

INFO: Scanning for root resource and provider classes in the packages:
  com.homesforhumans.resource
INFO: Root resource classes found:
  class com.homesforhumans.resource.PostalCodesResource
INFO: No provider classes found.
INFO: Initiating Jersey application, version 'Jersey: 1.12 02/15/2012 04:51 PM'
INFO: WEB0671: Loading application [com.homesforhumans_HomesForHumans_war_1.0-SNAPSHOT] at [/context]
INFO: com.homesforhumans_HomesForHumans_war_1.0-SNAPSHOT was successfully deployed in 2,238 milliseconds.
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: Grizzly Framework 1.9.46 started in: 3ms - bound to [0.0.0.0:8181]
SEVERE: The RuntimeException could not be mapped to a response, re-throwing to the HTTP container
java.lang.IllegalStateException: WEB9031: WebappClassLoader unable to load resource [javax.ws.rs.core.Response$Status], because it has not yet been started, or was already stopped
	at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1401)
	at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1359)
	at com.sun.jersey.core.spi.factory.ResponseBuilderImpl.<init>(ResponseBuilderImpl.java:67)
	at com.sun.jersey.core.spi.factory.AbstractRuntimeDelegate.createResponseBuilder(AbstractRuntimeDelegate.java:99)
	at javax.ws.rs.core.Response$ResponseBuilder.newInstance(Response.java:356)
	at javax.ws.rs.core.Response.status(Response.java:104)
	at com.sun.jersey.api.Responses.status(Responses.java:127)
	at com.sun.jersey.api.Responses.notFound(Responses.java:103)
	at com.sun.jersey.api.NotFoundException.<init>(NotFoundException.java:68)
	at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1484)
	at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1414)
	at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1363)
	at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1353)
	at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:414)
	at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)
	at com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:895)
	at com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:843)
	at com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:804)
	at com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:163)
	at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
	at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:118)
	at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:113)

I'm attaching my project file for your review.



 Comments   
Comment by Shing Wai Chan [ 28/Mar/12 ]

I notice the following incorrect elements in glassfish-web.xml
9a10,13
> <sun-web-app error-url="">
> <context-root>/context</context-root>
> <class-loader delegate="false"/>
> </sun-web-app>
10a15,18
> <sun-web-app error-url="">
> <context-root>/context</context-root>
> <class-loader delegate="false"/>
> </sun-web-app>

I have fixed the app in my local env.
It is deployed in 3.1.2 without error in server.log. But the app cannot be accessed.

When it is deployed in the 4.0 trunk, I saw the following in server.log:
[#|2012-03-28T14:06:42.492-0700|SEVERE|44.0|com.sun.jersey.core.spi.component.ProviderFactory|_ThreadID=72;_ThreadName=Thread-2;|The provider class, class com.sun.jersey.moxy.MoxyMessageBodyWorker, could not be instantiated. Processing will continue but the class will not be utilized
java.lang.NullPointerException
at com.sun.jersey.moxy.MoxyMessageBodyWorker.<init>(MoxyMessageBodyWorker.java:84)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at com.sun.jersey.core.spi.component.ComponentConstructor._getInstance(ComponentConstructor.java:209)
at com.sun.jersey.core.spi.component.ComponentConstructor.getInstance(ComponentConstructor.java:179)
at com.sun.jersey.core.spi.component.ProviderFactory.__getComponentProvider(ProviderFactory.java:166)
at com.sun.jersey.core.spi.component.ProviderFactory.getComponentProvider(ProviderFactory.java:137)
at com.sun.jersey.core.spi.component.ProviderServices.getComponent(ProviderServices.java:256)
at com.sun.jersey.core.spi.component.ProviderServices.getServices(ProviderServices.java:160)
at com.sun.jersey.core.spi.factory.MessageBodyFactory.initReaders(MessageBodyFactory.java:176)
at com.sun.jersey.core.spi.factory.MessageBodyFactory.init(MessageBodyFactory.java:162)
at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1287)
at com.sun.jersey.server.impl.application.WebApplicationImpl.access$700(WebApplicationImpl.java:171)
at com.sun.jersey.server.impl.application.WebApplicationImpl$13.f(WebApplicationImpl.java:777)
at com.sun.jersey.server.impl.application.WebApplicationImpl$13.f(WebApplicationImpl.java:773)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:773)
at com.sun.jersey.guice.spi.container.servlet.GuiceContainer.initiate(GuiceContainer.java:121)
at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:318)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:607)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:208)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:719)
at com.google.inject.servlet.FilterDefinition.init(FilterDefinition.java:114)
at com.google.inject.servlet.ManagedFilterPipeline.initPipeline(ManagedFilterPipeline.java:98)
at com.google.inject.servlet.GuiceFilter.init(GuiceFilter.java:172)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:264)
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:120)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4857)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5549)
at com.sun.enterprise.web.WebModule.start(WebModule.java:499)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:936)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:920)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:733)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2010)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1660)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:107)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:301)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:512)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:262)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:414)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:351)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:366)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1075)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:98)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1308)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1276)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:479)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:223)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:293)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:163)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:164)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:78)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:816)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
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:567)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:547)
at java.lang.Thread.run(Thread.java:722)

#]

[#|2012-03-28T14:06:42.495-0700|SEVERE|44.0|com.sun.jersey.core.spi.component.ProviderFactory|_ThreadID=72;_ThreadName=Thread-2;|The provider class, class com.sun.jersey.moxy.MoxyListMessageBodyWorker, could not be instantiated. Processing will continue but the class will not be utilized
java.lang.NullPointerException
at com.sun.jersey.moxy.MoxyMessageBodyWorker.<init>(MoxyMessageBodyWorker.java:84)
at com.sun.jersey.moxy.MoxyListMessageBodyWorker.<init>(MoxyListMessageBodyWorker.java:72)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at com.sun.jersey.core.spi.component.ComponentConstructor._getInstance(ComponentConstructor.java:209)
at com.sun.jersey.core.spi.component.ComponentConstructor.getInstance(ComponentConstructor.java:179)
at com.sun.jersey.core.spi.component.ProviderFactory.__getComponentProvider(ProviderFactory.java:166)
at com.sun.jersey.core.spi.component.ProviderFactory.getComponentProvider(ProviderFactory.java:137)
at com.sun.jersey.core.spi.component.ProviderServices.getComponent(ProviderServices.java:256)
at com.sun.jersey.core.spi.component.ProviderServices.getServices(ProviderServices.java:160)
at com.sun.jersey.core.spi.factory.MessageBodyFactory.initReaders(MessageBodyFactory.java:176)
at com.sun.jersey.core.spi.factory.MessageBodyFactory.init(MessageBodyFactory.java:162)
at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1287)
at com.sun.jersey.server.impl.application.WebApplicationImpl.access$700(WebApplicationImpl.java:171)
at com.sun.jersey.server.impl.application.WebApplicationImpl$13.f(WebApplicationImpl.java:777)
at com.sun.jersey.server.impl.application.WebApplicationImpl$13.f(WebApplicationImpl.java:773)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:773)
at com.sun.jersey.guice.spi.container.servlet.GuiceContainer.initiate(GuiceContainer.java:121)
at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:318)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:607)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:208)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:719)
at com.google.inject.servlet.FilterDefinition.init(FilterDefinition.java:114)
at com.google.inject.servlet.ManagedFilterPipeline.initPipeline(ManagedFilterPipeline.java:98)
at com.google.inject.servlet.GuiceFilter.init(GuiceFilter.java:172)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:264)
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:120)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4857)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5549)
at com.sun.enterprise.web.WebModule.start(WebModule.java:499)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:936)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:920)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:733)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2010)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1660)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:107)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:301)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:512)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:262)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:414)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:351)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:366)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1075)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:98)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1308)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1276)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:479)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:223)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:293)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:163)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:164)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:78)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:816)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
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:567)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:547)
at java.lang.Thread.run(Thread.java:722)

#]

[#|2012-03-28T14:06:42.501-0700|SEVERE|44.0|com.sun.jersey.core.spi.component.ProviderFactory|_ThreadID=72;_ThreadName=Thread-2;|The provider class, class com.sun.jersey.multipart.impl.MultiPartReaderServerSide, could not be instantiated. Processing will continue but the class will not be utilized
java.lang.IllegalArgumentException: The MultiPartConfig instance we expected is not present. Have you registered the MultiPartConfigProvider class?
at com.sun.jersey.multipart.impl.MultiPartReaderClientSide.<init>(MultiPartReaderClientSide.java:102)
at com.sun.jersey.multipart.impl.MultiPartReaderServerSide.<init>(MultiPartReaderServerSide.java:71)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at com.sun.jersey.core.spi.component.ComponentConstructor._getInstance(ComponentConstructor.java:209)
at com.sun.jersey.core.spi.component.ComponentConstructor.getInstance(ComponentConstructor.java:179)
at com.sun.jersey.core.spi.component.ProviderFactory.__getComponentProvider(ProviderFactory.java:166)
at com.sun.jersey.core.spi.component.ProviderFactory.getComponentProvider(ProviderFactory.java:137)
at com.sun.jersey.core.spi.component.ProviderServices.getComponent(ProviderServices.java:256)
at com.sun.jersey.core.spi.component.ProviderServices.getServices(ProviderServices.java:160)
at com.sun.jersey.core.spi.factory.MessageBodyFactory.initReaders(MessageBodyFactory.java:176)
at com.sun.jersey.core.spi.factory.MessageBodyFactory.init(MessageBodyFactory.java:162)
at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1287)
at com.sun.jersey.server.impl.application.WebApplicationImpl.access$700(WebApplicationImpl.java:171)
at com.sun.jersey.server.impl.application.WebApplicationImpl$13.f(WebApplicationImpl.java:777)
at com.sun.jersey.server.impl.application.WebApplicationImpl$13.f(WebApplicationImpl.java:773)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:773)
at com.sun.jersey.guice.spi.container.servlet.GuiceContainer.initiate(GuiceContainer.java:121)
at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:318)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:607)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:208)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:719)
at com.google.inject.servlet.FilterDefinition.init(FilterDefinition.java:114)
at com.google.inject.servlet.ManagedFilterPipeline.initPipeline(ManagedFilterPipeline.java:98)
at com.google.inject.servlet.GuiceFilter.init(GuiceFilter.java:172)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:264)
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:120)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4857)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5549)
at com.sun.enterprise.web.WebModule.start(WebModule.java:499)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:936)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:920)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:733)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2010)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1660)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:107)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:301)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:512)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:262)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:414)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:351)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:366)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1075)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:98)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1308)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1276)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:479)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:223)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:293)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:163)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:164)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:78)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:816)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
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:567)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:547)
at java.lang.Thread.run(Thread.java:722)

#]
Comment by cowwoc [ 14/Jun/12 ]

This error only seems to occur when overriding the built-in version of Glassfish by setting:

<class-loader delegate="false"/>
Comment by cowwoc [ 14/Jun/12 ]

Shing Wai Chan,

I don't understand your last post. What are the incorrect elements in glassfish.xml? It looks right to me.

Comment by cowwoc [ 14/Jun/12 ]

Good news! It looks like this issue is caused by setting:

<class-loader delegate="false"/>

in glassfish.xml but neglecting to set:

-Dcom.sun.enterprise.overrideablejavaxpackages=javax.ws.rs,javax.ws.rs.core,javax.ws.rs.ext

in domain.xml. The full instructions can be found here: http://jersey.java.net/nonav/documentation/latest/glassfish.html#d4e1903

In light of this discovery, is there a way to get Glassfish to throw a less misleading error message?

Also, can anyone reproduce this error in spite of following the above steps?

Comment by Pavel Bucek [ 15/Jun/12 ]

not about jersey anymore, user requests change in error reporting.

btw see http://java.net/jira/browse/GLASSFISH-13134 for full context.

Comment by Shing Wai Chan [ 09/Jul/12 ]

In Java EE 6, we cannot override the javax.* packages even with delegate flag.
We will mark this as a duplicate of the improvement task has been filed http://java.net/jira/browse/GLASSFISH-13134 .

Comment by cowwoc [ 10/Jul/12 ]

Shing,

Regardless of when GLASSFISH-13134 is implemented, we need to improve the error message. GLASSFISH-13134 does not cover this. Can we reopen this issue?

Comment by Shing Wai Chan [ 10/Jul/12 ]

Per request, we will reopen the bug for a better error message.





[GLASSFISH-17934] Support SNI (server name indication) Created: 08/Dec/11  Updated: 11/Mar/14

Status: Reopened
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: foal Assignee: oleksiys
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Support SNI (server name indication) to allows multiple SSL Certificates on a Single IP/Port



 Comments   
Comment by Ryan Lubke [ 28/Feb/13 ]

If SNI support is desired, I would recommend switching to JDK 7 [1].

[1] http://docs.oracle.com/javase/7/docs/technotes/guides/security/enhancements-7.html

Comment by oleksiys [ 11/Mar/14 ]

implemented in Grizzly [1], we can think how to promote it to Glassfish.

[1] https://java.net/jira/browse/GRIZZLY-1661





[GLASSFISH-18266] Unlocalized strings in the output of the commands Created: 30/Jan/12  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: l10n
Affects Version/s: 3.1.2_b19
Fix Version/s: 4.1

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

Server OS: OEL 6 x64 w/JDK 1.6.0_30 64-Bit
Bundle: ogs-3.1.2-b20_01_29_2012-ml.zip
Server Locale: ja_JP.UTF-8


Attachments: HTML File report.all.html    
Issue Links:
Dependency
depends on GLASSFISH-19844 main-docs-l10n: need help to set up t... Resolved
Tags: 4_0-approved, l10n

 Description   

Unlocalized strings in the output of the commands

To reproduce:
After unzip the bundle, open a terminal window and execute one of the following commands.

asadmin enable-secure-admin --help
asadmin enable-secure-admin
asadmin create-node-ssh
asadmin verify-domain-xml
asadmin generate-domain-schema
asadmin validate-multicast
asadmin list-modules
asadmin create-password-alias --help
asadmin list-password-aliases --help
asadmin list-password-aliases
asadmin update-password-alias --help
asadmin delete-password-alias --help
asadmin list-instances
asadmin list-clusters

There are unlocalized strings in the output of the commands.
Attached results file for your reference.



 Comments   
Comment by sunny-gui [ 31/Jan/12 ]

Verified with the bundle "ogs-3.1.2-b20_01_29_2012-ml.zip" in OEL 6 x64, there are also unlocalized strings when running following commands.

asadmin disable-secure-admin
asadmin backup-domain domainName
asadmin list-backups
asadmin restore-domain domainName
asadmin start-instance insName

Comment by gmurr [ 05/Feb/12 ]

fixed in 3.1.2 b21

Comment by sunny-gui [ 08/Feb/12 ]

Verified in GF 3.1.2 b21 with the bundle "ogs-3.1.2-b21-unix-ml.sh" in OEL 6 x64 w/JDK1.6.0_30 32-Bit, fixed some of the issues, but the following commands output are still not localized.

asadmin generate-domain-schema
asadmin validate-multicast
asadmin list-modules
asadmin list-instances
asadmin list-clusters
asadmin backup-domain domainName
asadmin list-backups
asadmin restore-domain

Comment by sunny-gui [ 10/Feb/12 ]

As mentioned above, for some of the commands this issue is reproducible, so reopen it.

Comment by clyang [ 28/Mar/13 ]

This depends on a succcessful build and publish into maven repository for main-docs-l10n.

Comment by clyang [ 04/Apr/13 ]
  • What is the impact on the customer of the bug?

How likely is it that a customer will see the bug and how serious is the bug?
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
What CTS failures are caused by this bug?

This integration will incorporate the localized version of on-line help and man pages into Glassfish workspace.

  • What is the cost/risk of fixing the bug?

How risky is the fix? How much work is the fix? Is the fix complicated?

Low risk. This integration will add localized version of on-line help and man pages. Changes are made to pom.xml to add a plugin which will zip up the l10n doc files into the distributions.

  • Is there an impact on documentation or message strings?

No

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

Once this is integrated into the build, QA can run on-line help and man pages of the supported l10n languages in Glassfish.

  • Which is the targeted build of 4.0 for this fix?

Next available build - should be 4.0_b85.

  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.

N/A

Comment by clyang [ 10/Apr/13 ]

Fix will be available in the next Glassfish 4.0 build.

Comment by clyang [ 10/Apr/13 ]

The localized online help and man pages have been checked into main-docs-l10n.
The build #4 has been released to maven central.
The fix should be available in the next Glassfish build.

Comment by clyang [ 10/Apr/13 ]

Assign to Sunny to verify the fix in the next Glassfish build.

Comment by sunny-gui [ 22/May/13 ]

Verified with bundle 'glassfish-4.0-b89-windows-ml.exe' in Windows 7 ENT SP1 x64 zh_CN Native, it is reproducible.





[GLASSFISH-15304] No information about validation constraints used in password alias Created: 21/Dec/10  Updated: 04/Mar/11

Status: Reopened
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b33
Fix Version/s: 3.1_b41

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

build: ogs-3.1-b34-12_21_2010.zip


Attachments: JPEG File password-not-accepted.JPG    

 Description   

Go to Domain tree node, Password Aliases tab and click New. Attempt to create a password alias, where password is one space character - after hitting save password fields are cleared and labels next to them become red. No information is displayed as to what are valid passwords/what validation constraints are used.



 Comments   
Comment by Anissa Lam [ 14/Feb/11 ]

Tested with latest 3.1, this is working correctly. There shouldn't be any restriction on the length of passwor.
Marking as resolved.

Comment by lidiam [ 04/Mar/11 ]

Tried on promoted build b43 - after entering one space character as password - it is not accepted, but no error message is displayed nor explanation about the password restriction. Perhaps it cannot contain space character or can't start with it?

Comment by lidiam [ 04/Mar/11 ]

Attaching screenshot to show that there is no error message indicating what may be wrong.





[GLASSFISH-14670] Tree Highlighting: wrong config highlighted Created: 12/Nov/10  Updated: 02/Mar/11

Status: Reopened
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_b31

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

Operating System: All
Platform: All


Attachments: JPEG File config-clusterexception.JPG     JPEG File config-wrong-highligh.JPG     Text File server.log    
Issuezilla Id: 14,670

 Description   

build ogs-3.1-b28-11_10_2010.zip

With a freshly installed build create a standalone instance. As soon as it is
highlights the wrong config - default-config, instead of the instance's config.
However, the list on the right belongs to the instance's config, so it is only
the highlighting that's incorrect.

If I go back to the Standalone Instances page and click on the instance's config
again - this time highlighting is correct. So the issue is there only right
after the instance is created.

I tried the same thing with a cluster and got an exception when clicking on
cluster's config (seems that the config itself wasn't added to the tree yet):

HTTP Status 500 -
type Exception report
message
descriptionThe server encountered an internal error () that prevented it from
fulfilling this request.
exception
javax.servlet.ServletException: java.util.ConcurrentModificationException while
attempting to process a 'beforeEncode' event for 'event145'.
root cause
java.lang.RuntimeException: java.util.ConcurrentModificationException while
attempting to process a 'beforeEncode' event for 'event145'.
root cause
java.util.ConcurrentModificationException
note The full stack traces of the exception and its root causes are available in
the Oracle GlassFish Server 3.1 logs.
Oracle GlassFish Server 3.1



 Comments   
Comment by lidiam [ 12/Nov/10 ]

Created an attachment (id=5449)
screenshot

Comment by lidiam [ 12/Nov/10 ]

Created an attachment (id=5450)
server.log

Comment by Anissa Lam [ 20/Nov/10 ]

Fixed several tree highlight issue. Fixing issue# 14262 also fixed this.

Comment by lidiam [ 02/Mar/11 ]

The highlight issue is still present, the good news there is no exception. I tried both standalone instance and cluster (empty) and for each one, I was taken to the right config, but the highlight was incorrect: the first config in the Configurations tree is highlighted. The configuration that's displayed on the right is not present in the Configurations tree for a while and then it appears. There is a significant delay.

Since user is taken to the correct config I'll lower priority of this issue.

Comment by lidiam [ 02/Mar/11 ]

Attached screenshot.





[GLASSFISH-13935] Connector: disable Processing... button Created: 12/Oct/10  Updated: 09/Mar/12

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

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

Operating System: All
Platform: All


Attachments: JPEG File processing-v2.JPG     JPEG File processing-v3.JPG     JPEG File resource-runtime-exception.JPG     Text File server.log    
Issuezilla Id: 13,935

 Description   

build: glassfish-3.1-b24-10_10_2010.zip

Currently when I click on delete for resources (connector or jdbc) a
"Processing..." button is displayed and it is active, meaning I can click it
again and get the same prompt displayed again. This button should be disabled,
as it is in v2, for all such actions. However, I did not observe any negative
side effects of this button being active (no exceptions in server.log, deletion
completes fine), thus potentially this issue could have a lower priority.



 Comments   
Comment by lidiam [ 12/Oct/10 ]

Created an attachment (id=5129)
screenshot - v2

Comment by lidiam [ 12/Oct/10 ]

Created an attachment (id=5130)
screenshot - v3

Comment by sumasri [ 13/Oct/10 ]

Added a target milestone.

Comment by sumasri [ 22/Oct/10 ]

->MS7

Comment by sumasri [ 11/Nov/10 ]

Once it starts the delete operation, if we click on the "delete" button also, it
will be no op as it has already started the process.

So, Changing it to lower priority.

Comment by sumasri [ 02/Dec/10 ]

Jason has made some changes related to this. This issue is also resolved with that change.
When user clicks on delete for resources (connector or jdbc) a "Processing..." button is displayed and user is not able to click on the button now. Hence, closing the issue as resolved.

Comment by lidiam [ 25/Feb/11 ]

Tested in promoted build b43 and the issue still exists, though the button is displayed for a short time, since deletion of the resource is quick. The bad thing is that now the click on "Processing" button results in runtime exception printed on the screen. Steps to reproduce:

1. Create a Connector Resource filling as many fields, creating properties as desired.
2. On the Connector Resources screen select the newly created resource and click Delete. Hit OK on prompt and right away click on "Processing" that appears in place of "Delete" button. Hit OK on prompt again. - At first the page will display with the table but after a while the following is printed in the right hand frame:

class java.lang.RuntimeException

This may be a bit more of an issue on slower systems, when deletion takes longer.

By the way, when creating a resource, there is also a "Processing..." button, but it is grayed out and inactive, as it should be.

Comment by lidiam [ 25/Feb/11 ]

Attached screenshot and server.log.

Comment by sumasri [ 09/Mar/12 ]

Updating the fix version to future release.





[GLASSFISH-13894] update-node-* lets you set a nodedir on in-use node if original node does not have one Created: 08/Oct/10  Updated: 15/Apr/14

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

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

Operating System: All
Platform: All


Attachments: JPEG File node-chnodedir.JPG     JPEG File nodedir-change.JPG     JPEG File nodedir-startup-error.JPG     Text File server.log     Text File server.log    
Issuezilla Id: 13,894
Tags: 3_1_1-scrubbed

 Description   

build: glassfish-3.1-b23-10_07_2010.zip

Create a node on localhost specifying a node directory, e.g. mynodes and the
same install directory as localhost node. Create standalone instance using new
node. At this point directory structure is created in filesystem for node and
instance. Go to Edit Node screen, for the newly created node and modify node
directory by deleting the entry. Attempt to start instance and the following
error is printed on screen:

An error has occurred
Could not start instance sanlan1 on node lancer (localhost). Command failed on
node lancer (localhost): CLASSPATH=
/export/home/j2eetest/v3.1/glassfish3/glassfish/bin/../modules/admin-cli.jar
Commands: [start-local-instance, --node, lancer, --nodedir, , sanlan1] asadmin
extension directory: /export/home/j2eetest/v3.1/glassfish3/glassfish/lib/asadmin
Prepare Process program options Parsing program options Parse command options
params:

{node: [lancer] nodedir: [] }

operands: [sanlan1] Prevalidate...

Either user should be able to change node directory without further errors or
this choice should be disabled.



 Comments   
Comment by lidiam [ 08/Oct/10 ]

Created an attachment (id=5107)
screenshot

Comment by lidiam [ 08/Oct/10 ]

Created an attachment (id=5108)
server.log

Comment by Anissa Lam [ 08/Oct/10 ]

I think backend needs to fix this, ie to be able to handle changing of the
node-dir after the node is created.
User maybe using CLI set to modify that as well.

If this is going to cause problem, it should disallow it so user cannot use CLI
to change it, and notify GUI to make that field read-only after creation.
If user should be able to change node directory after creation, then the current
behavior is wrong.

Comment by Joe Di Pol [ 11/Oct/10 ]

A couple of options:

1) Don't allow changing the nodedir once a node has been created. Or

2) Don't allow changing the nodedir if there are any instances using the node.

I'm leaning towards #2. update-node-* can check if any instances are using
the node and report an error if nodedir is being changed.

Comment by Joe Di Pol [ 03/Nov/10 ]

The code has been changed so that if you try to change installdir or nodedir and
the node is referenced by one or more server instances then the update command
will fail with an error.

Author: jfdipol
Date: 2010-11-03 21:44:43+0000
New Revision: 42431

Modified:

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/LocalStrings.properties

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/NodeUtils.java

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/UpdateNodeCommand.java

Comment by lidiam [ 25/Feb/11 ]

I can still change node directory on an SSH node that has an instance underneath. Here are the steps to reproduce:

1. In Admin Console create an SSH node on localhost, filling in only node name and host.
2. Create a standalone instance under the new node with default settings.
3. Start the instance.
4. Stop the instance.
5. Go to Nodes page and type a bogus name for Node Directory field - the change is accepted. I tried it three times to make sure...
6. If you attempt to start the instance you will get the following error:

An error has occurred
Could not start instance in2 on node ln (localhost). Command failed on node ln (localhost): Command start-local-instance failed. Node directory /export/home/j2eetest/v3.1/glassfish3/glassfish/bogusDir does not exist or is not a directory To complete this operation run the following command locally on host localhost from the GlassFish install location /export/home/j2eetest/v3.1/glassfish3: asadmin start-local-instance --node ln --nodedir /export/home/j2eetest/v3.1/glassfish3/glassfish/bogusDir --sync normal in2

7. Go back to the node page and wipe out bogus node dir name - this time the change is not accepted with the expected error message of:

An error has occurred
Cannot update node ln. It is in use by a server instance and therefore attribute nodedir cannot be changed.

I'm not sure why this message does not show up the first time around...

Comment by lidiam [ 25/Feb/11 ]

Attaching screenshots and server.log.

Comment by Joe Di Pol [ 12/May/11 ]

The current code lets you update a node with new values if the attributes you are updating do not already have values, even if the node is in use by an instance. Here is the relevant comment from UpdateNodeCommand:

// If the current (config) value is null or "" then let it be changed.
// We need to do this for the offline config case where the user has
// created a config node with no values, created instances using those
// nodes, then updates the values later. This has the undersireable
// effect of letting you, for example, set a nodedir on a node
// that was created without one.
if (!StringUtils.ok(currentvalue))

{ return true; }

In order to truly fix this we need to be able to tell the difference between the offline config use case (where instances exists in the config, but do not physically exist on a server yet) versus the case where the physical instances do exist.

In the former case update-node-* should allow all attributes to be changed.

In the later case update-node-* should be strict about what attributes can be changed.

This is related to bug GLASSFISH-15414.

To fix this we may need to add a "rendezvous" attribute to the server instance domain.xml element to indicate that the physical instance has been created.

Comment by Joe Di Pol [ 06/Jul/11 ]

Lowering priority since this is a lack of an error check and not a significant loss of functionality.





[GLASSFISH-11821] poor error message from create-jdbc-connection-pool Created: 24/Apr/10  Updated: 02/Nov/10

Status: Reopened
Project: glassfish
Component/s: jdbc
Affects Version/s: v3.0.1
Fix Version/s: 3.1_ms07

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

Operating System: All
Platform: All


Issuezilla Id: 11,821

 Description   

Here is the output that I get from 3.0.1 b12

vkraemer$ ../../GlassFish3.0.1.b12/glassfish/bin/asadmin create-jdbc-connection-pool foobar
com.sun.enterprise.admin.cli.CommandException: remote failure: JDBC connection pool foobar creation
failed. Constraints for this bean violated.
Message = Must specify a datasource/driver classname. DatasourceClassname is mandatory when
resType is javax.sql.DataSource/javax.sql.ConnectionPoolDataSource/javax.sql.XADataSource.
DriverClassname is mandatorywhen resType is java.sql.Driver.

Command create-jdbc-connection-pool failed.

Here is the output that I expected....

vkraemer$ ../../GlassFish3.0.1.b12/glassfish/bin/asadmin create-jdbc-connection-pool foobar
com.sun.enterprise.admin.cli.CommandException: remote failure: JDBC connection pool foobar creation
failed. Constraints for this bean violated.
Message = Must specify a datasource/driver classname. DatasourceClassname is mandatory when
resType is javax.sql.DataSource/javax.sql.ConnectionPoolDataSource/javax.sql.XADataSource.
DriverClassname is mandatorywhen resType is java.sql.Driver.
Usage: asadmin [asadmin-utility-options] create-jdbc-connection-pool
[--datasourceclassname <datasourceclassname>] [--restype <restype>]
[--steadypoolsize <steadypoolsize>] [--maxpoolsize <maxpoolsize>]
[--maxwait <maxwait>] [--poolresize <poolresize>]
[--idletimeout <idletimeout>] [--initsql <initsql>]
[--isolationlevel <isolationlevel>]
[--isisolationguaranteed[=<isisolationguaranteed(default:true)>]]
[--isconnectvalidatereq[=<isconnectvalidatereq(default:false)>]]
[--validationmethod <validationmethod>]
[--validationtable <validationtable>]
[--failconnection[=<failconnection(default:false)>]]
[--allownoncomponentcallers[=<allownoncomponentcallers(default:false)>]]
[--nontransactionalconnections[=<nontransactionalconnections(default:false)>]]
[--validateatmostonceperiod <validateatmostonceperiod>]
[--leaktimeout <leaktimeout>]
[--leakreclaim[=<leakreclaim(default:false)>]]
[--creationretryattempts <creationretryattempts>]
[--creationretryinterval <creationretryinterval>]
[--sqltracelisteners <sqltracelisteners>]
[--statementtimeout <statementtimeout>]
[--lazyconnectionenlistment[=<lazyconnectionenlistment(default:false)>]]
[--lazyconnectionassociation[=<lazyconnectionassociation(default:false)>]]
[--associatewiththread[=<associatewiththread(default:false)>]]
[--driverclassname <driverclassname>]
[--matchconnections[=<matchconnections(default:false)>]]
[--maxconnectionusagecount <maxconnectionusagecount>]
[-ping[=<ping(default:false)>]] [-pooling[=<pooling(default:true)>]]
[--statementcachesize <statementcachesize(default:0)>]
[--validationclassname <validationclassname>]
[--wrapjdbcobjects[=<wrapjdbcobjects(default:true)>]]
[--description <description>] [--property <property>]
[--target <target>] [?|-help[=<help(default:false)>]]
jdbc_connection_pool_id
Command create-jdbc-connection-pool failed.

The error would be even better if it said this

com.sun.enterprise.admin.cli.CommandException: remote failure: JDBC connection pool foobar creation
failed.
Message = Must specify a datasource/driver classname. The option --datasourceclassname or –
driverclassname is mandatory.

instead of this

com.sun.enterprise.admin.cli.CommandException: remote failure: JDBC connection pool foobar creation
failed. Constraints for this bean violated.
Message = Must specify a datasource/driver classname. DatasourceClassname is mandatory when
resType is javax.sql.DataSource/javax.sql.ConnectionPoolDataSource/javax.sql.XADataSource.
DriverClassname is mandatorywhen resType is java.sql.Driver.



 Comments   
Comment by Bill Shannon [ 14/Sep/10 ]

Reassign.

Comment by Jagadish [ 25/Sep/10 ]

"Constraints for this bean violated."
Above message is due to "bean-validation" constraints violation. This will
happen for any validation failure, not just for the reported case.

More samples :
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

asadmin set server.resources.jdbc-connection-pool.DerbyPool.max-pool-size=5
remote failure: Could not change the attributes: Constraints for this bean
violated.
Message = Max-pool-size has to be greater than or equal to steady-pool-size
Constraints for this bean violated. Message = Max-pool-size has to be greater
than or equal to steady-pool-size

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

asadmin set server.resources.jdbc-connection-pool.DerbyPool.max-pool-size=0
remote failure: Could not change the attributes:
org.jvnet.hk2.config.ValidationException: Constraints for this bean violated.
Message = maxPoolSize must be greater than or equal to 1
org.jvnet.hk2.config.ValidationException: Constraints for this bean violated.
Message = maxPoolSize must be greater than or equal to 1

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

asadmin set server.resources.jdbc-connection-pool.DerbyPool.pool-resize-quantity=-1
remote failure: Could not change the attributes:
org.jvnet.hk2.config.ValidationException: Constraints for this bean violated.
Message = poolResizeQuantity must be greater than or equal to 1
org.jvnet.hk2.config.ValidationException: Constraints for this bean violated.
Message = poolResizeQuantity must be greater than or equal to 1

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

Either Config or HK2 module need to take care of this.

Comment by Tom Mueller [ 27/Sep/10 ]

The bean validation logic doesn't have any way to translate a validation failure
into a message about command line options. To do this, the command would need to
catch the validation exception, determine what the failure was, and then produce
an appropriate message. However, the trick here is to figure out how to catch the
validation exception and translate it into a command exception with a different
error message. Check with Jerome on that.

Comment by Jagadish [ 27/Sep/10 ]

This issue is not related to individual module or individual command.
This is common for all "configuration" beans that use bean-validation.
Instead of expecting individual modules/commands to handle the message, it would
be helpful if config / hk2 can handle this.

IIUC, the bug submitter's suggestion is :
eg:

Instead of :

remote failure: Could not change the attributes:
org.jvnet.hk2.config.ValidationException: Constraints for this bean violated.
Message = poolResizeQuantity must be greater than or equal to 1

It should be :
poolResizeQuantity must be greater than or equal to 1

Comment by Tom Mueller [ 27/Sep/10 ]

Please reread the description. The submitter doesn't mention anything about
poolSizeQuantity. I agree that the bean validation message should be cleaned up
so that it doesn't have "Message = " or repeat the message; that would be a
different bug.

The submitters request was to change:

"Must specify a datasource/driver classname. DatasourceClassname is mandatory
when resType is
javax.sql.DataSource/javax.sql.ConnectionPoolDataSource/javax.sql.XADataSource.
DriverClassname is mandatory when resType is java.sql.Driver."

to

"Must specify a datasource/driver classname. The option --datasourceclassname or
--driverclassname is mandatory."

This reference to command options is specific to a particular command and cannot
be handled by the configuration framework without having knowledge about how
command options map to bean properties.

Comment by Jagadish [ 27/Sep/10 ]

Thanks, I have raised issue 13625 to track the bean validation related issue.

Comment by Tom Mueller [ 28/Sep/10 ]
      • Issue 13625 has been marked as a duplicate of this issue. ***
Comment by Jagadish [ 05/Oct/10 ]

setting target milestone

Comment by Jagadish [ 30/Oct/10 ]

Here is the latest output.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
asadmin create-jdbc-connection-pool foobar
remote failure: JDBC connection pool foobar creation failed. Constraints for
this bean violated.
Message = Must specify either datasource-classname or driver-classname.
datasource-classname is mandatory when res-type is javax.sql.DataSource or
javax.sql.ConnectionPoolDataSource or javax.sql.XADataSource. driver-classname
is mandatory when res-type is java.sql.Driver.

Command create-jdbc-connection-pool failed.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

There are two parts :
Part 1 :
"remote failure: JDBC connection pool foobar creation failed. Constraints for
this bean violated. "
Part 2 :
Message = Must specify either datasource-classname or driver-classname.
datasource-classname is mandatory when res-type is javax.sql.DataSource or
javax.sql.ConnectionPoolDataSource or javax.sql.XADataSource. driver-classname
is mandatory when res-type is java.sql.Driver.

Part 1 of the message is from the common framework. I have raised issue 13625
for the same.

Part 2 of the message is a bit verbose as it indicates the appropriate parameter
(either datasource-classname or driver-classname) to be used for various
"res-type".
If we provide the message : "either datasource-classname or driver-classname is
mandatory", then the relationship with restype is not clarified here.

Hence, I feel that current message is fine as we are trying to give more
information in the message w.r.t "restype" and "driver/datasource-classname"

Comment by vince kraemer [ 01/Nov/10 ]

The primary problem that I was concerned about is the following...

The error message does not provide feedback to the user in terms of the valid options to the command
that failed..

datasource-classname should be --datasourceclassname
driver-classname should be --driverclassname

in the error message.

Comment by Jagadish [ 02/Nov/10 ]

The difference in names is because they are from the config validation module
(that validates before persisting a configuration in domain.xml) which is common
for both CLI and GUI. Only other option would be to duplicate this validation in
CLI also.

Comment by vince kraemer [ 02/Nov/10 ]

can you have the message that gets generated by the config validation 'filtered' by the cli command to
remap the strings in the error message into the vocabulary of the command that executed?





[GLASSFISH-15470] every subcommand manual page include "asadmin-options" in the synopsis Created: 06/Jan/11  Updated: 06/Mar/12

Status: Reopened
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_b36
Fix Version/s: future release

Type: Improvement Priority: Minor
Reporter: jbenoit Assignee: Paul Davies
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude

 Description   

request that every subcommand manual page include "asadmin-options" in the synopsis with a note that information about the asadmin-options is on the asadmin manual page.

Here is the motivation/use case email thread from users@glassfish.java.net as to why this is requested:

http://java.net/projects/glassfish/lists/users/archive/2011-01/message/56



 Comments   
Comment by Paul Davies [ 24/Jan/11 ]

Defer to 3.2 for consideration. However, if the proposed fix is adopted, the synopsis would have to include asadmin <asadmin-options>, which reduces the prominence in the synopsis of the subcommand that is described in the man page.

Comment by Paul Davies [ 27/May/11 ]

After consideration, this RFE is declined. Adding this information would clutter the Synopsis and Options sections.

Comment by Paul Davies [ 05/Aug/11 ]

After further consideration and discussion, it seems that including all the related information is more important than not reducing the prominence in the synopsis of the subcommand that is described in the
man page.

The fix for this issue requires the following changes to the man page for each asadmin subcommand:

  • In Synopsis, prefix the subcommand with asadmin [asadmin-options] just like the usage statement.
  • In Options, add an explain for asadmin-options that cross-refers to asadmin(1M) and suggests running asadmin help as an alternative.
  • In See Also, move the cross-reference to asadmin(1M) to above the references to section 1 man pages.
Comment by Paul Davies [ 06/Mar/12 ]

Too ambitious for a minor release such as 3.1.2. Aim to fix in 4.0





[GLASSFISH-15377] [STRESS] java.lang.ArrayIndexOutOfBoundsException in EJB container when executing richAccess 24x7 Created: 28/Dec/10  Updated: 06/Jan/11

Status: Reopened
Project: glassfish
Component/s: ejb_container
Affects Version/s: None
Fix Version/s: None

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

Attachments: Text File server.log    
Issue Links:
Dependency
blocks GLASSFISH-15425 [STRESS][umbrella] 24x7 RichAccess ru... Open

 Description   

Build : 21-dec-2010 nightly build.

See one occurrence of this exception in the cluster when running richaccess over a 24x7 period.

[#|2010-12-28T13:02:31.076+0530|WARNING|glassfish3.1|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=16;_ThreadName=Thread-1;|A system exception occurred during an invocation on EJB SFSB method null
javax.ejb.EJBException: java.lang.ArrayIndexOutOfBoundsException
at com.sun.ejb.containers.StatefulSessionContainer.removeBean(StatefulSessionContainer.java:1051)
at com.sun.ejb.containers.StatefulSessionContainer.removeBean(StatefulSessionContainer.java:969)
at com.sun.ejb.containers.EJBObjectImpl.remove(EJBObjectImpl.java:207)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invokeEJBObjectMethod(EJBObjectInvocationHandler.java:284)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:170)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:123)
at $Proxy182.remove(Unknown Source)
at sun.reflect.GeneratedMethodAccessor108.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:241)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at samples.rmiiiopclient.ejb._SFSBRemoteObjRef_DynamicStub.remove(samples/rmiiiopclient/ejb/_SFSBRemoteObjRef_DynamicStub.java)
at com.s1as.e2e.richAccess.servlet.SendOrder.processRequest(SendOrder.java:141)
at com.s1as.e2e.richAccess.servlet.SendOrder.doPost(SendOrder.java:229)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)



 Comments   
Comment by Mahesh Kannan [ 03/Jan/11 ]

Sony, Are there any other exceptions following this exception (particularly any message that says "Caused by")?

Comment by Mahesh Kannan [ 03/Jan/11 ]

At line number 1051 in StatefulSessioncontainer, I dont see any Array access at all. The source at that line only throws EJBException(ex);

line 1051: throw new EJBException(ex);

I have asked Sony to find out if there were any other "Caused by" exception messages.

This is an EJB Container bug and not replication bug.

Since we see this only once in a 7 day run, the priority of the issue can be reduced.

Also, the message "A system exception occurred during an invocation on EJB SFSB method null " seem to indicate that the method object is null. Not sure if it is anyway related to the ArrayIndex exception.

Assigning to Marina for further evaluation.

Comment by marina vatkina [ 04/Jan/11 ]

Sony, Is monitoring on during run? Can you set ejb-container logger to FINE level and try again?

Comment by marina vatkina [ 05/Jan/11 ]

Please reopen when you have FINE logs available

Comment by sonymanuel [ 05/Jan/11 ]

Don't expect FINE logs for a stress run. We are running at 100 calls per seconds and we can't turn on FINE logging.





[GLASSFISH-14860] create-file-user should allow specifying target Created: 29/Nov/10  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: security
Affects Version/s: 3.1
Fix Version/s: 4.1

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

all platform


Issue Links:
Dependency
blocks GLASSFISH-14797 Realm: error when adding a user to a ... Closed
blocks GLASSFISH-14770 Realm: new user added to admin-realm ... Closed
Tags: 3-1-regression

 Description   

list-file-users , delete-file-user takes in target, but create-file-user doesn't.

Usage: asadmin [asadmin-utility-options] create-file-user
[--groups user_groups[:user_groups]*] [--authrealmname <authrealm_name>]
[?|-help[=<help(default:false)>]] username

Without being able to specify the target during creation, it seems this user is created for EVERY instance.
here is what i see:

%asadmin create-file-user --authrealmname file userABC

Command create-file-user executed successfully.

%asadmin list-file-users --authrealmname file server
userABC
Command list-file-users executed successfully.

%asadmin list-file-users --authrealmname file instance-1
userABC
Command list-file-users executed successfully.

Besides missing the target option, list and delete doesn't takes in config name as target.
%asadmin list-file-users --authrealmname file sever-config
org.glassfish.api.admin.CommandException: remote failure: Unable to find a valid target with name sever-config
Command list-file-users failed.
This doesn't sound right since any security realm is based on configuration, so it should take in config name as target as well.

GUI issue (GLASSFISH-14797) and (GLASSFISH-14770) is depending on this bug fix. We want the following to happen:

1. add 'target' as an option for create-file-user (blocks GLASSFISH-14770)
2. config name should be a valid target. (blocks GLASSFISH-14797)



 Comments   
Comment by kumarjayanti [ 30/Nov/10 ]

Note : create-file-user and delete-file-user already support a --target option. It has to be a --target since the username is the operand for these commands and this is not any different from V2.

Added CONFIG as a targetype.

Note : When dealing with create-file-user and delete-file-user you really need to look at what the Property

<property value="$

{com.sun.aas.instanceRoot}

/config/keyfile" name="file" />

is pointing to. For example the same property above appears in default-config and server-config. So if you do

create-file-user with one config and do list-file-users with another config. You might see the new user under the second config if they share the same keyfile. This is not a bug in security.

Comment by kumarjayanti [ 30/Nov/10 ]

fixed

Comment by Anissa Lam [ 18/Dec/10 ]

I have to reopen this issue.
I don't see a target option for create-file-user with the latest nightly build 12/18.

Usage: asadmin [asadmin-utility-options] create-file-user
[--groups user_groups[:user_groups]*] [--authrealmname <authrealm_name>]
[?|-help[=<help(default:false)>]] username
Command create-file-user failed.

Comment by Anissa Lam