[GLASSFISH-21326] deployment of a EJB with a CDI injection from a different jar fail Created: 12/Mar/15  Updated: 26/Jun/15

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

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


 Description   

i try to deploy a application with a EJB which make a CDI injection from a different jar. But the deployment fails.

A simple CDI injection in the same jar works

I get these exception:

Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001408: Unsatisfied dependencies for type CDIOutOfEJB with qualifiers @Default
at injection point [BackedAnnotatedField] @Inject private com.ducktail.ejb.EJBImpl.outofEJB
at com.ducktail.ejb.EJBImpl.outofEJB(EJBImpl.java:0)

The deployment of the same ear on wildfly works



 Comments   
Comment by jjsnyder83 [ 24/Mar/15 ]

Please provide a reproducible test case.

Comment by tiran1984 [ 24/Mar/15 ]

How can i attach my project?

Comment by jjsnyder83 [ 16/Apr/15 ]

You can mail it to me: j.j.snyder@oracle.com

Comment by tiran1984 [ 05/May/15 ]

I send the test case! Did you received?

Comment by jjsnyder83 [ 07/May/15 ]

Yes I have it. I see why it's failing. You should be able to work around the issue by putting the testbl-3.7.0-SNAPSHOT.jar into the Ear's lib directory.

Comment by jjsnyder83 [ 11/May/15 ]

I believe this is closely related to or a duplicate of these issues:
https://java.net/jira/browse/GLASSFISH-15119
https://java.net/jira/browse/GLASSFISH-15249

Comment by tiran1984 [ 03/Jun/15 ]

No it work the deployment but I get a lot of warnings!

PWC6351: In TLD scanning, the supplied resource file:/D:/glassfish4/glassfish/domains/DOMAIN1/applications/CNEAR/commons-codec-1.3.jar does not exist
java.io.FileNotFoundException: D:\glassfish4\glassfish\domains\DOMAIN1\applications\CNEAR\commons-codec-1.3.jar (The system cannot find the file specified)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:220)
at java.util.zip.ZipFile.<init>(ZipFile.java:150)
at java.util.jar.JarFile.<init>(JarFile.java:166)

How can I resolve this?

Comment by tiran1984 [ 03/Jun/15 ]

An other error by the deployment is

Exception during lifecycle processing
java.lang.IllegalArgumentException: Could not find sub module [fmcalRCP.war] as defined in application.xml
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.readModulesDescriptors(ApplicationArchivist.java:560)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:229)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:232

I can not reproduce it! I will get him sporadically!

Comment by jjsnyder83 [ 03/Jun/15 ]

Please provide full exception stacks so we can determine where the exception starts.

Comment by tiran1984 [ 03/Jun/15 ]

2015-06-03T13:11:47.556+0200] [glassfish 4.1] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=58 _ThreadName=admin-listener(4)] [timeMillis: 1433329907556] [levelValue: 1000] [[
Exception during lifecycle processing
java.lang.IllegalArgumentException: Could not find sub module [cmcalRCP.war] as defined in application.xml
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.readModulesDescriptors(ApplicationArchivist.java:560)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:229)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:232)
at org.glassfish.javaee.core.deployment.DolProvider.processDOL(DolProvider.java:193)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:227)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:96)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:881)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:821)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:377)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:404)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
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:151)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:171)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:104)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:387)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:331)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:103)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:271)
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:297)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:254)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1028)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:365)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
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:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
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:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
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:745)
]]

[2015-06-03T13:11:47.582+0200] [glassfish 4.1] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=58 _ThreadName=admin-listener(4)] [timeMillis: 1433329907582] [levelValue: 1000] [[
Exception while deploying the app [CMEAR] : Could not find sub module [cmcalRCP.war] as defined in application.xml]]

Comment by jjsnyder83 [ 03/Jun/15 ]

It appears to be something wrong with the application deployment.

Comment by tiran1984 [ 12/Jun/15 ]

during the deployment the application folder will not complete deleted. The folder can also not deleted from file system manuel . I have to restart the server for successful deploy or delete

It is always the same path "applications\EAR\test_war\WEB-INF\lib"
It is possilbe to find out which process lock the jar?

Comment by Vinay Vishal [ 12/Jun/15 ]

This issue could be similar to https://java.net/jira/browse/GLASSFISH-21261 which has already been fixed in revision 63874. Can you please give it a try with latest glassfish build and let us know?

http://download.java.net/glassfish/4.1/nightly/latest-glassfish.zip

Comment by tiran1984 [ 12/Jun/15 ]

Nothing changed, when i tried quick

in the ear folder I have the file .glassfishStaleFiles with
_war/
_war/WEB-INF/
_war/WEB-INF/lib/
_war/WEB-INF/lib/bl-3.7.0-SNAPSHOT.jar
lib/
lib/bl-3.7.0-SNAPSHOT.jar

this is a jar which have a beans.xml for weld cdi, it is always the this file which could not deleted

Comment by tiran1984 [ 22/Jun/15 ]

can someone help?
when I remove the beans.xml, the undeploy works fine but the CDI is disabled

Comment by jjsnyder83 [ 23/Jun/15 ]

Please send me new app and I'll try it out.





[GLASSFISH-11764] EJBContainer#createEJBContainer() does not consider full classpath Created: 08/Apr/10  Updated: 23/Apr/15

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: v3.0.1
Fix Version/s: future release

Type: Improvement Priority: Critical
Reporter: ljnelson Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://forums.java.net/jive/thread.jspa?threadID=78213&start=0&tstart=0


Issuezilla Id: 11,764
Tags: 3_1-exclude, javaee_ri_target

 Description   

The contract for EJBContainer#createEJBContainer() says:

"JVM classpath is searched for all ejb-jars or exploded ejb-jars in directory
format."

The "JVM classpath" in this documentation is presumably intended to be what the
EJB 3.1 specification says:

"By default, the embeddable container searches the JVM classpath (the value of
the Java System property java.class.path) to find the set of EJB modules for
initialization."

That happens to be a really narrow version of what any given JVM classpath
usually is in reality. A pragmatic definition of classpath also includes the
set of all "reachable" classpath entries present in a jar file's MANIFEST.MF
Class-Path entry.

IMHO the classpath scanning mechanism in EJBContainer should take into account
the full set of classpath entries (including those reachable from a Class-Path
manifest header), not just the value in System.getProperty("java.class.path"),
since that is what programmers expect.

Finally, most Maven tests run by building up such a classpath in an otherwise
empty "booter" jar file. Test cases that launch in this manner will not be able
to discover EJBs on the classpath without manual intervention until this bug is
fixed.

The full discussion of this issue is available at
http://forums.java.net/jive/thread.jspa?threadID=78213&start=0&tstart=0.



 Comments   
Comment by Alexis MP [ 08/Apr/10 ]

cc

Comment by sirajg [ 08/Apr/10 ]

cc

Comment by Amy Roh [ 08/Apr/10 ]

assign to marina

Comment by ksak [ 08/Apr/10 ]

Yes, agree this is ambiguous in the EJB spec. It will have to be clarified in the next spec. This should work
the same way manifest-classpath entries are handled for EE modules during deployment. Namely, that
classes in .jars referenced from the manifest-classpath of a module (and their recursive manifest-
classpaths contents, etc.) are logically included in the set of classes for the original module. Note that the
entries referenced from the manifest-classpath do not themselves define new modules. Their classes are
merely processed as if they were physically packaged within the original module that appears on the jvm
classpath.

Comment by ljnelson [ 08/Apr/10 ]

OK, so take Maven, which when its surefire-plugin (a JUnit runner, basically)
runs in <forkMode>always</forkMode> mode always builds one jar file in /tmp that
contains a Manifest Class-Path entry. This is pervasive throughout commercial
enterprise Java development.

You're saying-and I don't necessarily disagree with this-that as far as
Glassfish is concerned, it will effectively discover the mother of all EJB jars,
which will just happen to be this empty surefire jar? So ejb-jar.xml files
sprinkled throughout the jars it references are ignored?

Coming at this a different way for a moment, I wonder what the value of
ClassLoader.getResources("META-INF/ejb-jar.xml") would be in such a case (never
tried it). I would argue that if it returns many URLs, then the EJB spec should
follow this behavior (i.e. contrary to your assertion I'd expect many modules to
be defined). If it returns one, then I would agree with your assertion.

Having been burned by Manifest Class-Paths in the past, I seem to recall that
the magic that computes the set and the effective classpath doesn't just make it
look like referenced jars are somehow included as though they were packaged in
the original jar file; it is more like it adds URLs to a URLClassLoader (even
though as far as I can recall that's not actually what happens).

Comment by ljnelson [ 08/Apr/10 ]

Retract my previous comment, please; I misread your statement.

Comment by marina vatkina [ 12/Apr/10 ]

Reassign to deployment to verify that they process manifest entry references

Comment by Hong Zhang [ 04/Oct/10 ]

scrubbing issues

Comment by Hong Zhang [ 21/Oct/10 ]

The deployment now supports absolute URL in the Class-Path attribute. Assign to
ejb team to see if there is any remaining work from ejb container to get the
use case work with embedded ejb container.

Comment by marina vatkina [ 21/Oct/10 ]

Reassigning back to deployment to resolve:
a) a jar with a PU referenced in the class-path
b) GenericAnnotationDetector.hasAnnotationInArchive to look at the manifest
class-path

Comment by Hong Zhang [ 21/Oct/10 ]

I can fix b) here which is only invoked in the embedded code path.

But for a) to be fixed, we need to look at META-INF/persistence.xml in the
referenced jar. And more general, we need to start looking for deployment
descriptors in the library jars. I am not sure if that's what we want to do.
Let's having more discussions before we decide what to do. I am going to change
the target milestone to 3.2 (if we do decide to support it, we will need quite
some changes).

Comment by Hong Zhang [ 21/Oct/10 ]

Reading the EE 6 spec (section 8.2.1, quoted at the end), it says the
depoloyment descriptor in the library jar must be ignored:
"Any deployment descriptors in referenced .jar files must be ignored when
processing the referencing .jar file."

Also:
Top level JAR files that are processed by a deployment tool should not contain
Class-Path entries; such entries would, by definition, reference other files
external to the deployment unit. A deployment tool is not required to process
such external reference

I think the next version of the EJB spec must do some clarifications to
override the above EE spec section before we do something in the implementation
to support the use case.

============================================================================
EE.8.2.1 Bundled Libraries
Libraries bundled with an application may be referenced in the following ways:
A JAR format file (such as a .jar file, .war file, or .rar file) may reference
a .jar file or directory by naming the referenced .jar file or directory in a
Class-Path header in the referencing JAR file’s Manifest file. The
referenced .jar file or directory is named using a URL relative to the URL of
the referencing JAR file. The Manifest file is named META-INF/MANIFEST.MF in
the JAR file. The Class-Path entry in the Manifest file is of the form
Class-Path: list-of-jar-files-or-directories-separated-by-spaces
(See the JAR File Specification for important details and limitations of the
syntax of Class-Path headers.) The Java EE deployment tools must process all
such referenced files and directories when processing a Java EE module. Any
deployment descriptors in referenced .jar files must be ignored when processing
the referencing .jar file. The deployment tool must install the .jar files and
directories in a way that preserves the relative references between the files.
Typically this is done by installing the .jar files into a directory hierarchy
that matches the original application directory hierarchy. All referenced .jar
files or directories must appear in the logical class path of the referencing
JAR files at runtime.
Only JAR format files or directories containing class files or resources to be
loaded directly by a standard class loader should be the target of a Class-Path
reference; such files are always named with a .jar extension. Top level JAR
files that are processed by a deployment tool should not contain Class-Path
entries; such entries would, by definition, reference other files external to
the deployment unit. A deployment tool is not required to process such external
reference.
=============================================================================

Comment by marina vatkina [ 22/Oct/10 ]

There will be more things to sort out with a jar wrapping an Java EE module via
Class-Path ref: the module name of an EJB module (with the lack of deployment
descriptors processing in the referenced jars) becomes that of the wrapping jar.





[GLASSFISH-11710] make --contextroot useful for EAR projects... Created: 20/Mar/10  Updated: 16/Apr/13

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Critical
Reporter: vince kraemer Assignee: Hong Zhang
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: Sun


Issuezilla Id: 11,710

 Description   

This RFE is based on a query that I found... http://stackoverflow.com/questions/2469284/deploy-
multiple-instances-of-an-ear-representing-versions-to-glassfish

It would be nice to make it easy to deploy multiple instances of the same ear file on single server.

Right now, you have to edit the descriptors or deploymentplan to put the same ear on one instance of
the server.

It looks like we could do the following, though... pretty simply.

assume I have an ear with a war file in it, mapped to /123

We could use the --contextroot option of asadmin to construct a new CR by appending the option's
argument WITH the CR specified in the application.xml

So:

asadmin deploy EarWith123War.ear
results in the same old CR we would get today, "/123"

asadmin deploy --contextroot /abc EarWith123War.ear
results in a constructed CR /abc/123

If the user needed to deploy another version of EarWith123War.ear, they could do

asadmin deploy --contextroot /xyz EarWith123War.ear
to get the constructed CR /xyz/123



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

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

Comment by Jeremy_Lv [ 15/Apr/13 ]

Hong:
I found it is a critical issue, shall we need to support the option of --contextroot when deployed an ear application in the feature?

Thanks

Jeremy

Comment by Hong Zhang [ 16/Apr/13 ]

The complication is an ear application could contain multiple web applications so there needs to be some correlation between the context root and the corresponding war file when you specify the context root. So I am not sure if it's going to provide much more convenience than the deployment plan if we factor this in..

Comment by vince kraemer [ 16/Apr/13 ]

Hmmm. Say you have an ear with multiple CRs... war1.war has a CR of /123; war2.war has a CR of /789.

If the user said something like 'asadmin deploy -contextroot /abc myTwoWar.ear'

The resulting CRs would be war1.war would have CR /abc/123 and war2.war would have CR /abc/789.

I am not sure I see a need to correlate the CRs and wars (other than the data that is already in the application.xml). Did I miss something?

Comment by Hong Zhang [ 16/Apr/13 ]

If the contextroot option have different semantics for ear and standalone module (one provides prefix and the other provide complete context root), will it cause confusion to the user?

Comment by vince kraemer [ 16/Apr/13 ]

that is a good point. we could use the --contextroot for EARs that have a single war file, though, and that would be consistant and useful for a number of users. If the ear had multiple CRs, the use of --contextroot could generate a useful error message that would instruct the user to create a deployment plan to override the CRs that are in the ear...

or

create a new cli option --contextroot-prefix that would be used as outlined in my previous comment.

The goal is to make stuff easy for the user. Creating a deployment plan is not easy (unless it has improved significantly in GF 4).

Comment by Jeremy_Lv [ 16/Apr/13 ]

There's no specification about this situation, So I think we can implement the option of contextroot-prefix in the deployment side, I think the idea vince kraemer suggest is a nice one. I think the user will be more convinent to use this.





[GLASSFISH-5474] Allow for webapp deployment/initialization priority Created: 13/Aug/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Critical
Reporter: uppalapati Assignee: Hong Zhang
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5,474

 Description   

Sometimes webapps expose services that are consumed by other webapps running on
the same webcontainer. In such a situation, the developer needs the webcontainer
to deploy/initialize applications in a particular order.

At the minimum users should be able to define a top level application like in
Tomcat's ROOT webapp.
Adding this feature will bring feature parity with Tomcat for Glassfish V3

The user should be able to set the initialization priority at deployment time
either using asadmin or using an entry in the sun-web.xml



 Comments   
Comment by uppalapati [ 13/Aug/08 ]

Increasing the priority since it is needed for Liferay community builds on
Glassfish V3

Comment by jluehe [ 13/Aug/08 ]

Can you explain a little more?

Prior to a server restart, webapps are initialized in the order in which they
are deployed. The web container is not involved in the decision about which
webapps are deployed when. That is the administrator's decision.

Are you talking about the order in which webapps are loaded/initialized
following a server restart? Could that not be the same order in which they were
deployed originally?

Comment by uppalapati [ 13/Aug/08 ]

We place the portal war file and all the portlet war files in the GF domain auto
deploy dir. The portlet war files need to be deployed and initialized after the
portal war is done.

Right now auto deploy is using its own sort mechanism to decide the order in
which the webapps are deployed.

Tomcat has the concept of ROOT context webapp and it initializes this app before
any of the other webapps. So services defined in this app are available to other
webapps when they are initializing.

Comment by jluehe [ 13/Aug/08 ]

Thanks for clarifying! So that would make it a deployment issue, since the web
container is not involved in the decision in which order autodeployment occurs.

Comment by Hong Zhang [ 13/Aug/08 ]

Can you point us to the relevant Tomcat doc for this feature?

I guess there are two parts to this:
1. The web applications need to be deployed in a certain order.
2. The web applications need to be loaded in a certain order (after server is
restarted).

Comment by km [ 14/Aug/08 ]

I don't think we should redefine how auto-deployment works. The algorithm of
auto-deployment is simple and effective. You place an archive in that folder and
it gets deployed when the auto-deployment thread "sees" it. Applying some kind
of dependency logic there is going to make it complex.

Why can't you deploy two applications in the sequence you desire by using
asadmin deploy command?

Also, is this a deploy-time dependency or runtime dependency? i.e. do you want
deployment of these applications to occur in a sequence you want or their
loading in the container? If it is latter, auto-deployment alone is not going to
help for after deployment, if you restart the server, the loading of
applications is (generally speaking) going to happen in the order of their
appearance in the domain.xml.

Comment by uppalapati [ 24/Aug/08 ]

Any application that is deployed in the ROOT context "/" on Tomcat is
initialized before any other application deployed before or after the
application in the ROOT context was deployed.

I understand the need to keep the design and impl simple. However the usecase
above needs to be solved by Glassfish. With that in mind can we just do the
following:

Modify Glassfish to deploy and initialize any webap that is targeted for the "/"
context ahead of the rest of the apps?

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-20992] Clustered deployment sometimes fails with error "Command disable failed on server instance xxx: remote failure: Application not registered Command deploy failed." Created: 21/Feb/14  Updated: 17/Apr/14

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

Type: Bug Priority: Critical
Reporter: electricsam Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, JDK 1.7.0_45



 Description   

Sometimes when redeploying an application, the deploy fails with the following error:

Failure: Command disable failed on server instance xxxxxx: remote failure: Application not registered Command deploy failed.

Repeated attempts always fail. After the error appears once it seems like nothing can be deployed.

Sometimes the error is:

Error occurred during deployment: Keys cannot be duplicate. Old value of this key property, nullwill be retained. 

Here is the command:

asadmin deploy --force=true --deploymentorder 300 --target yyyyy 

Sometimes by trial and error I can get the deploy to work. Here is what I've tried:

1. Stop the domain then remove the "generated" and "osgi-cache" and re-start the domain
2. Stop the cluster and the domain then remove the "generated" and "osgi-cache" from the domain and the nodes and re-start the domain and cluster
3. Undeploy the problem app, then redeploy it. However, sometimes the app is listed as having been un-deployed already and this fails
4. Undeploy everything that can be undeployed. Manually delete the applications that could not be undeployed via asadmin from the applications folder and manually edit the domain.xml to remove references to those apps.



 Comments   
Comment by Hong Zhang [ 11/Apr/14 ]

Can you provide the test application and the set of steps for us to reproduce from our side?

Comment by electricsam [ 17/Apr/14 ]

It's not always the same app.

Let me describe our set-up. We have a complex web service. It is comprised of about 60 ears. We have a nightly script which will deploy / re-deploy any apps that have changed (varies between 5-60).

This error occurs probably 3-4 times a month and requires manual intervention and possibly an outage to resolve.

We are running a cluster of 2 nodes. The DAS and each of the nodes are on their own separate boxes.

Other than all being ears, there is no commonality between the apps. I have not been able to find one scenario that will consistently reproduce the issue.

I will continue to look for patterns, but so far none are obvious.





[GLASSFISH-21283] WAR undeployment ends up with .glassfishStaleFiles after upgrading Glassfish 4.0 up to 4.1 Created: 31/Dec/14  Updated: 15/Jun/15

Status: In Progress
Project: glassfish
Component/s: deployment
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: alexander.v.morozov Assignee: Shaifali Kansal
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64 Professional, JDK 7u72 x64


Tags: javaee_ri_target

 Description   

We have simple WAR archive, which contains several jar-files (some of them contains beans.xml) and several classes within WAR, which uses Managed Beans. Our application works well under Glassfish 4.0 and redeployment time takes about 3 seconds.
Once we upgrade Glassfish up to 4.1 (release) - undeployment time dramatically increased up to 40 and more seconds. After that Glassfish creates ".glassfishStaleFiles" which enumerates all JAR-archives with beans.xml. There is no any errors in Glassfish log file. We will try to provide sample application archive a bit later.



 Comments   
Comment by alexander.v.morozov [ 12/Jan/15 ]

Sample project was uploaded to Github https://github.com/shuraa/gf41 .

Comment by Shaifali Kansal [ 12/Jun/15 ]

This bug could not be reproduced locally. I tried to deploy, undeploy and redeploy your sample project multiple times with glassfish 4.1 and everything happened within 2-3 seconds. Also no ".glassfishStaleFiles" were created either.
Can you please check if you're still facing this issue?

Comment by mmariotti [ 13/Jun/15 ]

I confirm this issue is still present.
In particular, GF fails to undeploy and delete jars which contains JSF @ManagedBeans, @EJBs, @Named CDI objects, etc.

I'm using a WAR, not an EAR, and this issue can be reprocuced on every version of windows (I tried 7, 8, 8.1, server 2012).
This is the content of .glassfishStaleFiles:

WEB-INF/
WEB-INF/lib/
WEB-INF/lib/shape-core-3.0.1-SNAPSHOT.jar
WEB-INF/lib/primefaces-5.2.1.jar
WEB-INF/lib/omnifaces-2.0.jar
WEB-INF/lib/atmosphere-runtime-2.3.1.jar

please consider a high priority for this issue, since GF 4.1, in this state, is unusable for development (repeatedly stop-cleanup-start-deploy is too slow, even with JRebel) and for production too (service unavailability is too high)

if you need me to test something, or to give you additional informations, don't hesitate.

Thank you

Comment by davidwinters1980 [ 14/Jun/15 ]

A similar issue to this https://java.net/jira/browse/GLASSFISH-21261 has been fixed on Payara can be downloaded from here: http://payara.co.uk/downloads.

The issue and commits on Payara to fix this issue can be referenced here: https://github.com/payara/Payara/issues/79.

The fix should be already in the latest Glassfish nightly also so can you try on Payara and the latest nightly Glassfish.

If you still get the same issue ..attach the contents of the server log file, the file system details you are deploying the application to on windows (NFS possibly)

Comment by davidwinters1980 [ 14/Jun/15 ]

Also if you could capture a number of thread dumps during the period of time the deployment that takes up to 40 seconds and copy the contents to here or send us a link to your dropbox so that we can download the thread dumps that would be appreciated.

Comment by mmariotti [ 15/Jun/15 ]

Already tried "Payara Server Open Source Edition 4.1.152.1 #badassfish (build 193)";
I don't know SCM revision, but I downloaded it two days ago, and the issue is still present.

In some hour I'll download and test the latest GlassFish nightly, and let you know. If the latest GlassFish is still presenting the issue, I'll provide thread dumps.

I'm not using NFS, but NTFS on a local machine; actually more than one, around 10, and every machine has a local installation, but no shared folder/NFS available to GlassFish, so maybe they are not related.

server.log doesn't contains anything relevant, however you can take it here: http://pastebin.com/6iejkfFc

Comment by mmariotti [ 15/Jun/15 ]

OK, I tried with latest GlassFish nightly, and the issue is still present.

here is the link to a zip file that contains thread dumps, server.log and .glassfishStaleFiles: glassfish_thread_dumps.zip

Thank you





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

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

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


 Description   

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

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

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

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

{ cl.addURL(moduleURL); }

 Comments   
Comment by Hong Zhang [ 08/Feb/13 ]

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





[GLASSFISH-12162] align osgi versioning with application versioning Created: 07/Jun/10  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: Hong Zhang Assignee: Hong Zhang
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: 12,162

 Description   

Filing this to keep track of the issue.

As part of the asarch review on the versioning spec, it was discussed that maybe
osgi deployment should be aligned with the application versioning feature.

Version information (and name) will be retrieved from the osgi metadata, and
used similarly as the passed in name+version information in the application
versioning feature.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-10496] Global V2 Compatibility Mode For GF v3 Created: 22/Oct/09  Updated: 12/Jun/13

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: abien Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS X
Platform: Macintosh


Issuezilla Id: 10,496

 Description   

Glassfish v3 comes with compatibility feature: asadmin deploy --property compatibility=v2 foo.ear

The problem: this feature is only available from the CLI. There should be global e.g. setting (in
domain.xml) and accessible from the admin UI (EJB container node) to be set persistently. A local setting,
e.g. in the deployment descriptor: sun-*.xml .

Reason: a majority of GF v2 projects is using Hudson + Maven / Ant for deployment. Most of the projects,
are not 100% Java EE compatible but can be deployed to GF v2 without any problems. The migration even
of such projects should be as smooth, as possible.



 Comments   
Comment by Hong Zhang [ 28/Oct/09 ]

Taking the ownership of this. I will talk with Jerome to discuss the plan for this.

Downgrading it to P2 as it only happens for applications which are packaging in
an incompatible way defined by the spec.

The reason we did this clean up in v3 is we want to encourage the compatible
packaging by the spec.

Comment by abien [ 28/Oct/09 ]

I understand your intention, but from customer perspective it causes a lot of trouble. I had to argue a lot
why an application worked on v2, but not on v3.

I would reverse the settings and provide a "JavaEE strict" mode, instead of setting the strict mode as
default...

Comment by Hong Zhang [ 28/Oct/09 ]

also adding bill and tim to the Cc

Comment by vince kraemer [ 28/Oct/09 ]

A reference to the sections of the spec that are being violated would be very helpful.

Comment by Tim Quinn [ 29/Oct/09 ]

Read EE 8.3.x. Near the end of each container-specific section is a statement
like this (this one is from the app client container section, EE 8.3.3):

"Components in the application client container must not have access to the
following classes and resources, unless such classes or resources are covered by
one of the rules above.

• Other classes or resources in the application package. For example, the appli-
cation client should not have access to the classes in other application client jar
files in the same ear file, nor should it have access to the classes in web appli-
cations or ejb jar files in the same ear file. "

The details vary among the different containers discussed in EE 8.3.x.

Comment by ludo [ 29/Oct/09 ]

Adam, are you talking about App Client apps or EAR apps?

Can you add more info in the bug? Is is related to the class-path entry in the
webapp manifest inside an ear file?
http://www.netbeans.org/issues/show_bug.cgi?id=173195

Comment by abien [ 29/Oct/09 ]

Clearification:

0. asadmin deploy --property compatibility=v2 foo.ear solved the problem
1. It was an EAR-only deployment
2. The app, as many others GF v2 apps were deployed in Java EE incompatible way - but worked perfectly
in GF v2. Maven was used to build the archive the application. It ignored the class-path entries in
manifest.mf

The point is: it is hard to explain to the customers, why something worked with GF v2 but doesn't work
with GF v3 any more. Suggestion: GF v3 should behave as v2, and be optionally more restrictive.

Comment by vince kraemer [ 29/Oct/09 ]

OK. So these are Java EE 5 apps... right?

Which part of the Java EE 5 spec were they violating?

If they were not violating the Java EE 5 spec, then we may have another way to decide how we want to treat
these apps, wrt to the compatibility flag...

Java EE 6 apps should default to 'strict'. Java EE 5 and J2EE 1.4 apps should default to 'compatible'...

Comment by Hong Zhang [ 29/Oct/09 ]

I see. So it's a combination of NB/Maven which produces this type of ear packaging.

This is what EE5 spec defined for the bundled libraries:

Section 8.2.1 Bundled Libraries

2. A .ear file may contain a directory that contains libraries packaged in JAR
files. The library-directory element of the .ear file’s deployment descriptor
contains the name of this directory. If a library-directory element isn’t spec-
ified, or if the .ear file does not contain a deployment descriptor, the
directory named lib is used. An empty library-directory element may be used to
specify that there is no library directory.
All files in this directory (but not subdirectories) with a .jar extension
must be made available to all components packaged in the EAR file, including
application clients. These libraries may reference other libraries, either bun-
dled with the application or installed separately, using any of the techniques
described herein.

Comment by Bill Shannon [ 29/Oct/09 ]

The app was non-portable. It depended on behavior that was not specified
by the Java EE 5 spec, and was not specified by the GlassFish documentation,
but which happened to work in earlier versions of GlassFish. This was not
a "Java EE 5 app". At best it was a "GlassFish v2 app". If there's a way
to know from the packaging of the app that it intends to depend on GlassFish
v2 behavior, we could use that to control the compatibility mode.

Really, this is a bug in GlassFish v2 that was fixed in GlassFish v3 to align
with a more complete specification of this behavior in Java EE 6.

Comment by vince kraemer [ 29/Oct/09 ]

regarding https://glassfish.dev.java.net/issues/show_bug.cgi?id=10496#desc10

You seem to have ignored EE 8.2.1 (item 1), which is the way NetBeans configures
modules in an ear to reference bundled libraries.

regarding https://glassfish.dev.java.net/issues/show_bug.cgi?id=10496#desc11

there is plenty of evidence that an app might have deployed and run on v2...
the doctype of any sun-*.xml files
the doctype or version of any platform descriptors that are in the app
the absence of any Java EE 6 apis

You are right. This is a bug in our servers that appears to have been 'in
place' way back in the SJSAS 8.x days. We need to clean up our act. I am not
sure we want to force users to clean up their apps that are 'done' (not under
active development)

Comment by Tim Quinn [ 29/Oct/09 ]

Just a minor point of clarification... The "allow visibility to the top-level
JARs" behavior, as I understand it, originated in Sun Java System App Server 8.x
– long before the library-directory concept appeared in Java EE 5 – and was an
implementation-specific way to accomplish essentially the same thing. As such
it seems to have started as a "feature," evolved into an "artifact" in the
GlassFish v2/Java EE 5 timeframe, and now seems to have graduated to "bug" status!

The Java EE 5 spec language listed approved ways of constructing references to
other JARs in the app but did not state that other ways of doing so were
forbidden or needed some explicit mechanism to do so. Java EE 6 has added this
restriction. (In each EE 8.3.x section is wording to this effect about
visibility of "other" JARs:

"Other classes or resources contained in the application package, and specified
by an explicit use of an extension not defined by this specification."

)

The --property compatibility=v2 feature is such an explicit, platform-specific
mechanism to which the spec refers. So would a possible addition to
sun-application.xml.

IMO checking the DTD or schema versions declared in descriptors does not meet
the requirement in the EE 6 spec for an explicit extension provided by the app
server implementation.

Comment by vince kraemer [ 29/Oct/09 ]

re: https://glassfish.dev.java.net/issues/show_bug.cgi?id=10496#desc13

a little bit of further clarification... as far as I know, the 'standard'
NetBeans EAR project (based on ANT) has never leveraged 'The "allow visibility
to the top-level JARs" behavior' and has used the spec prescribed method (EE
8.2.1 (number 1) [in the Java EE 6 spec] of referencing other jars since that
method first appeared in the J2EE 1.4 spec...

Comment by Hong Zhang [ 29/Oct/09 ]

Right, from the further information provided by the user, the NB (ant) is doing
the right packaging (item 1 of Section 8.2.1). The user case was NB (maven).

Comment by Hong Zhang [ 31/Oct/09 ]

I have checked in the changes to add a compatibility element in the
sun-application.xml. This will provide a way for autodeploy/JSR88 to set the
compatibility flag to have v2 jar visibility behavior. I will keep the issue
open but downgrade to P3 for further enhancements on providing useful warning
messages for the cases where we could detect such packaging.

Comment by Hong Zhang [ 10/Dec/09 ]

One more request that's related to this property came from this forum thread:
http://forums.java.net/jive/post!reply.jspa?messageID=375716

Seems in v2, we also added module root level jars to the classpath, we should
probably also provide this jar visibility through the property in v3.1

Comment by Tom Mueller [ 06/Mar/12 ]

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

Comment by erpomata [ 12/Jun/13 ]

Any new about this issue?





[GLASSFISH-9720] provide a "safe shared lib folder" for deploying jars without affecting the application server Created: 24/Sep/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: kawazu Assignee: Hong Zhang
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: 9,720

 Description   

Situation:

Following test drives in gfv3-b64, I deployed a load of jar libraries shared by
all our internal applications (mostly webapps/war artifacts) to <domain>/lib/,
restarted the application server just to find the admin_gui not working anymore.
Upon closer inspection, I figured out that this behaviour could be triggered
reproducibly by dumping a xercesImpl.jar to <domain>/lib/.

Motivation:

We have pretty large webapp files, a bunch of third-party dependencies which
come as jar files, and many of them shared by all the webapps. From this point
of view it is sane not to put the jars into <webapp>/WEB-INF/lib/ but rather
place them directly in some "shared-library" folder, eventually accepting
certain restrictions (servlet.jar, ...).

However, such a folder to store shared libs should be treated in a way so that,
no matter which jar files will be stored there, it should never ever be
capable of damaging the application server as a whole as effects of such a
behaviour may be hard to foresee. Would it be possible to completely wreck, or,
worse, compromise (from a security point of view) the application server by
storing a prepared .jar in <domain>/lib/? At least talking about wrecking the
admin_gui, the answer seems yes.

Proposed solution / enhancement request:

Introduce a "safe shared library" folder which is the place to deploy jar
libraries used by applications (war, ejb, connectors, ...) deployed to the app
server without affecting the behaviour of the app server itself.



 Comments   
Comment by Sanjeeb Sahoo [ 24/Sep/09 ]

You didn't affect the application server by placing some jars in domain/lib; you
only affected admin gui, which is really another application deployed in the
server. I repeat, domain/lib does not and can not affect the server. Yes, it can
definitely affect all deployed applications, as it is a shared library folder.
Having said that, I don't think it is entirely wrong to assume admin gui to be
part of server. Now that we have support for OSGi-enabled web applications,
admin gui can use that approach and that way, it will have explicit control over
what it sees. But, that's a long term goal if at all.

You have other ways of deploying libraries as shared libraries. You can do the
following:
Copy all your library jars to domain/lib/applibs.
Create a manifest file like this (replace a.jar, b.jar by actual jar names):
Class-Path: a.jar b.jar
Do jar cvfm foo.jar manifest
Now deploy whichever applications need access to this library by running the
following command:
asadmin deploy --libraries foo.jar first.war

If you deploy a second war like this, the second war will use the same library
instance as the first war.

More details about --libraries option is available in GlassFish document or in
Siva's blog:
http://blogs.sun.com/sivakumart/entry/classloaders_in_glassfish_an_attempt

Hope this helps.

Comment by kawazu [ 24/Sep/09 ]

Re-opening it. Rationales:

(a) Indeed the admin_gui from my point of view is an integral part of the
application server so having someone being capable of rendering it useless
simply by deploying a "wrong" jar to <domain>/lib/ is pretty bad style at
all, especially considering there is no way of figuring out whether an actual
jar deployed there will (not) affect the admin_gui or any other applications
eventually installed. Sure, the latter problem won't possibly be resolved by a
"single" shared libraries folder but eventually will require more powerful means
of dependency / library management, but at least an end user should not be
capable of trashing a part of software that comes with the app server
(admin_gui) by deploying anything to it.

(b) The second approach is technically fine but then again I would, here, plead
for something like "asadmin deploy --shared-libs-folder=... <webapp>" to deploy
a webapp using all the libs placed in "shared-libs-folder", which is essentially
what I am asking for.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-9962] expand glassfish to support pylons Created: 03/Oct/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: jnewton Assignee: Hong Zhang
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Linux


Issuezilla Id: 9,962

 Description   

Given the support of glassfish with django pylons should be an easy expansion.
I've installed pylons to jython and used the following tutorials to create a
pylons app on glassfish to no avail:
http://weblogs.java.net/blog/vivekp/archive/2009/06/run_django_appl_1.html
http://pylonshq.com/docs/en/0.9.7/gettingstarted/#installing (everything below
creating a pylons project)

I get the following stacktraces when trying to deploy from helloworld/ :
~/glassfishv3/bin/asadmin deploy .
com.sun.enterprise.cli.framework.CommandException: remote failure: There is no
installed container capable of handling this application
com.sun.enterprise.deploy.shared.FileArchive@74a456bb

Command deploy failed.

and when using helloworld/helloworld :
com.sun.enterprise.cli.framework.CommandException: remote failure: Exception
while loading the app : java.lang.Exception: Module not started
org.glassfish.scripting.jython.JythonApplication@77fb58b6

Command deploy failed.



 Comments   
Comment by jnewton [ 03/Oct/09 ]

as a quick tip to install pylons use the mercurial repo and run the setup.py
method within, the go-pylons.py install script the tutorial opens with seems
incompatible with jython.

Comment by jnewton [ 03/Oct/09 ]
      • Issue 9962 has been confirmed by votes. ***
Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-14081] support .xxx (such as .war) as the sub module directory for directory deployment Created: 19/Oct/10  Updated: 18/Apr/13

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

Type: Improvement Priority: Major
Reporter: Hong Zhang Assignee: Hong Zhang
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: 14,081
Tags: ee7ri_cleanup_deferred

 Description   

Currently we assume the sub module directory name will always be _xxx (_war)
for directory deployment. But we should support .xxx (.war) as a valid suffix
as well.

Quoting the requirement from Ludo:
Complete requirement would be: whenever you expect a jar or war or lib real
file, either it is a file (working today) or it can be a directory. Names stay
the same.



 Comments   
Comment by Hong Zhang [ 23/Mar/11 ]

target for 3.2

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.

Comment by Jeremy_Lv [ 15/Apr/13 ]

Hong:
Need this improvement be finished in the next branch of the glassfish? It seems like an interesting issue..

Thanks

Comment by Hong Zhang [ 16/Apr/13 ]

Yeah, I meant to look into this but did not get a chance to. You can look into it if you have time..

Comment by Jeremy_Lv [ 17/Apr/13 ]

Hong:
Can we just decompression the related application and then continue the following steps?

Suggestion1).
For example:
Try to deploy the ear application as "asadmin deploy d:\test_ear", the construct of the directory will be as follows:
test_ear
----A.war
----B.jar
----META-INF

After the command has been executed, I think the directory construct of the test_ear should be changed as follows:
test_ear
----A.war
----B.jar
----META-INF
----A_war
----B_jar

Suggestion2).
If we don't accept the first suggestion, I think we may changed the original syntax about deploying the application for directory application, Which means we should copy the test_ear under the directory of GF_HOME/domains/domain1/application. But it will affect the performance of the deployment and change the syntax about deploying the application for directory deployment.

If we want to support this new feature, I think the first suggestion would be a good choice. Hong, What else suggestion can you suggest me?

Thanks.

-Jeremy

Comment by Hong Zhang [ 18/Apr/13 ]

No, we definitely should not copy directory. And the sub directories in the requested use case are already expanded, but just ends with ".xxx" instead of "_xxx", so we need to find in the current code where it makes assumption that the sub directory would be "_xxx" and make them accept ".xxx" also. I think the tricky part is ".jar" versus "_jar", with "_jar" we know it's a component jar (such as EJB jar) instead of a library jar. With ".jar", we might have to do extra processing to distinguish the component jars from library jars when introspecting application contents.

Comment by Jeremy_Lv [ 18/Apr/13 ]

Hong:
I have look into the ApplicationLifecycle.java and found the code of archiveHandler.expand(archive, expandedArchive, initial); is start to expand the file into _war or _jar.

BTW: I found it is illegal to rename the directory with the suffix of .war and .jar on the windows platform. So if we want to implement this, I think it maybe the feature only support on the linux platform.

I agree with your anxious about the situation to the .jar, As some of the situation seems complex, I think I need to consider more about it...

Comment by Hong Zhang [ 18/Apr/13 ]

This is for directory support, so we don't need to expand the directories again. Just the expanded sub directory name is with ".war" instead of "_war" as we currently support.





[GLASSFISH-12793] Ability to Load Individual Servlets without reloading entire web app Created: 26/Jul/10  Updated: 23/Mar/11

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

Type: Improvement Priority: Major
Reporter: hoffman462 Assignee: Hong Zhang
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://forums.java.net/jive/thread.jspa?threadID=79152


Attachments: Zip Archive dynamicreload.zip    
Issue Links:
Duplicate
is duplicated by GLASSFISH-15928 Dynamic Reload doesnt work for servlet Closed
Issuezilla Id: 12,793

 Description   

It would be helpful if it was possible to deploy or load a single new servlet
listed in the web.xml file without causing issues / or redeploying all ejbs, or
other resources (JMS queues, etc..).

This has been discussed here, and more information is contained in the post:

http://forums.java.net/jive/thread.jspa?threadID=79152



 Comments   
Comment by fsousa [ 26/Jul/10 ]
      • Issue 12793 has been confirmed by votes. ***
Comment by Hong Zhang [ 26/Jul/10 ]

Thanks for filing the RFE to track this, we wil revisit it when planning the
next release.

Comment by tetyanac [ 10/Feb/11 ]

Continuation from issue 15928
Last comment:

>Hong Zhang added a comment - 10/Feb/11 06:13 PM
>You can attach the application (and the modified bits) in its duplicated issue (12793) with exact steps and we will take look to see if we can reproduce it.
>So after you saved the .reload file, you didn't see anything in the server.log indicating the application is being reloaded?
>What do you mean it changed only after you executed reloading of the application, do the "reload" here mean redeploy the application?

I didn't see anything in server.log. Under "reload" I clicked "reload" for application in the applications list in the GUI console.

Here is my source. Deploy, click "http://localhost:8080/dynamicreload/TestServlet", then go to TestServlet.java, change message, compile, package into WAR, unpack into domains/domain1/applications/dynamicreload, change there .reload file, and access again the link.
I didnt get new message. What am I doing wrong?

Comment by Hong Zhang [ 11/Feb/11 ]

Which build were you using? When we tried to reproduce the problem today we actually found some issues with the dynamic reload functionality:
http://java.net/jira/browse/GLASSFISH-15963

The fix will go in soon and you can try again with the next promoted build b42 (should be out next Monday).

Comment by tetyanac [ 14/Feb/11 ]

I use build 3.1_b38.
I will try new build.

Comment by tetyanac [ 14/Feb/11 ]

Same problem for GF 3.1_b42.

Comment by Tim Quinn [ 15/Feb/11 ]

Which specific 3.1_b42 did you use and on what operating system?

The fix for the .reload problem Hong referred to was checked in at 3:00 p.m. Pacific time on Feb. 11. the only b42 build that would have the fix is the one from Feb. 13.

I just downloaded the Feb. 13 b42 and used the example app, changed TestServlet, recompiled it and rebuild the war, expanded the whole war into dynamicreload again (although copying the new TestServlet.class would be sufficient), and ran "touch xxx/dynamicreload/.reload" and when I reloaded the web page in my browser the new servlet was used.

Comment by tetyanac [ 15/Feb/11 ]

I downloaded glassfish-3.1-b42.zip ant tested on it on Windows XP.

I got new Servlet behaviour only after I click reload of application in GUI admin. The problem is still here.

Comment by Tim Quinn [ 16/Feb/11 ]

You did not mention which specific build 42 you downloaded. There are multiple ones from different dates and not all of them contain the fix for the .reload handling.

I just downloaded this build

http://dlc.sun.com.edgesuite.net/glassfish/3.1/nightly/glassfish-3.1-b42-02_13_2011.zip

onto two different Windows XP systems. On both systems I have:

deployed your example app,

accessed http://localhost:8080/dynamicreload

edited src\webtest\TestServlet.java to display a different message

recompiled src\webtest\TestServlet.java

copied the new webtest\TestServlet.class into glassfish\domains\domain1\applications\dynamicreload\WEB-INF\classes\webtest

used notepad to create .reload in glassfish\domains\domain1\applications\dynamicreload

accessed the app again

and this displayed the new output.

The .reload feature is working for me.

Comment by tetyanac [ 16/Feb/11 ]

I downloaded from http://dlc.sun.com.edgesuite.net/glassfish/3.1/promoted/:

[ ] glassfish-3.1-b42.zip 14-Feb-2011 09:27 78M

Seems it is released after that you mentioned.

Could you please check whether it contains the discussed fix?

Thank you

Comment by Tim Quinn [ 16/Feb/11 ]

There is an even more recent promoted build now: b43. Use that one.

The .reload feature works correctly in promoted b43. I am confident it also works in promoted build 42 since earlier, nightly builds of b42 worked correctly.

Comment by tetyanac [ 16/Feb/11 ]

Thank you. Now it works as expected.





[GLASSFISH-12699] Allow deploy command to accept URI Created: 17/Jul/10  Updated: 21/Jan/13

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Hong Zhang
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
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive GLASSFISH-12699_REVISED_SOURCE.zip     Text File pathToUri_patch.txt    
Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-19497 Can't get the proper path when deploy... Sub-task Closed Hong Zhang  
GLASSFISH-19529 The asadmin client should support the... Sub-task Resolved Tom Mueller  
Issuezilla Id: 12,699

 Description   

Currently deploy, redeploy commands accept a file path. It will be nice if they
accept a URI instead. I am attaching a patch which is an attempt to address
this, but I don't think it is complete. Any way, if someone wants to take a stab
at this issue, the patch may come handy.



 Comments   
Comment by Sanjeeb Sahoo [ 17/Jul/10 ]

Created an attachment (id=4587)
Patch generated against svn rev #38356

Comment by Hong Zhang [ 17/Jul/10 ]

add tim to CC, tim is more familiar with this part

Comment by Tom Mueller [ 06/Mar/12 ]

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

Comment by Jeremy_Lv [ 18/Dec/12 ]

Dear Hong, Sahoo:
I have updated the Sahoo's patch and have this new feature accomplished. But what I have revised is only can be used for deploying the applications in the local space.
i.e:asadmin deploy file:/e:/test_sample1.war(also can be useful about the operation of redeployment)

I have attached the revised source to the JIRA, please review my modification.

BTW: If we need to implement the operation about deploying the application in the Internet(i.e:deploy as http,ftp,https), we can discuss about this scenario first before I have it implemented.
i.e:(asadmin deploy http://http://java.net/jira/secure/attachment/50467/test_sample1.war)

Best Regards
-Jeremy

Comment by Hong Zhang [ 18/Dec/12 ]

Jeremy: thanks for looking into this enhancement and continuing to contribute to GlassFish!

Some comments from my initial look at the changes:

1. When a command line option is File type and annotated with @Param, the admin infrastructure will upload the file from local machine to remote machine. With the changes in DeployCommandParameters, can you make sure the cluster scenario still work as expected, the file will get uploaded as expected? I saw there are changes in MapInjectionResolver which probably take care of this, but want to double check things still work as expected for cluster scenario.

2. Can you try the server restart scenario to make sure things are working as expected there also (deploy application, restart server, and see if application is loaded properly during server start up and can be accessed afterwards)? This is a pretty significant change and I want to make sure there is no regression to the existing scenarios.

3. Run deployment dev tests in PE and EE mode and also run ejb dev tests.

4. Add some new tests in the deployment dev tests to cover the new scenario and enable these tests for both PE and EE mode.

5. The admin related changes (for example, MapInjectionResolver) need to be reviewed by the admin team. We can write to Tom Mueller about this after we make sure the various scenarios are working ok.

And yes we can have further discussions if we decide to expand the feature to support internet protocols.

Comment by Jeremy_Lv [ 09/Jan/13 ]

[Latest investigation]
The changes of mine to support the scenario about 12699 makes the original scenario about deploying the application as File(only deploy the application as relative path) doesn't work...

After I look into the code, I found the value in EntityParamValueFactoryProvider.java(jersey modules) doesn't get the correct value while deploying the application as relative path in File way(e.g: asadmin deploy test.jar)

value = requestContext.readEntity(rawType, parameter.getType(), parameter.getAnnotations());

the value here should be get the absolute path while it just get the name of the deployed application.

However, it can be deployed successfully as absolute path in File way.

Should the original scenario about deploying the application as File way still be support after it is support the URI?

Comment by Sanjeeb Sahoo [ 09/Jan/13 ]

Existing behavior has to be maintained for compatibility reasons. I think it will be reasonable to support the URI syntax for absolute URIs only. An absolute URI always has a scheme component.

Comment by Jeremy_Lv [ 10/Jan/13 ]

Dear Hong, Sahoo, Tom:
I have a question for you. Should the new feature about deploying the application accept the URI instead of File or accept the URI syntax without any changes about File syntax?

Comment by Jeremy_Lv [ 10/Jan/13 ]

After some of my investigation, I found something different between the two definations as follows:
Sample1:

 
    @Param(primary=true) 
    public File path; 
    public File getPath() { 
      return path; 
    } 

Sample2:

 
    private File path; 
     
    @Param(primary=true) 
    public void setPath(File path) { 
        this.path = path; 
    } 
     
    public File getPath() { 
      return path; 
    } 

When the @Param are defined to declare the method as the Sample2 shows, The value of "DEFAULT" is not correct when deployed as a relative File path. the jersey side get the wrong value of "reqeust" when DeployCommandParameters defined as Sample2.

Comment by Hong Zhang [ 10/Jan/13 ]

We have to continue supporting File path for backward compatibility. If that only allows us to support absolute URI, that's fine. We just need to give a good error message for the unsupported case.

I don't know the details of how the payload works (with injected File param), Tom probably knows more about that to explain why. But you will probably need to write an email to him to get his attention on this as I don't think he is monitoring issues outside of the admin area..

Comment by Tom Mueller [ 14/Jan/13 ]

While looking at the subtask GLASSFISH-19529, I decided to comment on this issue instead.

First, what are the expected semantics for the original request? If the deploy command is invoked with a URI, what is the asadmin client expected to do? For example, is the client expected to fetch the content of the URI and then treat that content the same way it treats a file today? Is the URI supposed to be passed to the server, and then the server is supposed to fetch the content of the URI? A key question is, where does the URI client code execute?

Second, since the original syntax must be supported, how is the command parameter actually declared. If it is a URI (as the subtask requests), is the asadmin client expected to convert a path argument to a URI argument automatically? How is the asadmin client supposed to know that the default URI scheme should be "file://"? Is the implementation to be hardcoded this way, or is it necessary to allow the default scheme to be specified by the command.

Or, is the idea hear to allow the operand to be of varying types depending on what is entered by the user? If it looks like a URI, then just the URI is passed, but if it looks like a path, then a File is passed? What would the @Param declaration for a command look like in this case?

Another option might be to have a "deployuri" command (similar to deploydir) which could have a different declaration for the operand.

If just a URI is to be passed to the server (not the content), and the URI references a local file, how would the server access the file if asadmin is remote from the server?

In summary, the following design options seem feasible:

1) Add a deployuri command for which the operand is a String which is passed to the server and the server resolves the URI. Therefore the URI must be resolvable by the server (can't be a file:// URI to a local file that is remote from the server).

2) Modify the CLI framework so that a File parameter (option or operand) can be specified as a URI. In that case, the asadmin client would resolve the URI and download its content to a temporary file which would then be passed as a File parameter like any other File parameter. This option would require no changes to the deploy command at all. With this option, a file:// URI to a file that is local to asadmin would work when the server is remote, but a file:// URI to a file that is local to the server but not asadmin would not work.

Other more complicated options would be to have some way of having a command option that is either a File or a URI but I haven't specified that design here.

Comment by Sanjeeb Sahoo [ 14/Jan/13 ]

I support option #1. It keeps things simple.

Sahoo

Comment by Jeremy_Lv [ 15/Jan/13 ]

First, what are the expected semantics for the original request? If the deploy command is invoked with a URI, what is the asadmin client expected to do? For example, is the client expected to fetch the content of the URI and then treat that content the same way it treats a file today? Is the URI supposed to be passed to the server, and then the server is surpposed to fetch the content of the URI? A key question is, where does the URI client code execute?

What I have supposed to do is that the client expected to fetch the content of the URI and then treat that content the same way it treats a file today.

Second, since the original syntax must be supported, how is the command parameter actually declared. If it is a URI (as the subtask requests), is the asadmin client expected to convert a path argument to a URI argument automatically? How is the asadmin client supposed to know that the default URI scheme should be "file://"? Is the implementation to be hardcoded this way, or is it necessary to allow the default scheme to be specified by the command.
Or, is the idea hear to allow the operand to be of varying types depending on what is entered by the user? If it looks like a URI, then just the URI is passed, but if it looks like a path, then a File is passed? What would the @Param declaration for a command look like in this case?

What I have revised is to define a path as a URI parameter. Then I will try to convert a path argument to a URI argument when it is excuted in the asadmin client.

All in all, What I have revised is based on the option#2, which is defined a URI parameter and change the File to URI when the application is deployed as a File.

BTW: If we decide to take the option#1, I will look into the logical about deploydir first before I code.

Comment by Jeremy_Lv [ 15/Jan/13 ]

Thanks for Tom's suggestion, After being compare these two options I think the option#1 seems better than option#2.
It seems not diffcult to develop and it is no longer to change codes in CLI.

Comment by Jeremy_Lv [ 15/Jan/13 ]

As the JIRA file system can not work, I have sent my modification by email. please check it.

Comment by Jeremy_Lv [ 21/Jan/13 ]

Hi,All:
As Tom has been suggested, I want to make sure what function should I implement.
Here is my option:
1.Support a new command like "deployuri", The "deployuri" will support the following options
1).--name <name>
2).--contextroot <contextroot>
3).--virtualservers <virtualservers>
4).--libraries <libraries>
5).--force[=<force(default:false)>]
6).--precompilejsp[=<precompilejsp(default:false)>]
7).--verify[=<verify(default:false)>]
8).--retrieve <retrieve>
9).--dbvendorname <dbvendorname>
10).--createtables[=<createtables(default:false)>]
11).--dropandcreatetables[=<dropandcreatetables(default:false)>]
12).--uniquetablenames[=<uniquetablenames(default:false)>]
13).--deploymentplan <deploymentplan>
14).--altdd <altdd>
15).--runtimealtdd <runtimealtdd>
16).--enabled[=<enabled(default:false)>]
17).--generatermistubs[=<generatermistubs(default:false)>]
18).--availabilityenabled[=<availabilityenabled(default:false)>]
20).--asyncreplication[=<asyncreplication(default:true)>]
21).--target <target>
22).--keepreposdir[=<keepreposdir(default:false)>
23).--keepfailedstubs[=<keepfailedstubs(default:false)>]
24).--logreportederrors[=<logreportederrors(default:true)>]
25).--description <description>
26).--properties <properties>
27).--property <property>
28).--type <type>
29).--keepstate[=<keepstate(default:false)>]
30).--lbenabled <lbenabled>
31).--deploymentorder <deploymentorder>
32).--upload[=<upload(default:false)>]
33).?|-help[=<help(default:false)>]

BTW:As the application is deployed as URI, Should we give up the function about --upload? (The original option about --upload is support for File types.)

2.Should I support another command which is used for redeploy the application as URI?(As the description shows)

Notice: As the URI is complex type to use, I think I will support the file:// syntax first.

If someone want to present more options about this improvement, please comments.

Best regards
-Jeremy





[GLASSFISH-13518] asadmin deploy won't come back when mistakenly specifying dir name Created: 17/Sep/10  Updated: 02/May/11

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

Type: Improvement Priority: Major
Reporter: Dies Koper Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 13,518

 Description   

I accidentally passed a directory name instead of a file name to asadmin deploy.
The hard disk's been grinding for 10 minutes but the command is not coming back.
Also no messages in server.log. GF is being very unforgiving..

D:\GFv3.1\glassfish-3.1-b21-09_17_2010\glassfishv3>bin\asadmin deploy \



 Comments   
Comment by Hong Zhang [ 17/Sep/10 ]

Dies: it's not so much of archive vs directory which makes the disk grinding,
it's more of the directory got passed in is the root path "\"!. So it's trying
to scan the whole root directory to see if it finds a JavaEE component jar
through annotation scanning. If you package the whole root directory into a
giant jar file, it will take just as much time.

Try to pass a small sub directory with not many files in it, and see how much
time before it returns.

Comment by Dies Koper [ 17/Sep/10 ]

I've never accidentally packaged the whole root directory and tried deploying it
but I have confirmed that with an empty sub-directory it comes back quickly.

So I'm not sure what is the root issue here.
The man pages say the operand is a file, not a directory, so if the man pages
are correct it could just check whether a file or directory was specified and
return an error immediately.

If the man pages are wrong, and it is supposed to traverse all subdirectories
searching for applications, then that's an issue by itself. Most Unix but also
Windows commands don't recursively go into each subdirectory unless some
recursive option has been explicitly specified. GF should operate the same.

In my case I tried to specify an application by using tab completion (and who
doesn't) and it picked a directory instead (note that on Windows it picks the
first match and you can cycle through the candidates by pressing tab again).
When this happened to me I didn't actually deploy '\' but still the
sub-directory that was picked had enough files for asadmin to become unresponsive.

Comment by Hong Zhang [ 20/Sep/10 ]

If the man page says it can only take a file, it needs to be updated to say
take both file and directory. The deploydir command is deprecated and the
deploy command is the one that should be used for both file and directory.
About going into sub directories: yes, the logic does go to the sub directories
to scan for component annotations. For ear case, the sub modules are in the sub
directories. And the component jars could be come in the form of a library jar
too, for example in WEB-INF/lib for ejb in war case.

Comment by Hong Zhang [ 28/Sep/10 ]

dies: Are you ok for me to close this issue? As I said in my previous comments,
we do need to go to the sub directories to process sub modules and scan library
jars to scan for annotations.

Comment by Dies Koper [ 28/Sep/10 ]

Could you close it after addressing the issues I brought up?

1. The man page is wrong. Closing this issue won't fix it.

2. I understand you want to merge 'deploydir' into the 'deploy' command and
therefore need to scan library jars. But scanning all subdirectories without
warning can be very annoying. I think it's better to add a '--recursive' option
and let the user explicitly express their wish to go into all subdirectories
when they want it to. Default (no option) would be to only check the specified
dir (or relevant dirs, like ./WEB-INF/lib, etc.)

Comment by Hong Zhang [ 04/Oct/10 ]

scrubbing issues

Comment by Hong Zhang [ 07/Dec/10 ]

I have provided this feedback to the doc team and now the latest 3.1 man page (not published officially yet) has reflected this change.

I am not sure how easy it is to decide what directories and the depth that we should scan by default: libraries could be at random places and referenced through manifest, class files could be located in a deep directory layout. I am going to mark this issue as an enhancement now and see if there is anything we can do in the future release.





[GLASSFISH-13505] separate autodeployment and autodeployment status files Created: 16/Sep/10  Updated: 09/Mar/13

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: v3.0.1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: sroughto Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 13,505

 Description   

Currently Glassfish creates a subdirectory and *.war_deployed files in the autodeployment directory. It
would be helpful if an option existed to place status files in a separate user-specified directory, e.g.,
/var/opt/glassfish/autodeploy, leaving the autodeploy directory unmodified.

By default, the existing behavior would continue (storing status files in the same directory as
autodeployment wars).

Justification: We want to deploy from a read-only volume, such as a read-only QFS directory, internet
cloud directory, etc. Currently this requires a work-around, such as using cron to copy the files from
the read-only volume to a read-write directory where Glassfish can create status files.



 Comments   
Comment by Hong Zhang [ 10/Oct/12 ]

Scrubbing RFEs for GlassFish 4.0.

Comment by sroughto [ 09/Mar/13 ]

Another example is setting autodeploy to a developer's network (NFS) home directory, e.g., /home/userid/autodeploy. It would be helpful if the Glassfish server did not require write permissions on the developer's NFS directory, but rather stored its status files in a local directory such as /var/opt/glassfish/autodeploy.status.





[GLASSFISH-13391] Preserve sessions across versioned applications Created: 13/Sep/10  Updated: 02/Dec/11

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

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

Operating System: Linux
Platform: Linux


Issuezilla Id: 13,391

 Description   

Here are the things I had in mind about that currently:

this is a different approach than quiescing, as the version is switched even if some
people are still using the old version, the sessions are forwarded to the new version.
I think there is a limit to the session preservation:
it depends on how much different are the sessions of the two versions being switched ;
how would we handle that case:

  • do we just let things happen and if the versions are too much different this might
    involve some unexpected behavior,
  • or do we figure out if the two versions are compatible each other to preserve their
    sessions and prevent the switch if they are not compatible?





[GLASSFISH-12501] support command line options in glassfish specific deployment descriptors Created: 06/Jul/10  Updated: 15/May/13

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: Hong Zhang Assignee: Hong Zhang
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: 12,501

 Description   

It's useful to allow user to specify command line options through glassfish
specific deployment descriptors, especially for autodeploy and JSR88.

Ludo suggested we could support them generically through a deployment-params
element:
<deployment-params> --foo=bar --keeptable =true etc etc
</deployment-params>

And later Bill suggested rather than creating another place that has to parse a
command line, it probably be more appropriate to have a general way to specify
option names and values as XML:

<deployment-params>
<param><name>foo</name><value>bar</value></param>
<param><name>keepstate</name><value>true</value></param>
</deployment-params>

I don't think we will have time to address this in 3.1 release, but file a RFE
to track this and we will revisit in next release.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

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

Comment by Jeremy_Lv [ 15/May/13 ]

I agree with you, it will be more useful if we implement this..





[GLASSFISH-6677] Warning when using a Resource in context.xml Created: 31/Oct/08  Updated: 07/Mar/12

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

Type: Bug Priority: Major
Reporter: lancea Assignee: Hong Zhang
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: File JPAWeb_V3.war     Text File JPAWeb_V3.zip     Text File server.log    
Issuezilla Id: 6,677
Status Whiteboard:

3.1-exclude

Tags: 3_1-exclude

 Description   

When I start prelude I get the following warning:

WARNING: This web app [/C:/Netbeans/JPAWeb_V3/build/web/] has no resource
reference by the name of [jdbc/mysqlTestDB]

I have this resource defined in context.xml:

<?xml version="1.0" encoding="UTF-8"?>
<Context path="/JPAWeb_V3">
<Resource
name="jdbc/mysqlTestDB"
auth="Container"
type="javax.sql.DataSource"/>

</Context>

The sun-web.xml contains:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server
9.0 Servlet 2.5//EN"
"http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd">
<sun-web-app error-url="">
<context-root>/JPAWeb_V3</context-root>
<resource-ref>
<res-ref-name>jdbc/mysqlTestDB</res-ref-name>
<jndi-name>jdbc/mysqlTestDB</jndi-name>
</resource-ref>
<class-loader delegate="true"/>
<jsp-config>
<property name="classdebuginfo" value="true">
<description>Enable debug info compilation in the generated servlet
class</description>
</property>
<property name="mappedfile" value="true">
<description>Maintain a one-to-one correspondence between static content
and the generated servlet class' java code</description>
</property>
</jsp-config>
</sun-web-app>

There is no entry in web.xml for jdbc/mysqlTestDB and the app works fine.

Now if I do not use the context.xml and instead add the entry to web.xml I do
not see the warning when I reboot (which makes sense):

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<servlet>
<servlet-name>ContactServlet</servlet-name>
<servlet-class>demo.servlet.ContactServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>ContactServlet</servlet-name>
<url-pattern>/ContactServlet</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ContactServlet</servlet-name>
<url-pattern>/displayContacts</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ContactServlet</servlet-name>
<url-pattern>/addContact</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
</welcome-file-list>
<resource-ref>
<res-ref-name>jdbc/mysqlTestDB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
</web-app>

I assume the warning is being generated because the context.xml is not being
taken into consideration?

Also another interesting scenario is if i do not put the resource-ref in
sun-web.xml of
<resource-ref>
<res-ref-name>jdbc/mysqlTestDB</res-ref-name>
<jndi-name>jdbc/mysqlTestDB</jndi-name>
</resource-ref>

I get the following error (which makes sense) using JSTL tag of

<sql:query var="resultSet" dataSource="jdbc/mysqlTestDB" >
select * from contacts
</sql:query>

javax.servlet.ServletException: javax.servlet.jsp.JspException: Unable to get
connection, DataSource invalid: "java.sql.SQLException: No suitable driver found
for jdbc/mysqlTestDB"

I am going to log an issue as the error can be clearer. However the interesting
part is that my app which uses Eclipselink has no issues using the same JNDI
resource:

<persistence-unit name="JPAContactJNDIPU" transaction-type="RESOURCE_LOCAL">
<non-jta-data-source>jdbc/mysqlTestDB</non-jta-data-source>
<class>demo.entity.Contact</class>
<properties>
<property name="eclipselink.logging.level" value="FINEST"/>
<property name="eclipselink.ddl-generation" value="create-tables"/>
</properties>
</persistence-unit>



 Comments   
Comment by Amy Roh [ 06/Nov/08 ]

Hi Lance,

It'd help tremendously if you could attach both working and non-working webapp
mentioned in the bug report to help me debug the issue.

Thanks!
Amy

Comment by lancea [ 06/Nov/08 ]

Created an attachment (id=2076)
Deploy this app and you will see the warning

Comment by lancea [ 06/Nov/08 ]

Hi Amy,

The zip i attached you can deploy to see the warning. Then just add the
Resource Ref to the web.xml and redeploy and the warning is gone.

-lance

Comment by Amy Roh [ 12/Nov/08 ]

Created an attachment (id=2099)
JPAWeb_V3.war

Comment by Amy Roh [ 12/Nov/08 ]

Created an attachment (id=2100)
server.log

Comment by Amy Roh [ 12/Nov/08 ]

Strangely, I'm not seeing the warning mentioned deploying the attached war. The
full server.log is also attached.

Comment by Amy Roh [ 25/Sep/09 ]

A warning gets displayed when you have a resource-ref definition in sun-web.xml
and no entry in web.xml (although the Resource entry exists in context.xml)
because deployment does not check context.xml.

In WebBundleDescriptor:

public ResourceReferenceDescriptor getResourceReferenceByName(String name) {
for (ResourceReference next : getResourceReferenceDescriptors()) {
if (next.getName().equals(name))

{ return (ResourceReferenceDescriptor) next; }

}
throw new IllegalArgumentException(localStrings.getLocalString(
"enterprise.deployment.exceptionwebapphasnoresourcerefbyname",
"This web app [

{0}

] has no resource reference by the name of
[

{1}

]", new Object[]

{getName(), name}

));
}

Not easy to fix since the web.xml and sun-web.xml are parsed by the deployment
code, and the context.xml is parsed by the web container much later. So when
deployment processes the sun-web.xml, we don't really have access to information
in context.xml yet.

Comment by Amy Roh [ 08/Oct/09 ]

Need to parse the context.xml during deployment so that context.xml information
is available during deployment. Will address this for the next release.

Comment by Amy Roh [ 01/Oct/10 ]

3.1-exclude

Comment by Tom Mueller [ 06/Mar/12 ]

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

Comment by Amy Roh [ 07/Mar/12 ]

Need to parse the context.xml during deployment so that context.xml information is available during deployment. Assign to deployment team to investigate fixing this in the future release.





[GLASSFISH-6600] Deployer should allow deployment of single file Created: 21/Oct/08  Updated: 13/Jun/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: vivekp Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 6,600

 Description   

JRuby connector supports many ruby based frameworks, one of the framework
'Sinatra' could have just one ruby file. Sinatra provides a simple and powerful
way to create restful apps in ruby.

So if the Sinatra file is: blog.rb which has contents such as:

require "rubygems"
require "sinatra"
get '/' do
"And the blogging begins"
end

So we expect the deployment to happen as, asadmin deploy blog.rb. When I try to
deploy it, the deployer expects it to be a zip archive and then fails
deployment. This restriction is unnecessary, given that the container can handle
such archive.

This enhacement will be needed to support frameworks such as Sinatra or any such
framework where the deployable artifact is not an archive but rather just some
script or file.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

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

Comment by Tim Quinn [ 13/Jun/12 ]

Reassigning to deployment lead.





[GLASSFISH-5169] Consider using Apache commons HttpClient and FileUpload to handle multiple file uploads Created: 16/Jun/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: not determined

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 5,169
Status Whiteboard:

gfv3-prelude-included


 Description   

The current implementation for uploading multiple files in a single (deployment)
request creates a ZipEntry for each file to be uploaded and writes a
ZipOutputStream into the outbound http request containing those ZipEntry
objects. The AdminAdapter then extracts those uploaded files into temp files on
the server.

A more standards-friendly way to do this would be to use multipart/mixed POST
https requests. The Apache HttpClient and FileUpload projects would make doing
it that way pretty simple.

This looks like it would require splitting the current
distributions/external/apache-commons module into at least two, one for the
client side and one for the server side (to avoid requiring things on the client
side that are not needed) and adding HttpClient and FileUpload.

Because the multifile upload is currently working, this is a relatively low
priority and can be deferred until a future release of v3.



 Comments   
Comment by Tim Quinn [ 16/Jun/08 ]

This should not require too much work but it's lower priority than some other
things right now. Also will take some discussion to agree on splitting the
distributions/external/apache-commons into two pieces: client-side and server-side.

Comment by kumara [ 19/Aug/08 ]

Add gfv3-prelude-include to status whiteboard

Comment by kumara [ 03/Sep/08 ]

v3 defect tracking

Comment by Tim Quinn [ 03/Sep/08 ]

Changing to enhancement request.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-5267] Cannot see Context URL for .war in .ear Created: 07/Jul/08  Updated: 16/Apr/13

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

Type: Improvement Priority: Major
Reporter: mkarg Assignee: Hong Zhang
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: 5,267

 Description   

Sometimes it happens that, due to several reasons, the administrator decides to
bind a .war file to some particular Context URL. So he changes the Context URL
found in the admin GUI for that .war.

Unfortunately, when the .war is not standalone but part of an .ear file, the
administrator does not see that Context URL. So he cannot change it.



 Comments   
Comment by harpreet [ 04/Sep/08 ]

Marking target milestone as 9.1.1

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 mkarg [ 27/Apr/09 ]

Increased priority to P3 according to
https://glassfish.dev.java.net/public/IssueTrackerPriority.html. The ability to
change the context URL is an essential feature for a lot of customers, so not
being able to do that is a major usability issue. Also until now nobody filed a
workaround in the comments list of this issue, so it seems there is no workaround.

Comment by Anissa Lam [ 22/Sep/09 ]

Admin Console is not designed to show context root of embedded war, and doesn't
provide launching embedded war either.
This is not a bug, but RFE. Marking as such.
To do this, we need deployment backend to provide an API so that we can get the
context root of embedded war. Currently this is not available.
Transferring to "deployment". If this API is available, please reassign to GUI
to finish the implementation.

Comment by Hong Zhang [ 10/Oct/12 ]

Scrubbing RFEs for GlassFish 4.0.

Comment by Jeremy_Lv [ 15/Apr/13 ]

It seems like the issue about http://java.net/jira/browse/GLASSFISH-11710.

Comment by Hong Zhang [ 16/Apr/13 ]

Currently only the context roots of the standalone modules are stored in the domain.xml, maybe we should make it consistent and store the context roots of the web modules which are part of the ear in the domain.xml also which could make this kind of editing possible. We can explore more about this in next release.





[GLASSFISH-5246] Add URL as a possible location to get a deployment unit Created: 01/Jul/08  Updated: 06/May/13

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: v2.1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: jkilgrow Assignee: Hong Zhang
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: 5,246

 Description   

Currently in the admin gui and admin cli we are given 2 options for where to
find a deployment unit:
1. Packaged file to be uploaded to the server
2. Local packaged file or directory that is accessible from the Application Server

It would be great if we could use a URL for the location. This would help when a
deployment unit is stored in a maven repository.



 Comments   
Comment by km [ 01/Jul/08 ]

This is an excellent suggestion! Sharing can be vastly improved because of this.
Most of the actions in deployment can remain as they are, it is only the
question of downloading the archive before deployment commences.

Another way would be for the "server" to deploy directly from the URL and
download the archive exactly once.

What protocols (http, ftp etc.) do you think should be supported?

Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Hong Zhang [ 10/Oct/12 ]

Scrubbing RFEs for GlassFish 4.0.

Comment by Jeremy_Lv [ 06/May/13 ]

issue duplicated to the GLASSFISH-12699 .





[GLASSFISH-8430] MAKE AutoDeploy more Flexible Created: 22/May/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: Byron Nevins Assignee: Hong Zhang
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: 8,430

 Description   

I have an Embedded Customer that came up with a pretty cool "roll your own"
auto-deploy solution. He monitors 2 different directories.
In one of the directories he drops regular apps that get deployed to a
http/virtual server.
In the other one he drops apps that get deployed to a different https/virtual server

From what I've figured out from looking at the code in deployment/autodeploy and
examining domain.xml is that

1. Autodeploy can fairly easily be modified to have multiple instances
monitoring different directories
2. Autodeploy's granularity is at a sever-config level currently.

Proposal:

Allow AutoDeploy attributes inside http-service config as well as server-config.
Then the user can easily setup auto-deploy directories at a Virtual-server
granularity and do what my customer did just by making a few changes to the config.



 Comments   
Comment by Byron Nevins [ 22/May/09 ]

Kedar might be interested – adding him...

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-14367] FileArchive.entries() now returns dir entries unlike other archives Created: 02/Nov/10  Updated: 09/Feb/13

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

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Mitesh Meswani
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: 14,367
Tags: 3_1-exclude

 Description   

FileArchive was changed to return dirs also. This was part of
http://fisheye4.atlassian.com/changelog/glassfish-svn/?cs=36443 to solve
https://glassfish.dev.java.net/issues/show_bug.cgi?id=11766
This enabled exploded archive deployment.

Other existing Archive implementations don't return directory entries and it is
arguable either way what is the desired behavior looking at the javadocs of
Archive.entries() and Archive.isDirectory().

The only benefit of not including directory entries in entries() is that
Archive.getEntry() returns null as the InputStream for a directory entry - there
is no choice - a directory can't be read as a stream. So, including directory
entries in entries() means anyone iterating over them has to do a null check now
which they didn't have to do earlier. One such code is in
ReadableArchiveScannerAdapter. Even if we decide to change the semantics of
entries(), we have to change all implementations to be consistent.

The second plan of action is to evaluate an alternative fix that would address
the original issue 11766. Mitesh and I spoke about it and he is going to try out
an alternative that we outlined during the talk. As per the discussion, I am
assigning this to Mitesh.



 Comments   
Comment by Mitesh Meswani [ 21/Dec/10 ]

Targeting for 3.2





[GLASSFISH-3145] retain application attributes during auto-redeployment Created: 07/Jun/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 9.1pe
Fix Version/s: not determined

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

Operating System: All
Platform: Linux


Issuezilla Id: 3,145

 Description   

For auto redeploy case, user doesn't have the opportunity to specify application
attributes. It will be the more user friendly behavior to retain the attribute
values during redeployment.

Related forum thread:
http://forums.java.net/jive/thread.jspa?messageID=220918



 Comments   
Comment by Hong Zhang [ 07/Jun/07 ]

accepted

Comment by Hong Zhang [ 08/Nov/07 ]

look in v3

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-3386] Glassfish V2 and exploded deployments Created: 20/Jul/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: ivicac Assignee: Hong Zhang
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,386

 Description   

I am using glassfish V2 build 56. I am trying to use exploded deployment but
without any success. My structure of EAR is:
ctg.main.ear - exploded
ctg-main-war.war - exploded
ctg-main-ejb.jar - exploded
lib
META-INF
jboss-seam.jar - archive

Exploded directories are created by myeclipse.

After deployment I am getting the next exceptions:

2007.07.20 19:17:43 com.sun.enterprise.server.PEMain main
INFO: Starting Sun Java System Application Server 9.1 (build b56-rc) ...
2007.07.20 19:17:43 com.sun.enterprise.server.PEMain$LoadMBeanServer doRun
INFO: MBeanServer started: com.sun.enterprise.interceptor.DynamicInterceptor
2007.07.20 19:17:43 com.sun.enterprise.server.ss.ASLazyKernel startASSocketServices
INFO: CORE5098: AS Socket Service Initialization has been completed.
2007.07.20 19:17:43 com.sun.enterprise.server.ApplicationServer printStartupInfo
INFO: CORE5076: Using [Java HotSpot(TM) Client VM, Version 1.6.0_02] from [Sun
Microsystems Inc.]
2007.07.20 19:17:44 com.sun.enterprise.security.SecurityLifecycle <init>
INFO: SEC1002: Security Manager is OFF.
2007.07.20 19:17:44
com.sun.enterprise.server.logging.SystemOutandErrHandler$LoggingByteArrayOutputStream
flush
INFO: C:\appservers\glassfish\domains\domain1/config/.__com_sun_appserv_pid
2007.07.20 19:17:45 com.sun.enterprise.admin.server.core.AdminService init
INFO: ADM0001:SunoneInterceptor is now enabled
2007.07.20 19:17:45 com.sun.enterprise.security.PolicyLoader loadPolicy
INFO: SEC1143: Loading policy provider
com.sun.enterprise.security.provider.PolicyWrapper.
2007.07.20 19:17:45 com.sun.enterprise.web.VirtualServer configureSSOValve
INFO: WEB0114: SSO is disabled in virtual server [server]
2007.07.20 19:17:45 com.sun.enterprise.web.VirtualServer configureSSOValve
INFO: WEB0114: SSO is disabled in virtual server [__asadmin]
2007.07.20 19:17:46 com.sun.enterprise.admin.server.core.AdminService
initializeAMXMBeans
INFO: ADM1079: Initialization of AMX MBeans started
2007.07.20 19:17:46
com.sun.enterprise.admin.jmx.remote.server.rmi.JmxConnectorServerDriver
logJconsoleStartup
INFO: ADM1504: Here is the JMXServiceURL for the Standard JMXConnectorServer:
[service:jmx:rmi:///jndi/rmi://q1:8686/jmxrmi]. This is where the remote
administrative clients should connect using the standard JMX connectors
2007.07.20 19:17:46
com.sun.enterprise.admin.jmx.remote.server.rmi.JmxConnectorServerDriver
logJconsoleStartup
INFO: ADM1506: Status of Standard JMX Connector: Active = [true]
2007.07.20 19:17:47 com.sun.jbi.framework.JBIFramework startup
INFO: JBIFW0010: JBI framework ready to accept requests.
2007.07.20 19:17:48 com.sun.ejb.base.sfsb.util.EJBServerConfigLookup
needToAddSFSBVersionInterceptors
INFO: EJBSCLookup:: sc.getEjbContainerAvailabilityEnabledFromConfig() ==> false
2007.07.20 19:17:49 com.sun.jts.CosTransactions.DefaultTransactionService
identify_ORB
INFO: JTS5014: Recoverable JTS instance, serverId = [3700]
2007.07.20 19:17:49 com.sun.enterprise.server.ondemand.SystemAppLoader
loadSystemApps
INFO: About to load the system app: MEjbApp
2007.07.20 19:17:49 com.sun.enterprise.iiop.POARemoteReferenceFactory
createReferenceFactory
INFO: POARemoteRefFactory checking if SFSBVersionPolicy need to be added
2007.07.20 19:17:49 com.sun.ejb.base.sfsb.util.EJBServerConfigLookup
needToAddSFSBVersionInterceptors
INFO: EJBSCLookup:: sc.getEjbContainerAvailabilityEnabledFromConfig() ==> false
2007.07.20 19:17:49 com.sun.enterprise.iiop.POARemoteReferenceFactory
createReferenceFactory
INFO: POARemoteRefFactory addSFSBVersionPolicy? false
2007.07.20 19:17:49 com.sun.enterprise.iiop.POARemoteReferenceFactory
createReferenceFactory
INFO: POARemoteRefFactory checking if SFSBVersionPolicy need to be added
2007.07.20 19:17:49 com.sun.ejb.base.sfsb.util.EJBServerConfigLookup
needToAddSFSBVersionInterceptors
INFO: EJBSCLookup:: sc.getEjbContainerAvailabilityEnabledFromConfig() ==> false
2007.07.20 19:17:49 com.sun.enterprise.iiop.POARemoteReferenceFactory
createReferenceFactory
INFO: POARemoteRefFactory addSFSBVersionPolicy? false
2007.07.20 19:17:49 com.sun.enterprise.server.AbstractLoader loadEjbs
INFO: LDR5010: All ejb(s) of [MEjbApp] loaded successfully!
2007.07.20 19:17:49 com.sun.enterprise.server.ondemand.SystemAppLoader
loadSystemApps
INFO: About to load the system app: __ejb_container_timer_app
2007.07.20 19:17:50 com.sun.ejb.containers.TimerBeanContainer
doAfterApplicationDeploy
INFO: EJB5109:EJB Timer Service started successfully for datasource
[jdbc/__TimerPool]
2007.07.20 19:17:50 com.sun.enterprise.server.AbstractLoader loadEjbs
INFO: LDR5010: All ejb(s) of [__ejb_container_timer_app] loaded successfully!
2007.07.20 19:17:50 com.sun.enterprise.server.AbstractLoader loadPersistenceUnits
WARNING:
C:\appservers\glassfish\domains\domain1\autodeploy\ctg-main.ear\ctg-main-war_war\WEB-INF\classes
does not exist!
java.lang.RuntimeException:
C:\appservers\glassfish\domains\domain1\autodeploy\ctg-main.ear\ctg-main-war_war\WEB-INF\classes
does not exist!
at
com.sun.enterprise.server.PersistenceUnitInfoImpl.getAbsolutePuRootFile(PersistenceUnitInfoImpl.java:398)
at
com.sun.enterprise.server.PersistenceUnitInfoImpl._getJarFiles(PersistenceUnitInfoImpl.java:344)
at
com.sun.enterprise.server.PersistenceUnitInfoImpl.<init>(PersistenceUnitInfoImpl.java:112)
at
com.sun.enterprise.server.PersistenceUnitLoaderImpl.load(PersistenceUnitLoaderImpl.java:121)
at
com.sun.enterprise.server.PersistenceUnitLoaderImpl.load(PersistenceUnitLoaderImpl.java:84)
at
com.sun.enterprise.server.AbstractLoader.loadPersistenceUnits(AbstractLoader.java:898)
at com.sun.enterprise.server.ApplicationLoader.doLoad(ApplicationLoader.java:184)
at
com.sun.enterprise.server.TomcatApplicationLoader.doLoad(TomcatApplicationLoader.java:126)
at com.sun.enterprise.server.AbstractLoader.load(AbstractLoader.java:244)
at com.sun.enterprise.server.AbstractManager.load(AbstractManager.java:225)
at
com.sun.enterprise.server.ApplicationLifecycle.onStartup(ApplicationLifecycle.java:217)
at com.sun.enterprise.server.ApplicationServer.onStartup(ApplicationServer.java:442)
at
com.sun.enterprise.server.ondemand.OnDemandServer.onStartup(OnDemandServer.java:120)
at com.sun.enterprise.server.PEMain.run(PEMain.java:411)
at com.sun.enterprise.server.PEMain.main(PEMain.java:338)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.server.PELaunch.main(PELaunch.java:294)
2007.07.20 19:17:50 com.sun.enterprise.server.AbstractManager load
WARNING: CORE5021: Application NOT loaded: [ctg-main]
2007.07.20 19:17:50 com.sun.enterprise.web.PEWebContainer startInstance
INFO: WEB0302: Starting Sun-Java-System/Application-Server.
2007.07.20 19:17:50 com.sun.enterprise.web.connector.grizzly.GrizzlyHttpProtocol
start
INFO: WEB0712: Starting Sun-Java-System/Application-Server HTTP/1.1 on 8080
2007.07.20 19:17:50 com.sun.enterprise.web.connector.grizzly.GrizzlyHttpProtocol
start
INFO: WEB0712: Starting Sun-Java-System/Application-Server HTTP/1.1 on 8181
2007.07.20 19:17:50 com.sun.enterprise.web.connector.grizzly.GrizzlyHttpProtocol
start
INFO: WEB0712: Starting Sun-Java-System/Application-Server HTTP/1.1 on 4848
2007.07.20 19:17:51
com.sun.enterprise.management.selfmanagement.SelfManagementService onReady
INFO: SMGT0007: Self Management Rules service is enabled
2007.07.20 19:17:51 com.sun.enterprise.server.PEMain main
INFO: Application server startup complete.
2007.07.20 19:17:51 com.sun.enterprise.deployment.autodeploy.AutoDeployer deploy
INFO: [AutoDeploy] Selecting file
C:\appservers\glassfish\domains\domain1\autodeploy\ctg-main.ear for autodeployment.
2007.07.20 19:17:51 com.sun.enterprise.deployment.autodeploy.AutoDeployer
undeployJavaEEArchive
INFO: Autoundeploying application :ctg-main
2007.07.20 19:17:51
com.sun.enterprise.deployment.phasing.PEDeploymentService$AuditInfo <init>
INFO: Undeployment by user Unknown of module ctg-main (type=Application) starting
2007.07.20 19:17:51 com.sun.enterprise.web.WebContainer unloadWebModule
SEVERE: [WebContainer] Undeployment failed for context /ctg-main.war
2007.07.20 19:17:51 com.sun.enterprise.server.ApplicationManager
applicationUndeployed
INFO: CORE5022: All ejb(s) of [ctg-main] were unloaded successfully!
2007.07.20 19:17:51
com.sun.enterprise.deployment.phasing.PEDeploymentService$AuditInfo reportEnd
INFO: Undeployment by user Unknown of module ctg-main (type=Application)
completed successfully, elapsed time 296 ms
2007.07.20 19:17:51 com.sun.enterprise.deployment.autodeploy.AutoDeployer
invokeUndeploymentService
INFO: [AutoDeploy] Successfully autoundeployed :
C:\appservers\glassfish\domains\domain1\autodeploy\ctg-main.ear.
2007.07.20 19:17:51
com.sun.enterprise.deployment.phasing.PEDeploymentService$AuditInfo <init>
INFO: Deployment by user Unknown of module ctg-main (type=Application) starting
2007.07.20 19:17:52 com.sun.enterprise.deployment.phasing.J2EECPhase runPhase
SEVERE: Exception occured in J2EEC Phasejava.lang.IllegalArgumentException:
Invalid ejb jar [jboss-seam.jar]: it contains zero ejb.
Note:
1. A valid ejb jar requires at least one session, entity (1.x/2.x style), or
message driven bean.
2. EJB3+ entity beans (@Entity) are POJOs and please package them as library jar.
3. If the jar file contains valid EJBs which are annotated with EJB component
level annotations (@Stateless, @Stateful, @MessageDriven), please check
server.log to see whether the annotations were processed properly.
com.sun.enterprise.deployment.backend.IASDeploymentException: Error loading
deployment descriptors for module [ctg-main] – Invalid ejb jar
[jboss-seam.jar]: it contains zero ejb.
Note:
1. A valid ejb jar requires at least one session, entity (1.x/2.x style), or
message driven bean.
2. EJB3+ entity beans (@Entity) are POJOs and please package them as library jar.
3. If the jar file contains valid EJBs which are annotated with EJB component
level annotations (@Stateless, @Stateful, @MessageDriven), please check
server.log to see whether the annotations were processed properly.
at com.sun.enterprise.deployment.backend.Deployer.loadDescriptors(Deployer.java:390)
at
com.sun.enterprise.deployment.backend.AppDeployerBase.loadDescriptors(AppDeployerBase.java:358)
at com.sun.enterprise.deployment.backend.AppDeployer.deploy(AppDeployer.java:226)
at
com.sun.enterprise.deployment.backend.AppDeployer.doRequestFinish(AppDeployer.java:148)
at com.sun.enterprise.deployment.phasing.J2EECPhase.runPhase(J2EECPhase.java:191)
at
com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:276)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:294)
at
com.sun.enterprise.admin.mbeans.ApplicationsConfigMBean.deploy(ApplicationsConfigMBean.java:555)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:375)
at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:358)
at com.sun.enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java:464)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java:90)
at $Proxy1.invoke(Unknown Source)
at
com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.invoke(SunoneInterceptor.java:304)
at
com.sun.enterprise.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:174)
at
com.sun.enterprise.deployment.autodeploy.AutoDeployer.invokeDeploymentService(AutoDeployer.java:564)
at
com.sun.enterprise.deployment.autodeploy.AutoDeployer.deployJavaEEArchive(AutoDeployer.java:545)
at
com.sun.enterprise.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:492)
at
com.sun.enterprise.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:267)
at
com.sun.enterprise.deployment.autodeploy.AutoDeployControllerImpl$AutoDeployTask.run(AutoDeployControllerImpl.java:374)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Caused by: java.lang.IllegalArgumentException: Invalid ejb jar [jboss-seam.jar]:
it contains zero ejb.
Note:
1. A valid ejb jar requires at least one session, entity (1.x/2.x style), or
message driven bean.
2. EJB3+ entity beans (@Entity) are POJOs and please package them as library jar.
3. If the jar file contains valid EJBs which are annotated with EJB component
level annotations (@Stateless, @Stateful, @MessageDriven), please check
server.log to see whether the annotations were processed properly.
at
com.sun.enterprise.deployment.util.EjbBundleValidator.accept(EjbBundleValidator.java:95)
at
com.sun.enterprise.deployment.util.ApplicationValidator.accept(ApplicationValidator.java:82)
at
com.sun.enterprise.deployment.EjbBundleDescriptor.visit(EjbBundleDescriptor.java:729)
at com.sun.enterprise.deployment.Application.visit(Application.java:1754)
at
com.sun.enterprise.deployment.archivist.ApplicationArchivist.validate(ApplicationArchivist.java:470)
at
com.sun.enterprise.deployment.archivist.ApplicationArchivist.openArchive(ApplicationArchivist.java:790)
at
com.sun.enterprise.deployment.archivist.ApplicationArchivist.openArchive(ApplicationArchivist.java:744)
at com.sun.enterprise.deployment.backend.Deployer.loadDescriptors(Deployer.java:349)
... 32 more
2007.07.20 19:17:52
com.sun.enterprise.deployment.phasing.PEDeploymentService$AuditInfo reportEnd
INFO: Deployment by user Unknown of module ctg-main (type=Application) failed,
elapsed time 484 ms
2007.07.20 19:17:52 com.sun.enterprise.deployment.autodeploy.AutoDeployer
parseResult
SEVERE: "DPL8011: autodeployment failure while deploying the application : Error
loading deployment descriptors for module [ctg-main] – Invalid ejb jar
[jboss-seam.jar]: it contains zero ejb.
Note:
1. A valid ejb jar requires at least one session, entity (1.x/2.x style), or
message driven bean.
2. EJB3+ entity beans (@Entity) are POJOs and please package them as library jar.
3. If the jar file contains valid EJBs which are annotated with EJB component
level annotations (@Stateless, @Stateful, @MessageDriven), please check
server.log to see whether the annotations were processed properly.
"
2007.07.20 19:17:52 com.sun.enterprise.deployment.autodeploy.AutoDeployer
markFileAfterDeployment
INFO: [AutoDeploy] Autodeploy failed :
C:\appservers\glassfish\domains\domain1\autodeploy\ctg-main.ear.

When I deploy ear as an archive everything works fine.



 Comments   
Comment by Hong Zhang [ 20/Jul/07 ]

Downgrade this to P2 as there is always the workaround of deploying with archive
unexploded.
Can you attach your application (or a simple test case) with steps to reproduce
the problem? We have unit test cases covering similar scenarios, so there might
be something special with your application that we need to look into.

Comment by Hong Zhang [ 20/Jul/07 ]

->P2 as stated in previous comments

Comment by Hong Zhang [ 20/Jul/07 ]

Looking at the stack trace again, it seems to treat the jboss-seam.jar as a ejb
jar. Was this jar specified as ejb jar explicitly in the application.xml? Does
this jar contain actual ejb: a valid ejb-jar.xml or ejb component level
annotations (@Stateless, @Stateful, @MessageDriven?

Again attaching the application would help us look into the problem further.
Thanks.

Comment by Hong Zhang [ 20/Jul/07 ]

Actually as the reported problem is only for the specific format of the
directory deployment and we are post-beta, move to the bug to P3 (fix for FCS).

If the application.xml declares the jboss-seam.jar as ejb jar while it's not,
please fix the application.xml and try again.

Comment by gfbugbridge [ 20/Jul/07 ]

<BT6583661>

Comment by ivicac [ 23/Jul/07 ]

Actually jboss-seam.jar is ejb beacuse it has same session beans. When I deploy
my application as an archive everything works fine. When I remove jboss-seam
definition from the application.xml then application works in exploded mode, too
but then I have to change configuration for jboss-seam and this is not good.
Obviously the problem is that for some reason, you cannot mix exploded and
archived submodules in exploded deployment of an ear. This is my conclusion.

Comment by Hong Zhang [ 23/Jul/07 ]

If jboss-seam.jar is indeed an ejb jar, is it declared in application.xml as an
ejb module? If so, is it declared in a similar way as ctg-main-ejb.jar?

If the exploded directories are created by MyEclipse, I am wondering why the
ctg-main-ejb.jar is exploded but not jboss-seam.jar.

You are right that we don't currently support deployment of mixed archive and
exploded submodules in an exploded directory. That has not been a common use case.

If jboss-seam.jar and ctg-main-ejb.jar are declared in a similar way in
application.xml and MyEclipse exploded one but not the other, it's something
needs to be fixed from MyEclipse side.

Could you try to manually explode jboss-seam.jar in a similar way as
ctg-main-ejb.jar and see if it works?

Comment by ivicac [ 23/Jul/07 ]

jboss-seam.jar is library from JBoss. It is their framework. So, I have putted
it in my exploded archive because I need it. As you can see it is a case where I
am developing my ejbs but I am using ejbs from others, too. So I would say it
could be a common use case. Primarily I am using exploded deployment because my
development is faster. MyEclipse only deploys my changes, not everything. I can
try explode jboss-seam.jar and see what will happen, but this is not very common.

Comment by ivicac [ 24/Jul/07 ]

And I think that you could improve a little bit deployment. As I can see yo are
first trying to deploy module as a zip file and if an exception occur you are
switching to exploded deployment and operation goes from the begining. I think
you should first find out is submodule a zip file or directory and then use a
properly deployment.

Comment by Sanjeeb Sahoo [ 24/Jul/07 ]

added myself to cc list.

Comment by Hong Zhang [ 24/Jul/07 ]

Thanks for the explanation, now I understand your use case better. As I said,
this has not been a common use case before where the archive and exploded
directory were mixed, but we will take a look at this in the next release as a
potential improvement.

Comment by ivicac [ 25/Jul/07 ]

And what about recognizing what type submodule is: zip file or directory. I
think it would accelerate deployment.

Comment by Hong Zhang [ 25/Jul/07 ]

Yes, this is something we need to do if we were to support the mixed exploded
directory/archive directory deployment. Right now, there is no complication: we
explode the archive if it's in archive format, and we don't do the exploding if
it's directory.

Comment by ivicac [ 26/Jul/07 ]

You didn't understand me. I was talking about exploded deployment. When you have
.war or .jar as a prefix(ebven if it is already directory) you are first trying
to unzip it even it is already a directory. After excpetion you conclude it is a
directory and then go from the start with deployment of the directory. you
should first check if it is already a directory then bypass unzip operation and
go straight to deployment.

Comment by Hong Zhang [ 08/Nov/07 ]

look in v3.

Comment by vince kraemer [ 15/Jan/08 ]

I think the user is telling us that the deployment code is using exceptions for
flow control in the comments dated: Tue Jul 24 12:11:35 +0000 2007; Wed Jul 25
09:29:45 +0000 2007; Thu Jul 26 08:48:02 +0000 2007

Did you want that logged as another issue or has it been addressed already?

Comment by vince kraemer [ 15/Jan/08 ]

get on the cc list

Comment by fabriciolemos [ 08/Jun/09 ]

Is there any workaround for this bug or any other way to have hot deployment
with GlassFish + Seam + Eclipse?

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-436] Notification of incomplete application.xml Created: 20/Mar/06  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: stvconsultants Assignee: Hong Zhang
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: 436

 Description   

Background:
-----------
With reference to
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6359192
and
https://glassfish.dev.java.net/issues/show_bug.cgi?id=71

Problem:
--------
I know that the spec for deployment says:
The deployment tool must first read the Java EE application deployment
descriptor from the application .ear file (META-INF/application.xml). If the
deployment descriptor is present, it fully specifies the modules included in the
application. If no deployment descriptor is present, the deployment tool uses
the following rules to determine the modules included in the application.
...

And that therefore one should either include a fully specified application.xml
or not include an application.xml file at all.

This is not exactly friendly deployment behaviour. Take the example of having an
enterprise application with no application.xml and I want to change the context
root of one web application. Now I have to figure out all the modules and
resource connectors, etc that the application server has been inferring for me.
This may not be the worlds biggest problem, since it should be just a case of:
adding references for all the root level rars and wars; adding the lib directory
if present; and, oh, figuring out whether the jars are application clients, ejb
modules or just plain fluff to be ignored...

Now consider that the .ear is one that I've been given to maintain, I'm no
JavaEE expert, but the users want the web context over-ridden, so I open up the
.ear to add an application.xml.

How is the non-developer to know which .jars are app clients, which .jars are
ejbs and which .jars are fluff!

Solution:
---------
Either provide some option to restore the scanning behaviour (i.e. change the spec)
OR
Provide warning on deployment that there appear to be ejb modules and app-client
modules which are not defined in application.xml

I can see that we don't want the spec to be changed such that scanning always
happens since somebody may want to (for example) disable the application client
jar without un-packaging it. But some sort of <infer-other-modules/> element
added to the application.xml schema would be good.



 Comments   
Comment by stvconsultants [ 20/Mar/06 ]

Actually, as I think about this more, it is more serious than I initially thought.

The general theme for JavaEE5 is that the .xml files should become optional. We
may not have an .xml descriptor in the ejb jars so how do I tell just by looking
at them (without being a JavaEE developer) that they contain ejbs

How do I tell that a .jar is an application client other than by opening up the
manifest.

I am beginning to think that scanning the ear for ejbs and application clients
should be the default behaviour even when an application.xml file is provided
and that the scanning should be turned off with a <exclude-unlisted-modules/>
element much like the <exclude-unlisted-classes/> element from persistence.xml

Comment by qouyang [ 20/Mar/06 ]

I think all of your concerns should be addressed by tools, and not deployment
process itself. If you want to know what's inside of an application after
deployment, you could login to admin gui and see it on display. If you are
given an ear file without any descriptors before deployment, I suppose you can
also open it up in some gui tool so you can inspect it visually. I am not aware
of any tools that does that now. But I'd recommand that you try it out with the
NetBeans. If they don't do it, file a bug. :-P

Comment by stvconsultants [ 20/Mar/06 ]

Well fair enough, maybe it's just, in my view, one piece of the spec that leaves
a bad taste in your mouth.

All the other deployment descriptors have a mechanism to say that they are the
full deployment descriptor and ensure that the application server does not go
and infer anything else. Why should application.xml be the special one that
does not have this type of behaviour?

Comment by Bill Shannon [ 20/Mar/06 ]

I guess the reason we didn't include a metadata-complete attribute in the
application.xml file is that it didn't seem that useful. There's very little
in the application.xml file that you would want to override. We assumed
developers would choose one style or the other and work within that style.

For example, to change the context root of a web application with no
application.xml, simply rename the war file.

You're right that the AVK and other tools should help by reporting any
"unaccounted for" artifacts in the ear file. And a tool to produce an
application.xml for a directory structure would also be useful.

Still, there may be use cases where it would be helpful to be able to
combine information in the application.xml with information discovered
by looking at files. This is something we can consider for the next
release.

Bill Shannon
Java EE 5 Spec Lead

Comment by Hong Zhang [ 08/Nov/07 ]

will revisit this for v3/JavaEE 6.

Comment by Hong Zhang [ 08/Nov/07 ]

assign to myself

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-811] eliminate the dot-reload file Created: 10/Jul/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: vince kraemer Assignee: Hong Zhang
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: 811

 Description   

It would be nice if the user did not have to touch the .reload file to signal
that they were "done" changing the files in an app.

The server could detect that there are changed files when a user accesses
elements of an app and would do its reload magic before completing the request.



 Comments   
Comment by Hong Zhang [ 05/Sep/06 ]

Change release to 9.1 and downgrade to P3. Have discussed with Vince in one of
the meetings and he agrees this is not too critical.

Comment by cafealpha [ 05/Sep/06 ]

What if the user has bulk of changes and want to notify app server to reflect
the all changes later?
The changes can be incremental and the user may want to apply changes when ready.

I think that the two mode should be supported.

  • automatic : as proposed in this issue
  • manual : dot reload file or some other way

my 2 cents.

Comment by Hong Zhang [ 08/Nov/07 ]

look in v3.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-629] Map local JNDI references to server references during GUI Deployment Created: 02/May/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: Anissa Lam Assignee: Hong Zhang
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: 629

 Description   

This is an enhancement related to using GUI for deployment, mentioned in the
blog http://epesh.blog-city.com/glassfish_b45_review.htm.
GUI should be able to implement this with deployment team support. Here is
suggestion:

  • Deployment team provides an API which takes in the application/module name and
    location, and return the list of JNDI references and its corresponding type.
  • Based on the list returned, GUI will show the user the corresponding server
    references that can be mapped to. User can select one from the list.
  • Upon finish, GUI will pass the mapped list back to deployment for updating.

This means gui will need 2 API, one to give it the list of local JNDI
references, and another to take in the mapped list.

I am assigning this to 'deployment' and will work with them to design the API.
Once the API is implemented, this issue can be assigned back to GUI for all the
UI changes.



 Comments   
Comment by Anissa Lam [ 02/May/06 ]

Add gui team to the interested list.

Comment by Hong Zhang [ 12/Jul/06 ]

I'd like to understand this better before I look into the code see if it's
possible (and how much work it is) to provide these two APIs.

I will use the ejb references as example. Currently we rely on the runtime
xml files to do the jndi mapping, and what we want to achieve here is to do this
mapping through gui.
Say I have an ejb with ejb name "FooBean" and it has a physical jndi name
called "ejb/FooBean". And a web component is referencing this ejb using the ref
name "foo". So in today's implementation:
1. In the sun-ejb-jar.xml we need to have something like this which maps this
ejb name to the jndi name:
<ejb>
<ejb-name>FooBean</ejb-name>
<jndi-name>ejb/FooBean</jndi-name>
</ejb>
2. And in the sun-web.xml, we need to map the ejb ref name "foo" to the same
jndi name "ejb/FooBean".
<ejb-ref>
<ejb-ref-name>foo</ejb-ref-name>
<jndi-name>ejb/FooBean</jndi-name>
<ejb-ref>

So in your proposal below, we no longer need the information in sun-web.xml.
The first deployment API will return the ejb reference, with the ref name "foo"
and type "ejb-ref". And the gui will provide the "ejb/FooBean" for the user to
select. Once user selects the "ejb/FooBean", the gui will return the mapping
"foo->ejb/FooBean" through the second deployment API. Then deployment code add
this information to the runtime.

Is this understanding correct? If so, I have some questions/comments
a. How does the gui gets all the physical jndi names (or what you called
server references), which in this case "ejb/FooBean"? Before the deployment
happens, there is no name binding happen yet. So you will also need to get this
from deployment code?
b. This mapping funtionality that gui is providing is just letting user
select from the existing jndi names, not to enter new ones, right? If that's the
case, the original archive still needs to include some of the mapping, in this
case, the information in the sun-ejb-jar.xml.

I remember deploytool has some functionality like this, but that happens at
the packaging time. Doing it at deployment time is much harder, it means round
trips between deployment code and gui code, and also change of the timing of
doing things. We will need to parse the deployment descriptors prior to actual
deployment in order to provide such information to gui. And then need to save
the information passed back from gui for deployment descriptor post processing.

Comment by Hong Zhang [ 08/Nov/07 ]

Will look into this in v3.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-4792] Honor context-root in sun-web.xml even if web module in bundled in EAR file Created: 16/Apr/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: jluehe Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 4,792

 Description   

vbkraemer wrote (see http://forums.java.net/jive/thread.jspa?messageID=269540
for complete background):

The context-root of a web app deployed inside an ear is determined by:

1. the value of the context-root element in the ear file's
sun-application.xml file
2. the value of context-root element in the ear file's application.xml
3. the default value computed by using the module's web-uri...

(in order)

Adding a forth method of determining the context-root, that requires
introspection of a second level of archived content, may have seemed
like overkill to the implementors.

Honoring the context-root specified in a web module's sun-web.xml regardless of
whether the web module is deployed on its own, or as part of an EAR, would be a
good idea. This would allow for the web module to simply be "dropped" into an
EAR (and have its context-root take effect), without having to edit any
sun-application.xml or application.xml.



 Comments   
Comment by Hong Zhang [ 16/Apr/08 ]

Jan: this is actually not an implementation issue. I am afraid honoring the
sun-web.xml context root values will violate the spec. For the ear case:

1. When there is application.xml present, as the context roots for web modules
are required elements for application.xml according to the schema, the context
roots will always be defined there. And they will over-shadow any values in
sun-web.xml.

2. When there is no application.xml present, according to the EE spec, the
context roots will be computed using the sub modules web uri, and there is no
chance for the context root from sun-web.xml to be used either.

Let me know what you think.

Comment by vince kraemer [ 23/Apr/08 ]

The spec doesn't take the vendor specific extensions into account.

The user can override the context-root specified in the application.xml with
data in the sun-application.xml. That feature appears to be spec compliant.

I think the spec creates an enclosure in which we can and do define extended
behavior. We need to be able to handle apps that are spec pure purely.

But an ear that contains a web-app that includes a sun-web.xml is not spec pure,
so our extensions should behave consistently.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-4722] Relaxed Schema Constraints Created: 10/Apr/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 9.1peur1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: mkarg Assignee: Hong Zhang
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: 4,722

 Description   

The sun-specific deployment descriptors seem to be a bit too constrained. There
are several places where constrains are used that are not needed. Example:

  • sun-ejb-jar.xml enforces the use of <ejb> while I just created that file to
    add a security roles mapping. This is silly because when I add the same mapping
    to sub-application.xml and just drop the sun-ejb-jar.xml, it just works. So the
    system can live without <ejb>, it is just a useless constraint of the schema.
  • If I noticed correctly, there is a sequence enforced on several tags. That
    means, you must not write tag B before tag A, but you may write tag A before tag
    B only. This makes no sense. Nobody cares about the sequence of tags but only
    about the content.

What I want to suggest is to relax these constrains unless there are really
needed to express the sense of the information found in that files.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-1298] Persistence Units info to be displayed Created: 12/Oct/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: marina vatkina Assignee: Hong Zhang
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 1,298

 Description   

Persistence Units (PUs) info is as important to be seen as any other Java EE
module as it's an important part of an application. Please make sure that PU
info is extracted from all possible elements (EJB, WEB, or a separate library jar).



 Comments   
Comment by Anissa Lam [ 03/Nov/06 ]

GUI invokes "getModuleComponents" of the
"com.sun.appserv:type=applications,category=config" to get the list of sub
modules. The component name and the type is extracted from the list it returns.

If backend returns the Persistence Units as other modules, it will be displayed
in GUI.
Transferring this to 'admin'. If this should be for 'deployment', please reassign.

Comment by marina vatkina [ 03/Nov/06 ]

Persistence Units are not Java EE modules, they are separate "things".

Comment by km [ 01/Feb/07 ]

Hi Marina:

How are these separate "things" deployed to a Java EE server?

Hi Hong:

Since these separate "things" are not registered in the configuration of the
domain, I think it should be deployment who provides an API to extract them
from their respective locations. Frankly, I don't know if we can support this
at this time.

I am requesting you to take a look.
If you disagree, we can discuss.

Comment by marina vatkina [ 02/Feb/07 ]

Those things are called Persistence Units (PUs) and can be packaged as part of
any other module or as a library to be shared by several module. There can be
more than one PU in any module and the whole ear file. They are deployed as part
of the enclosing module or ear file.

Comment by Hong Zhang [ 08/Nov/07 ]

revisit in v3.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-1292] Persistence archive is not listed as a library in the application vieweing page Created: 11/Oct/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: marina vatkina Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Attachments: File ex1-ee.ear    
Issuezilla Id: 1,292

 Description   

I'll attach my example that has an entity.jar separate of any other module. When
I deploy this app, the jar is not listed anywhere as if it doesn't exist.



 Comments   
Comment by marina vatkina [ 11/Oct/06 ]

Created an attachment (id=500)
Application with a separate persistence archive

Comment by Sanjeeb Sahoo [ 11/Oct/06 ]

I guess that's the case with any non-component top-level jar in the ear, isn't
that? e.g.

foo.ear
lib1.jar (not a Java EE archive, nor does it have persistence.xml)
ejb.jar
web.war

If yes, should the subject be changed?

Thanks,
Sahoo

Comment by Anissa Lam [ 16/Oct/06 ]

Additional info to deploy the attached ear:
You need to run "asadmin start-database" first before deploy the ear.

Here is the evaluation:
GUI calls the method "getModuleComponents" of the
"com.sun.appserv:type=applications,category=config" mbean to get the list of sub
components. That method doesn't return entities.jar as a sub component. Thats
why it is not shown up in GUI.
Transferring to "deployment". If the deployment team can fix it so that the
entities.jar is also returned, it will be displayed correctly in GUI. Nothing
is needed to change in GUI.

Comment by Anissa Lam [ 16/Oct/06 ]

assign to deployment

Comment by Hong Zhang [ 16/Oct/06 ]

Looking at the current implementation of ApplicationsConfigMBean

public String[] getModuleComponents(String standAloneModuleName)
throws ServerInstanceException {

seems it only intends to return (jsr77) object names for javaee modules (ejb,
web, appclient, resource adapter and application).

For entities.jar or any top level library jar, we just don't have a jsr77 mbean
for it and therefore don't have an object name for it. I am not sure what we
should do here.

Transferring to Sreeni for his take on this since he is in charge of the
ApplicationsConfigMBean and jsr77 stuff.

Comment by gfbugbridge [ 02/Jan/07 ]

<BT6508997>

Comment by Hong Zhang [ 15/Feb/07 ]

I have just talked with Sreeni on this. As of now we don't support displaying
library jars (including persistence units) and in fact today we don't display
any sub-components of an application either.

Change to enhancement for now and will revisit in the next release for the need
of providing such support.

Comment by Hong Zhang [ 08/Nov/07 ]

look in v3.

Comment by Hong Zhang [ 21/Jan/11 ]

marina: I am scrubbing the old RFEs and came across this one, do you still think displaying this in the console would be useful? As in v2, 3.* console does not display any subcomponents of an application.

Comment by marina vatkina [ 21/Jan/11 ]

Of course it would be useful - they can see an EJB or a Web module in an archive. it'd be nice to see if there is JPA included.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-4138] Map jndi entries through admin console Created: 08/Feb/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: not determined

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

Operating System: All
Platform: Linux


Issue Links:
Dependency
depends on GLASSFISH-4139 Map jndi entries through admin console Open
Issuezilla Id: 4,138
Status Whiteboard:

v3-prd-item


 Description   

Map jndi entries through admin console
http://wiki.glassfish.java.net/Wiki.jsp?page=V3DeploymentImprovements
Deploy-008

See this RFE:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=629

The user wants the ability of mapping jndi entries before deployment.



 Comments   
Comment by Hong Zhang [ 08/Feb/08 ]

Adding v3-prd-item to status whiteboard.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-2189] Write log msg when resolving DTD or schemas over the net Created: 23/Jan/07  Updated: 23/May/13

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: Tim Quinn Assignee: Hong Zhang
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: 2,189

 Description   

GlassFish provides local copies of the DTDs and schemas it expects to need. If
the system ID of a DTD or schema is misspelled in an application's descriptor,
then GlassFish will not find it locally and will try to resolve it over the
network. If the system is disconnected this yields errors.

The enhancement would be to detect when such off-host resolutions were occurring
and log a warning message about it. This would give the administrator a chance
to understand the problem and get the application developer to fix it.



 Comments   
Comment by Hong Zhang [ 23/Jan/07 ]

Move up to P3. Will fix for FCS.

Comment by km [ 23/Jan/07 ]

Shouldn't verifier do this job, already?

Comment by Hong Zhang [ 14/Mar/07 ]

Tim will take a look.

Comment by Tim Quinn [ 14/Mar/07 ]

Hong reassigned this to me since I've worked on the relevant classes before for
other reasons. Marking as started again.

Comment by Hong Zhang [ 08/Nov/07 ]

look in v3

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.

Comment by Tim Quinn [ 23/May/13 ]

I'm reassigning this to Hong (sorry, Hong!). We might have already addressed this somewhere along the way.





[GLASSFISH-2545] relax the 'doctype requirement' Created: 04/Mar/07  Updated: 04/Jan/13

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

Type: Improvement Priority: Major
Reporter: vince kraemer Assignee: Hong Zhang
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: 2,545

 Description   

Currently, there are a number of xml files that are part of the app server's
interface. Thee include DD files and the sun-resources.xml file. Many of these
files have an implementation requirement that they be identified by an embedded
doctype element.

While it is wise practice to include the doctype, the server should not require
that the file contain a doctype.

The server should probably just validate the file against the latest expected
version of the dtd associated with the file. If the file does contain an
embedded doctype, it would still be used for validation.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

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

Comment by Tom Mueller [ 04/Jan/13 ]

Assigning to the deployment component for evaluation.





[GLASSFISH-1048] improve error message for context root in use situations Created: 30/Aug/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 9.0peur1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: vince kraemer Assignee: Hong Zhang
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: File EnterpriseApplication6-war.war     File EnterpriseApplication6.ear    
Issuezilla Id: 1,048

 Description   

Build 5

this message could use more info...

CLI171 Command deploy failed : Trying to create reference for application in
target server failed; The context root [EnterpriseApplication6-war] in
application [EnterpriseApplication6-war] is already in use by another
application on this instance [server].

Steps to get this message:

1. deploy the attached ear file using 'asadmin deploy'
2. attempt to deploy the attached war file with 'asadmin deploy'.

Possible improvements:

1. Name of the application that currently is using the context root. The name
of should be the one that someone would use as an argument to 'asadmin undeploy'

2. A hint that doing asadmin undeploy then deploy would help, though that could
go into the error Messages reference/guide.

3. Put something into the server log when this happens. Currently, there is
nothing in the log, so a user cannot go to the Admin GUI logviewer and then look
up a detailed message about the error.



 Comments   
Comment by vince kraemer [ 30/Aug/06 ]

Created an attachment (id=407)
the ear

Comment by vince kraemer [ 30/Aug/06 ]

Created an attachment (id=408)
the war

Comment by Hong Zhang [ 08/Nov/07 ]

look in v3.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-17412] Annotations in plain java classes shouldn't be processed Created: 12/Oct/11  Updated: 28/Feb/13

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

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

Attachments: GZip Archive ejb-reference-testcase.tar.gz    
Tags: 3_1_x-exclude

 Description   

When deploying an EJB-module, Glassfish seems to scan for injection annotations in all classes, not just the ones marked as EJB.

This can lead to problems when plain java classes (no @Stateless, @Stateful, etc) contain annotations that would be invalid for container-managed classes, because Glassfish then refuses to deploy the application. It shouldn't do this, and instead ignore these annotations on unmanaged classes.

I've attached an example project that demonstrates this problem. It contains a non-EJB class AbstractTestA that contains an unresolvable @EJB annotation on a field, which causes deployment to fail:

SEVERE: Cannot resolve reference Local ejb-ref name=test.AbstractTestA/test,Local 3.x interface =test.TestA,ejb-link=null,lookup=,mappedName=,jndi-name=,refType=Session
SEVERE: Exception while deploying the app [ejb-reference-testcase]
SEVERE: Cannot resolve reference Local ejb-ref name=test.AbstractTestA/test,Local 3.x interface =test.TestA,ejb-link=null,lookup=,mappedName=,jndi-name=,refType=Session
java.lang.RuntimeException: Cannot resolve reference Local ejb-ref name=test.AbstractTestA/test,Local 3.x interface =test.TestA,ejb-link=null,lookup=,mappedName=,jndi-name=,refType=Session
at com.sun.enterprise.deployment.util.EjbBundleValidator.accept(EjbBundleValidator.java:608)
at com.sun.enterprise.deployment.EjbBundleDescriptor.visit(EjbBundleDescriptor.java:760)
at com.sun.enterprise.deployment.Application.visit(Application.java:1765)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:195)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:181)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:828)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:770)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:382)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1064)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1244)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1232)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:459)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:209)
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:238)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:680)

SEVERE: Exception while deploying the app [ejb-reference-testcase] : Cannot resolve reference Local ejb-ref name=test.AbstractTestA/test,Local 3.x interface =test.TestA,ejb-link=null,lookup=,mappedName=,jndi-name=,refType=Session

My actual use case is only slightly more complex: I'm using a shared library jar in several EJB-modules, that contains both EJB interfaces and abstract implementations. The abstract implementations include an @EJB reference to their own interface, to be able to start certain operations in a new transaction.

Each EJB-module implements some (often not all) of the interfaces, using the provided abstract implementation. Because only the actual implementations are marked with @Stateless (etc) and the abstract ones are not, injection annotation processing should only happen for the beans that are actually implemented. This worked properly in Glassfish 2.1.



 Comments   
Comment by Cheng Fang [ 12/Oct/11 ]

@EJB and other annotations on the super classes of EJB bean class are part of the dependency of this EJB, and need to be processed. This is required by Java EE and EJB spec.

If some ejb-ref only apply to certain concrete EJB bean class, then the concrete bean class is better place than the common super class. You may want to use lookup, or have a non-annotated setter method in super class, to be overridden with a setter method annotated with @EJB in subclass if needed.

Comment by omolenkamp [ 12/Oct/11 ]

"@EJB and other annotations on the super classes of EJB bean class are part of the dependency of this EJB, and need to be processed. "

Yes, but what's happening is that these annotations are also processed on classes that aren't EJB's themselves, and don't have any subclasses that are EJB's either. There's no reason to do this, and it will break the setup I described.

Comment by Sanjeeb Sahoo [ 13/Oct/11 ]

Seems like a bug to me. @EJB should only be processed for classes that are "injection capable."

Comment by Cheng Fang [ 14/Oct/11 ]

Assign to deployment. Hong, can you take a look?

Comment by Hong Zhang [ 14/Oct/11 ]

Yes today we scan all the classes for annotations as it's hard to determine which we should scan and should not ahead of the time. But it might be possible to filter the processed results to remove the unwanted processing.
The reason it used to work in 2.* is we did not scan libraries for annotation processing which was a bug and we fixed that in 3.*.

Comment by Hong Zhang [ 18/Oct/11 ]

Will look at this for trunk (the changes for this will be too involving for 3.1.*).

Comment by Hong Zhang [ 28/Feb/13 ]

Scrub bugs for 4.0 HCF. Did not get a chance to look into this one, as the changes for this one will be very involving, re-target for later release.





[GLASSFISH-16974] Deploying a <distributable/> application without availability-enabled (and vice-versa) should trigger a user-friendly warning Created: 06/Jul/11  Updated: 14/Dec/11

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

Type: Improvement Priority: Major
Reporter: Alexis MP Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_1-scrubbed, 3_1_2-exclude

 Description   

Using clustering in GlassFish requires (per specification) using a distributable application (defined in web.xml) and setting the availability flag at deploy-time.
While this is all fairly well documented, the runtime should point out inconsistencies such as:
1/ a missing <distributable/> tag when deploying with availability enabled
or the opposite :
2/ deploying an application carrying a <distributable/> tag but deployment done without enabling availability

IMO, this should be implemented at the deployment level and surfaced in admin tools (asadmin, web console, REST api).
Arguably 1/ could actually have the deployment fail (a bit extreme) while 2/ should only be a warning.

This would be useful for both new users, evaluators and more seasoned users that forget the flag or checkbox at deploy time.



 Comments   
Comment by Hong Zhang [ 06/Jul/11 ]

Yes, this could be a user-friendly improvement.

Comment by Hong Zhang [ 14/Dec/11 ]

Did not have time to get to this, will need to defer it to next release.





[GLASSFISH-16932] Adding and removing virtual server for an application does not take effect Created: 01/Jul/11  Updated: 12/Dec/12

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

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

FF5, WinXP, ogs-3.1.1-b10-06_28_2011.zip


Attachments: File domain.xml.after.vs.remove     File domain.xml.vs.added     File hello.war    
Tags: 3_1_1-scrubbed, 3_1_x-exclude

 Description   

Adding or removing virtual servers to an already deployed application does not seem to take effect: after adding a virtual server application cannot be accessed. Once it's made accessible, after removing a virtual server from the application one can still access it on the virtual server listener port. Steps to reproduce follow.

1. Create a cluster with one instance, e.g. cl with clin.
2. Start cluster.
3. Deploy an application, e.g. hello.war, to DAS and cluster.
4. Go to cl-config, Virtual Servers and create a new virtual server: enter virtual server name only, e.g. clvs.
5. In cl-config create a Network Listener: type name, e.g. http-listener-clvs, select Create Protocol (it should be automatically populated), select clvs for Default Virtual Server, type port, e.g. 85 and address as 0.0.0.0 and select http-thread-pool.
6. At this point you should be able to access the new virtual server on http://<machine name>:85.
7. Go to Applications and select previously deployed hello.war. Click on Target tab, Manage Virtual Servers link for the cluster target, cl.
8. Add virtual server, clvs, to Selected Targets, click Save.
9. At this point the expectation is that the hello.war application should be available under http://<machine name>:85/hello but the url brings 404 error. The domain.xml file contains the virtual server in the application-ref:

<clusters>
<cluster gms-multicast-port="4932" gms-bind-interface-address="$

{GMS-BIND-IN TERFACE-ADDRESS-cl}" name="cl" gms-multicast-address="228.9.107.160" config-ref=
"cl-config">
<application-ref ref="hello" virtual-servers="server,clvs"></application-r
ef>

10. One way to force the application to work on the virtual server is to make it a Default Module: go to cl-config, clvs virtual server and select hello under Default Web Module. Save.
11. Now we can access the app at http://<machine name>:85/hello.
12. Go to the application targets, Manage Virtual Servers again and remove clvs from the Selected Targets, save.
13. The reference is removed from:

<clusters>
<cluster gms-multicast-port="4932" gms-bind-interface-address="${GMS-BIND-INTERFACE-ADDRESS-cl}

" name="cl" gms-multicast-address="228.9.107.160" config-ref=
"cl-config">
<application-ref ref="hello" virtual-servers="server"></application-ref>

but not from the clustered instance:

<servers>
<server name="clin" node-ref="localhost-domain1" config-ref="cl-config">
<application-ref ref="hello" virtual-servers="server,clvs"></application-ref>

I'm attaching domain.xml at this point. One can still access the application via http://<machine name>:85/hello.



 Comments   
Comment by lidiam [ 01/Jul/11 ]

Attaching domain.xml after the virtual server is added as target to the application: cluster app reference is updated but clustered instance is not.

Comment by Anissa Lam [ 01/Jul/11 ]

I believe console is doing the right thing and domain.xml reflects what user done correctly.
Transferring to web container for evaluation.
Please reassign if needed.

I changed the affected version to b09 since b10 is not out yet.

Comment by Anissa Lam [ 01/Jul/11 ]

I can reproduce this following the same steps.
To summarize the bug, adding a VS to a cluster doesn't propagate the VS info to the cluster's instance.

I see that when adding the VS to the cluster, the application-ref of the cluster is updated correctly to include the newly added VS.

<cluster gms-multicast-port="26825" gms-bind-interface-address="${GMS-BIND-INTERFACE-ADDRESS-ABC-TEST}" name="ABC-TEST" gms-multicast-address="228.9.5.2" config-ref="ABC-TEST-config">
      <application-ref ref="hello" virtual-servers="server,TESTvs"></application-ref>
      <server-ref ref="TEST-1"></server-ref>
      <property name="GMS_LISTENER_PORT" value="${GMS_LISTENER_PORT-ABC-TEST}"></property>
    </cluster>

however, the instance itself doesn't have the VS added.

<server name="TEST-1" node-ref="localhost-domain1" config-ref="ABC-TEST-config">
      <application-ref ref="hello" virtual-servers="server"></application-ref>
    </server>

I believe whoever is listening to the addition of VS to application-ref of a cluster, should propagate this to ALL its instance. The target is the cluster for user to issue commands, not each of the instance. CLI user will have the same problem when using dotted name to set the VS of the cluster's application-ref.

I am not sure who should be responsible to this part of the code, whether it is admin or deployment.

Comment by Shing Wai Chan [ 01/Jul/11 ]

When I run
asadmin set servers.server.clin.application-ref.hello.virtual-servers=server,clvs

it works. This confirms that the observation above.

Comment by Hong Zhang [ 05/Jul/11 ]

Will check with Tom to see if there is anything at admin level which handles this kind of cluster/instance config update.
Anissa: I vaguely remembered in v2 we had similar issue, and console sends explict config update request for each cluster instance as well as the overall cluster? Maybe we need to do something similar here?

Comment by Anissa Lam [ 06/Jul/11 ]

Summary of the issue: If an application is deployed to a cluster, then adding newly created Virtual Servers to this target will not be reflected
in the <application-ref> of the cluster's instance.

Workaround: Remove the cluster target, and then add this cluster target back.

Maybe there should be a command similar to create-application-ref.
create-application-ref takes in a cluster as target, and propagating the info to all the instance of the cluster (ie, create the application-ref),
this new command should also take in a cluster as target, and propagate the VS info to all the <application-ref> of the instance of this cluster.

relying on user to call the 'set' command to set the VS of the <application-ref> of the cluster, and then run the set command again on all the instances of the cluster
so that the cluster and instances <application-ref> reflects the same VS attribute is very error-prone.

Comment by Hong Zhang [ 18/Oct/11 ]

We will look at the new command in the trunk.

Comment by Hong Zhang [ 12/Dec/12 ]

Scrubbing issues for GlassFish 4.0.





[GLASSFISH-16915] provide interface to install libraries e.g. JDBC driver Created: 27/Jun/11  Updated: 14/Dec/11

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

Type: Improvement Priority: Major
Reporter: schaarsc Assignee: Hong Zhang
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-17669 libraries relative to <domaindir>/lib... Resolved
Tags: 3_1_2-exclude

 Description   

GF no longer provides support for adding libraries to classpath. As a result of this design decision GF can no longer be configured remotly. With GFv2 it was possible to configure JDBC conn-pool with asadmin remote cmd and also add the driver jar (if available on disk) to the classpath with asadmin remote cmd. With GFv3 we have to ssh into the remote machine copy jar to */lib, then use asadmin remote cmd to configure the rest. In environments where security policies restict ssh usage GF can no longer be configured.

In order to provide full remote configuration support GFv3 need some admin commands to install 3rd party libs.
The best thing would be to extend common classloader with classpath support (can configure native libs with native-lib-path, but classpath-prefix/suffix has been dropped ??? )
Second best alternative is to provide a well defined interface to install libs (it is not acceptable to force users to manipulate configuration on disk, well defined interafeces should be provided)

Such an interface could look like this:
supported interfaces: admainGUI, asadmin, REST
commands:
list-lib -target [domain|config-name]
delete-lib -lib-name <lib-name> --target [domain|config-name]
install-lib -source [server|local] -source-path <path> --target [domain|config-name]
(to deploy an app with REST id-field accepts path on server or POST upload, this should be the same here)



 Comments   
Comment by Tom Mueller [ 27/Jun/11 ]

This request is also recorded in BugDB issue 12696007

Comment by Tom Mueller [ 27/Jun/11 ]

The classpath-prefix and classpath-suffix fields are displayed as unsupported in the console, but they can still be set with the set command, and the server does use the values. For example,

asadmin set configs.config.server-config.java-config.classpath-suffix=example.jar
asadmin restart-domain

results in a classpath argument as follows when the domain is restarted:

-cp /scratch/trm/test/glassfish3/glassfish/modules/glassfish.jar:/scratch/trm/test/glassfish3/glassfish/domains/domain1/config/example.jar

For practical use of this, the JAR file specification should be an absolute path or a relative path outside of the config directory.

Is there a reason why this doesn't work?

Also, it may be possible to deploy libraries using a RAR file along with the use of the --libraries option of the deploy command for applications.

Comment by Anissa Lam [ 27/Jun/11 ]

"The classpath-prefix and classpath-suffix fields are displayed as unsupported in the console, but they can still be set with the set command, and the server does use the values."

Are you sure the server really uses the values ?
These 2 values are not supported in v3 due to architectural change.
Please refer to http://java.net/jira/browse/GLASSFISH-10967 on discussion about these 2 attributes.

Comment by Tom Mueller [ 27/Jun/11 ]

Anissa's comment is correct. Even though the JAR files show up in the classpath, the classes in them will not be available to the applications. So ignore my previous comment.

Comment by Andreas Rieck [ 27/Jun/11 ]

This enhancement request is NOT a request to get legacy classpath-prefix and classpath-suffix back to GFv3 family.
classpath-prefix and suffix will not work since implementing OSGi with Glassfish v3 and might never come back to Glassfish.

It is a request to have a new interface developed from Glassfish administration point of view (asadmin, gui and rest).
This interface should handle the "file copy" recommendations "Circumventing Class Loader Isolation" described at this doc
http://download.oracle.com/docs/cd/E18930_01/html/821-2418/beadh.html
It is just the question to have a "asadmin/gui" feature implemented which will handle these "manual file copies" for
the various lib directories described on this page.

The szenario is a admin access to DAS gui, but no unix commandline permissions to ssh login for manual file copies (eg. jdbc drivers).

A second alternative option is maybe a new environment variable called "common-class-loader-path". (or similar)
If such environment variable can be implemented, then the common class loader might be able to load libraries,
classes, jar's, zip's from the standard default ./lib path (as described in docs) and then from another manual
configured path on second step.

Comment by Tom Mueller [ 29/Sep/11 ]

Hong, I think this is a duplicate of something that you are already working on.

Comment by Hong Zhang [ 14/Dec/11 ]

After various discussions, the plan is to limit the scope of this feature in this release to this set of commands:

asadmin add-library (to install libraries)
asadmin remove-library (to remove libraries)
asadmin list-libraries (to list libraries)

there will be no target support available for this release. And the instances will need to be restarted to synch over the libraries. Further enhancements will be made in the later releases.





[GLASSFISH-18329] Deployment/kernel cleanup - Phase 4: Misc Tasks Created: 06/Feb/12  Updated: 15/Jan/13

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

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

Issue Links:
Related
is related to GLASSFISH-17326 Nucleus class DeploymentUtils has Jav... Resolved
Tags: spo

 Description   

Hong,

I am creating this task to capture what we discussed the other day. As you might have noticed, I have cleaned up XModuleType which was a prerequisite for these items. Feel free to create subtasks if you wish. I am definitely hopeful doing all these will not only give us cleaner code, but also improve performance. Moreover, this will also help us getting closer to modular dol.

1) Move DeploymentUtils.isEJB/isWAR/isEAR/isRAR/isCAR to respective ArchiveDetector.handles(). Because cloud folks and admin gui introspects archive without deployment context, we need two methods: one that accepts DeploymentContext so that it could retrieve the information already computed in earlier stages of deployment and another one that just takes an Archive.

2) deployer sorting cleanup

3) Fix the following code which is in DeployCommand in nucleus: // done to disable versioning support for osgi
if ( name != null && !isUntagged && type != null && type.equals("osgi") ) {

4) Preselect certain sniffers to improve performance - especially for ejbjar. This is no longer a low priority, as this has to be fixed in order to address the osgi archive type support.

5) Remove List<Sniffer> prepareSniffersForOSGiDeployment(String type, DeploymentContext context) from Deployment; Its implementation in ApplicationLifecycle is incorrectly treating type as containerType instead of archiveType. The man page says it is archive type. Moreover, it seems to be created as a shortcut to address issues involved in OSGi archive type support. While doing this, make OSGiArchiveHandler a non-composite handler.

Optional:
6) It will be better to introduce an abstraction called DeploymentUnit with subclasses like Ear, EjbJar, War, Rar, Car, PlainJar, OSGiArchive, etc. It represents the structure of the bits getting deployed. Adding a new DeploymentUnit is a very expensive operation. It is like adding a new language in an extensible extensible compiler architecture. ArchiveHandler can be a producer of these objects with a source Archive as input. Since this is a stateful object, this can be set in DeploymentContext as opposed to storing a stateless object like ArchiveHandler. DeploymentUnit can have a method called getModuleType(): XModuleType. DeploymentUnit should also have a method called getSource(): ReadableArchive.

7) Remove all XXX_SNIFFER_TYPE constants from Application config bean. This will also require a change in ApplicationLifecycle which is using CONNECTOR_SNIFFER_TYPE to decide which applications to load first. We should separate that as a strategy and provide it from j2ee server distribution. Instead of looking for sniffer types, use archive type and define a loading order for each archive type. Allow the loading order to be overridden by application metadata during deployment: to be done

8) Add a method in ArchiveHandler called getEmbeddedClasses() which can be used by SnifferManagerImpl to iterate over while looking for annotations. This will avoid the hack we have in DeploymentUtils.getModuleLibraryJars() which being in nucleus knows about all the archive types and not at all extensible.

9) Why don't we call Sniffer.handles() first before looking for annotations in SnifferManagerImpl.getSniffers()?

Thanks,
Sahoo



 Comments   
Comment by Hong Zhang [ 26/Apr/12 ]

Some changes checked in this week related to the clean up tasks:

1. Remove javax.enterprise.deploy dependency from nucleus distribution (deployment-common module). Move various methods of getting archive types from DeploymentUtils to DOLUtils and update the classes referencing the methods.

2. Have the archive handlers be responsible for returning the associated class path URLs for the archive instead of having the DeploymentUtils class do it for them. Add an ArchiveHandler.getClassPathURIs API for each archive handler to return its corresponding class path URLs and move out the relevant logic from DeploymentUtils (deploymenmt-common module) and SnifferManagerImpl (core-kernel module).

2) here addressed item 8 in the task list.

Comment by Hong Zhang [ 21/Jun/12 ]

Add a new item in the clean up list:

10) We should be able to clean up CompositeSniffer interface now we have Sniffer.supportsArchiveType API

Comment by Hong Zhang [ 26/Jul/12 ]

Addressed item 1 of the task list. Replace various isXXX methods with generic isArchiveOfType methods (one takes a DeploymentContext when it's applicable for optimization, and one does not for the case where DeploymentContext is not available from the calling code) to remove Java EE dependencies from DeploymentUtils. The container specific logic are moved to the corresponding container modules.
Committed svn version: svn 55221

Comment by Hong Zhang [ 10/Aug/12 ]

Addressed item 10 of issue 18329: clean up CompositeSniffer interface now we have Sniffer.supportsArchiveType API.
Committed svn version: svn 55391

Comment by Hong Zhang [ 14/Aug/12 ]

Addressed item 5 of the list. Removed special handling for OSGi archive type, removed Deployment.prepareSniffersForOSGiDeployment API, with the
Sniffer.supportsArchiveType API we no longer need this. Also removed the
SnifferManager.canBeIsolated API to remove the artificial restriction on
the type option.
Committed svn version: svn 55449

Comment by Hong Zhang [ 15/Jan/13 ]

Scrub issues for Java EE 7 release.





[GLASSFISH-18920] Pick-up @ApplicationException from different deployment unit Created: 19/Jul/12  Updated: 10/Oct/12

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

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

Issue Links:
Related
is related to GLASSFISH-18918 [OSGi/JavaEE] Annotated ApplicationEx... Resolved

 Description   

Use case:

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

The concrete issue:

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

Result:

  • defined behaviour of the @ApplicationException is not applied

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

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



 Comments   
Comment by Hong Zhang [ 19/Jul/12 ]

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

Comment by Sanjeeb Sahoo [ 19/Jul/12 ]

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

Comment by Hong Zhang [ 10/Oct/12 ]

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





[GLASSFISH-18671] Logger names are too long Created: 01/May/12  Updated: 15/Feb/13

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

Type: Improvement Priority: Major
Reporter: Cheng Fang Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

some logger names in server.log:

javax.enterprise.system.tools.admin.org.glassfish.deployment.admin

javax.enterprise.system.tools.deployment.org.glassfish.deployment.common

javax.enterprise.system.container.web.com.sun.enterprise.web

javax.enterprise.system.container.ejb.com.sun.ejb.containers

These long logger names occupy a big portion of the log line, making it harder to view logs and increasing log size unnecessarily.

The use of javax prefix for an implementation of some standard is questionable. From a user/admin's perspective, he doesn't care if the module is implementing a standard or not. It's just a piece of the GlassFish product.

The use of this kind of prefix also makes it hard for average users to map the log to a subsystem. I suggest we simplify the logger name to something like:

org.glassfish.naming
org.glassfish.ejb
org.glassfish.web (and their sub loggers, if any).



 Comments   
Comment by sandeep.shrivastava [ 15/Feb/13 ]

We had gone through extensive reviews for the Logging One Pager and it was decided by AsArch to use the javax.enterprise prefix for GlassFish.

You could use shorter logger names as follows

javax.enterprise.system.tools.deployment.admin

javax.enterprise.system.tools.deployment.common

javax.enterprise.system.container.web

javax.enterprise.system.container.ejb

I am turning this back to you for updating the logger names used.

Comment by Tom Mueller [ 15/Feb/13 ]

Reassigning to component lead as the assignee is no longer with the project.

Comment by Hong Zhang [ 15/Feb/13 ]

Need to talk with other teams to see if we can make this change consistently across areas.





[GLASSFISH-16358] need better user experience when deploying ear application packaged in archive/directory mixed format Created: 14/Apr/11  Updated: 14/Apr/11

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

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


 Description   

User reported the deployment of their application did not work on windows XP:

====================================================
I've encountered the following issue while deploying an ear file on
Glassfish.

Issue: Some of the .uix files turned out to be 0kb after deploying,
however, this kind of problem did not happen on other J2EE application
servers such as Weblogic.

If I unpack the ear file first and deploy it in directory form, this
issue would not happen.

Glassfish Version: 3.1

JDK: 1.6.0_24

Platform: Windows 7 32 bit/Windows XP 32 bit
=====================================================

After investigation, the basic issue here is that the ear was not packaged as defined in the Java EE spec. At the top level it was packaged as an ear, but at module level, the modules are in expanded format (not .jar/.war/.rar format). The user verified after the application was packaged as specified in the EE spec, things worked as expected. However, the GlassFish should be enhanced to provide better user experience for this scenario, we could either support this type of packaging as a vendor extension or at least should provide a good error message to give user more clue why it did not work.






[GLASSFISH-16158] Register monitoring probes for deployed applications Created: 04/Mar/11  Updated: 21/May/13

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

Type: New Feature Priority: Major
Reporter: Jennifer Chou Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

To consider in 3.2:

If an application has defined Probes and ProbeProviders, during deployment we should register the Probes/ProbeProviders with GlassFish Monitoring.

In MonitoringBootstrap (admin/monitor) we have registerProbes which can be used.

public synchronized void registerProbes(String appName, File appDir, ClassLoader cl) {

This is currently used by connector module to register the system app jdbcra when it gets loaded.

Then a user does not need to call probeProviderFactory.getProbeProvider(getClass());
http://blogs.sun.com/foo/entry/mort_learns_how_to_use

Maybe there is also some way we can handle any ProbeListeners that are defined.



 Comments   
Comment by Hong Zhang [ 02/May/11 ]

Jennifer: is this still valid with the upcoming changes on the monitoring framework?

Comment by Hong Zhang [ 10/Oct/12 ]

Scrubbing RFEs for GlassFish 4.0.

Comment by Jeremy_Lv [ 15/May/13 ]

Shall we need to implement this in the upcoming version of the glassfish?

I have a question about registering the probe, I have develop a sample about registering the probes to the WebStatsProviderBootstrap and EjbMonitoringStatsProvider before and found we should set the monitor level to high if we want to register the probe to the WebStatsProviderBootstrap and EjbMonitoringStatsProvider. If we just MonitoringBootstrap to get the probe registered, Is it needed for us to set the monitor level? if it is needed, I think it will affect the performance of the deployment.

Comment by marina vatkina [ 21/May/13 ]

Everything by default is registered at HIGH level. LOW level isn't very easy to use - see GLASSFISH-20529





[GLASSFISH-16560] very slow EAR deployment (annotation scanning seems to be very slow) Created: 05/May/11  Updated: 10/Oct/12

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

Type: Improvement Priority: Major
Reporter: fmeili Assignee: Hong Zhang
Resolution: Unresolved Votes: 9
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Independent of OS and HW. Seen on Linux and Windows, 32 and 64 bit.


Attachments: Java Archive File dol.jar     File gf31_slow_ear_deployment.nps     File prof_with_dol_patch.nps    
Tags: 3_1_1-scrubbed, 3_1_1-scu, 3_1_x-exclude, annotation, deployment, ear, slow

 Description   

Using the following EAR file:

18 jar files with 383 Stateless EJB's an 65 MDB in the root directory of the EAR archive.
19 war files with 66 Servlets in the root directory of the EAR archive.
152 jar files in the ./lib directory of the EAR file.
Size of EAR file is 75 MByte.

The EAR file deploys in GF 2.1.1 in 40 seconds. With GF 3.0, 3.1 (b43) and 3.2-SNAPSHOT it deploys in >400 seconds. So it deploys 10 times slower than in GF 2.1.1.

We use a lot of self developed annotations (>70) which reside in jar files in the ./lib directory of the EAR file.

The profiling shows us that the time gets consumed in the method com.sun.enterprise.deployment.annotation.impl.ModuleScanner.addScanURI(). This method is called from the method addLibraryJars() in the same class. It seems, that for all found annotation, the whole amount of jar files get always scanned for annotaions. This task takes very long time and is very cpu intensive. In my profile sample, the method addScanURI() is called many thousand times from the method addLibraryJars(). I think the result of already scanned classes for annotations should be remembered and reused.

I've attached a JVisualVM profiling file.



 Comments   
Comment by Hong Zhang [ 05/May/11 ]

Yeah, there is a difference in 2.1 and 3.1 for annotation processing. In 2.1, we did not do annotation processing for library jars which was a bug and we fixed it in 3.1.
However, when we process annotations in 3.1, we do only scan it once and store the results for late processing. The addScanURI API does not actually do the annotation scanning. The scanning was done only once in ApplicationLifecycle.getDeployableTypes and addScanURI is just matching the URI with the scanned results and get the relevant processed results.
While 152 jars is a big number of jars which is expected to take significant time in annotation scanning, 40s vs 400s does seem a big difference. We will take a look to see if there is anything else we can improve here. Maybe we can introduce a property when set to skip annotation processing for the library jars (as in this case, your library jars do not really need scanning/processing as they don't contain JavaEE annotations).

Comment by fmeili [ 05/May/11 ]

Are you sure that the GF 3.1 only scan each jar file once for annotation processing? What we see in the profiling data (see attached file), each jar file is scanned very often. We have 152 jar files in the ./lib directory, but the method addScanURI() is called 8208 times for one EAR deploy task.

In the attached nbs-file you'll see the profile for one EAR deploying. When you open the largest time consuming tree's you'll find that the Method com.sun.enterprise.deployment.annotation.impl.ModuleScanner.addScanURI() is called 5472 times from com.sun.enterprise.deployment.annotation.impl.ModuleScanner.process() and 2736 times from com.sun.enterprise.deployment.annotation.impl.WarScanner.process()). Both are the cpu hot spot points in the profile.

By the way, can you explain me in short why it's necessary to scan the whole ./lib directory for annotations, while deploying an ear?

Thanks for your fast answer,
Frank

Comment by Hong Zhang [ 05/May/11 ]

It's a Java EE platform spec requirement that all classes packaged inside the archive needs to be scanned for annotation. It's not recommended for the library jars to contain component annotations like @EJB etc, but it can include annotation like @ApplicationException.

I am a little surprised to hear that the addScanURI will be invoked so many times, I will look into the code to see what I can find.

Comment by fmeili [ 05/May/11 ]

If it would help you, I can provide you more cpu profiling data, stack traces or something else, please let me know.

Thanks,
Frank

Comment by Hong Zhang [ 05/May/11 ]

Looking at the code, I kind of understand why there will be so many addScanURI calls now.

For each module inside the ear, when we process annotations for that module, we will include the library jars as if the library jars were packaged directly in that module.

So for 152 library jars and 19 wars, you would get 152 x 19 = 2888 from the WarScanner.
And for 18 ejb jars, you would get 152 x 18 = 2736 from the EjbJarScanner.
And then as both classes call its super class ModuleScanner, the ModuleScanner.addScanURI should get called total 5624.

The numbers don't exactly match with your numbers yet, but I guess we know why there could be so many calls.

I still need to figure out why this addScanURI call is expensive, but certainly any method with this many number of calls will take a significant of time.

When we wrote the code, we did not think too much about this type of scenario with so many library jars and module jars. We will think about how to optimize for this type of scenario. Maybe as you said, we can try to cache the results of the library jar matching.

Comment by Hong Zhang [ 05/May/11 ]

I think I understand why the addScanURI is expensive now. It still have references to some old code where we used to scan the class again.

I have seen significant time improvement with a test case I created after I changed this part. I will do more testing and then check in the change to 3.1.1. As the 3.1 has FCSed, any bug fixes can only be made into 3.1.1 or 3.2. I can send you a patch for you to install locally and try too.

You can download 3.1.1 from here http://dlc.sun.com.edgesuite.net/glassfish/3.1.1/
once I check in my change.

Comment by fmeili [ 06/May/11 ]

Ok, good to hear that you've found the problem. I think, it will be helpful for you when I also test the patch locally on my system with our EAR file. Can I download the patch somewhere? Til now, the newest version, at the link you provided in your last message, is glassfish-3.1.1-b04.zip (form 4th May). Will the patch fit to this version?

Comment by Hong Zhang [ 06/May/11 ]

After you install the 3.1.1 build, replace the dol jar in the glassfish3/glassfish/modules directory with this patch dol.jar. Then try to deploy your application to see how much difference it makes.

Comment by Hong Zhang [ 06/May/11 ]

I just attached the patch in the issue. I think it should match with that 3.1.1 build, but if you see any problem, I can provide a patch for the 3.2 too (I plan to backport the change there too). You could do a baseline measurement before you install the patch. And then reinstall the build, and install the patch and see what difference it makes.

Comment by fmeili [ 09/May/11 ]

I've done some tests with the patch you've provided. The deployment time with the dol patch was shrinking from 400 seconds to 170 seconds, which is a big improvement.

Glassfish 3.1.1 b04 original: 400 s
Glassfish 3.1.1 with dol patch: 170 s
Glassfish 2.1.1 b31g-fcs: 40 s

Now the EAR deployment is not longer 10 times slower compared with GF 2.1.1, but is still 4 times slower. I've done some profiling with the dol patch, but sadly I couldn't find an additional single CPU hot spot (like in the version without the dol patch). As far as I can see, the most CPU time get consumed in annotation processing, but not at in a single method. There are a bunch of methods involved. I've attached a profiler snapshot with dol patch active. Maybe you can find something else which may be problematic while deploying.

Thank for your fast response and patch.
Greetings, Frank

Comment by Hong Zhang [ 09/May/11 ]

Frank thanks for verifying the patch! Glad this patch had made big improvement (and thanks again for reporting this and providing the profiling data pointing us to where we could improve significantly). I have checked in the changes into both 3.1.1 branch and the trunk (3.2) now.

For the next step, I will probably take a look to see if we can save the processed results for the libraries and re-use it for each module instead of doing this for each module. But please keep in mind, as we are now additionally processing these library jars while we didn't in 2.1, there will be always time differences compared to 2.1 (especially when the application contains large amount of library jars).

Comment by Hong Zhang [ 18/Oct/11 ]

Could not find any more simple set of the changes which could improve significantly. I am keeping this as a RFE for improvement in future release.

Comment by Hong Zhang [ 10/Oct/12 ]

Scrubbing RFEs for GlassFish 4.0.





[GLASSFISH-16549] limit redeployment to necessary activity Created: 04/May/11  Updated: 10/Oct/12

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

Type: Improvement Priority: Major
Reporter: vince kraemer Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

app server where issue 16548 is implemented


Tags: redeploy-optimization

 Description   

avoid doing unnecessary work for a redeploy action where the only change is in an apps 'static content'...

a full redeployment is not necessary when there is a change to a jsp file, an html file, etc.

combining this improvement with issue GLASSFISH-16548 would allow more developers to have a fast development iteration (edit/deploy/validate) than they currently experience.



 Comments   
Comment by Hong Zhang [ 10/Oct/12 ]

Scrubbing RFEs for GlassFish 4.0.





[GLASSFISH-16548] redeploy an app with a partial archive that includes changed or new files only Created: 04/May/11  Updated: 10/Oct/12

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

Type: Improvement Priority: Major
Reporter: vince kraemer Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

any


Tags: redeploy-optimization

 Description   

support partial archive redeployment.

allows users to redeploy existing files or add new files to a deployed application/module without repackaging and transmission of a complete archive. deleting a file from an existing application would require a 'full archive' deployment action.



 Comments   
Comment by Hong Zhang [ 10/Oct/12 ]

Scrubbing RFEs for GlassFish 4.0.





[GLASSFISH-21152] memory leak in com.sun.enterprise.v3.common.ActionReporter Created: 01/Aug/14  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 4.0, 4.1
Fix Version/s: None

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

any


Tags: leak, memory

 Description   

The ActionReport keeps references to all deployed applications (via subAction). Thus any deployed applications are never unloaded properly.

Here is my workaround, by using SoftReferences in the subActionList

ActionReporter.java
...
    protected ArrayList<SoftReference<ActionReporter>> subActionRefs = new ArrayList<SoftReference<ActionReporter>>();
...
    @Override
    public ActionReport addSubActionsReport() {
        ActionReporter subAction;
        try {
            subAction = this.getClass().newInstance();
        } catch (IllegalAccessException ex) {
            return null;
        } catch (InstantiationException ex) {
            return null;
        }
        synchronized (subActionRefs) {
            subActionRefs.add(new SoftReference<ActionReporter>(subAction));
        }
        return subAction;
    }

    @Override
    public List<ActionReporter> getSubActionsReport() {
        final ArrayList<ActionReporter> subActions = new ArrayList<ActionReporter>();
        synchronized (subActionRefs) {
            for (final Iterator<SoftReference<ActionReporter>> i = subActionRefs.iterator(); i.hasNext();) {
                final SoftReference<ActionReporter> s = i.next();
                final ActionReporter ar = s.get();
                if (ar == null) {
                    i.remove();
                    continue;
                }
                subActions.add(ar);
            }
        }
        return subActions;
    }
...

plus replace the direct access to subActions with getSubActionsReport()






[GLASSFISH-21144] EAR deployment fails on GF 3.1.2.2 Created: 25/Jul/14  Updated: 28/Jul/14

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1.2_b05
Fix Version/s: None

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

Solaris: SunOS cl-app-ejbc 5.10 Generic_144489-14 i86pc i386 i86pc
Java: Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
Java HotSpot(TM) Server VM (build 17.0-b16, mixed mode)



 Description   

We have an ear archive which contains various applications including a client delivered via WebStart. Irrespective of the method we use to deploy (asadmin command line, copy to autodeploy, deploy via admin console) we get the same error.

Any help/pointers appreciated.

[#|2014-07-24T16:32:05.585+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=28;_ThreadName=Thread-2;|Exception while loading the app : injection failed on org.glassfish.appclient.server.core.jws.JavaWebStartInfo.jwsAdapterManager with class org.glassfish.appclient.server.core.jws.JWSAdapterManager
org.jvnet.hk2.component.ComponentException: injection failed on org.glassfish.appclient.server.core.jws.JWSAdapterManager.extensionFileManager with class org.glassfish.appclient.server.core.jws.ExtensionFileManager
at org.jvnet.hk2.component.InjectionManager.error_injectionException(InjectionManager.java:284)
at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:165)
at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:93)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:126)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at org.jvnet.hk2.component.Habitat.getBy(Habitat.java:1056)
at org.jvnet.hk2.component.Habitat.getByType(Habitat.java:1037)
at com.sun.hk2.component.InjectInjectionResolver.getComponentInjectValue(InjectInjectionResolver.java:159)
at com.sun.hk2.component.InjectInjectionResolver.getValue(InjectInjectionResolver.java:90)
at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:143)
at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:93)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:126)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at org.jvnet.hk2.component.Habitat.getBy(Habitat.java:1056)
at org.jvnet.hk2.component.Habitat.getByType(Habitat.java:1037)
at org.jvnet.hk2.component.Habitat.getComponent(Habitat.java:781)
at org.glassfish.appclient.server.core.AppClientServerApplication.newJavaWebStartInfo(AppClientServerApplication.java:156)
at org.glassfish.appclient.server.core.AppClientServerApplication.start(AppClientServerApplication.java:148)
at org.glassfish.appclient.server.core.AppClientServerApplication.start(AppClientServerApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
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:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:353)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:145)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:575)
at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:461)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:389)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:380)
at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:220)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Caused by: java.lang.RuntimeException: java.util.zip.ZipException: error in opening zip file
at org.glassfish.appclient.server.core.jws.ExtensionFileManager.postConstruct(ExtensionFileManager.java:109)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at org.jvnet.hk2.component.Habitat.getBy(Habitat.java:1056)
at org.jvnet.hk2.component.Habitat.getByType(Habitat.java:1037)
at com.sun.hk2.component.InjectInjectionResolver.getComponentInjectValue(InjectInjectionResolver.java:159)
at com.sun.hk2.component.InjectInjectionResolver.getValue(InjectInjectionResolver.java:90)
at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:143)
... 43 more
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:114)
at java.util.jar.JarFile.<init>(JarFile.java:135)
at java.util.jar.JarFile.<init>(JarFile.java:99)
at org.glassfish.appclient.server.core.jws.ExtensionFileManager.buildExtensionForJar(ExtensionFileManager.java:215)
at org.glassfish.appclient.server.core.jws.ExtensionFileManager.addExtJarsFromDirectory(ExtensionFileManager.java:196)
at org.glassfish.appclient.server.core.jws.ExtensionFileManager.buildExtensionFileEntries(ExtensionFileManager.java:172)
at org.glassfish.appclient.server.core.jws.ExtensionFileManager.prepareExtensionInfo(ExtensionFileManager.java:115)
at org.glassfish.appclient.server.core.jws.ExtensionFileManager.postConstruct(ExtensionFileManager.java:107)
... 54 more

#]


 Comments   
Comment by dnu [ 28/Jul/14 ]

I am a colleague of jamesiggulden and I found a corrupt jar file in the /lib/ext directory of the domain. A message about this corrupt jar file was output when the server started up:

[#|2014-07-28T15:54:14.321+0100|INFO|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deplo
yment.common|_ThreadID=10;_ThreadName=Thread-2;|DPL5410:Skipping extension processing for /opt/sfw/open-glassfis
h-v3.1.2/glassfish/domains/ejb/lib/ext/11.2.0.1-ojdbc6_g.jar due to error: error in opening zip file|#]

Replacing this jar with an uncorrupted version resolved the issue during deployment.





[GLASSFISH-21198] Clustered / Versioned applications cannot be enabled on individual cluster instances Created: 15/Sep/14  Updated: 26/Jul/15

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

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

aLL



 Description   

When deploying versioned applications, and trying to upgrade versions
instance-at-a-time, when enabling the first instance, all instances are disabled instead.

(version 1.0 working on the cluster)
$ asadmin deploy --enabled=false --target cluster app:1.1
(good)
$ asadmin enable --target inst1 app:1.1
(all versions of app are now inaccessible on all instance in the cluster)
i.e. Page Not Found error



 Comments   
Comment by lprimak [ 08/Jan/15 ]

This is still an issue

Comment by lprimak [ 26/Jul/15 ]

This is still an issue, and prevents rolling upgrades from happening correctly





[GLASSFISH-21196] Remote Deploy of Maven EAR issues java.util.concurrent.TimeoutException Created: 15/Sep/14  Updated: 30/Sep/14

Status: Open
Project: glassfish
Component/s: admin, concurrency, deployment
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gesker Assignee: Chris Kasso
Resolution: Unresolved Votes: 10
Labels: concurrency, deploy, jdk8, maven, netbeans, timeout
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Workstation: Win 8.1 Pro, jdk8_20, GlassFish_4.1, NetBeans_8.0.1
Server: Ubuntu Server 14.04, jdk8_20, GlassFish_4.1



 Description   

Maven Enterprise Project (of about 27 MB in size) cannot be deployed from NetBeans using DAS port.

This same EAR can successfully be deployed to GlassFish_4.1 on server using the Web – Admin console.

When attempting to deploy to the remote server from NetBeans on workstation the logs on the server record:

Exception while running a command
java.io.IOException: java.util.concurrent.TimeoutException
at org.glassfish.admin.payload.PayloadFilesManager.extractFile(PayloadFilesManager.java:584)
at org.glassfish.admin.payload.PayloadFilesManager.access$600(PayloadFilesManager.java:93)
at org.glassfish.admin.payload.PayloadFilesManager$DataRequestType$1.processPart(PayloadFilesManager.java:749)
at org.glassfish.admin.payload.PayloadFilesManager.processPartsExtended(PayloadFilesManager.java:618)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$UploadedFilesManager.extractFiles(CommandRunnerImpl.java:2074)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$UploadedFilesManager.<init>(CommandRunnerImpl.java:2046)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$UploadedFilesManager.<init>(CommandRunnerImpl.java:2025)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1155)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandlerBase.service(StaticHttpHandlerBase.java:189)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
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:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
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:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
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:745)
Caused by: java.io.IOException: java.util.concurrent.TimeoutException
at org.glassfish.grizzly.nio.transport.TCPNIOTransportFilter.handleRead(TCPNIOTransportFilter.java:90)
at org.glassfish.grizzly.filterchain.TransportFilter.handleRead(TransportFilter.java:173)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.read(DefaultFilterChain.java:351)
at org.glassfish.grizzly.filterchain.FilterChainContext.read(FilterChainContext.java:695)
at org.glassfish.grizzly.portunif.BackChannelFilter.handleRead(BackChannelFilter.java:80)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.read(DefaultFilterChain.java:351)
at org.glassfish.grizzly.filterchain.FilterChainContext.read(FilterChainContext.java:695)
at org.glassfish.grizzly.portunif.BackChannelFilter.handleRead(BackChannelFilter.java:80)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.read(DefaultFilterChain.java:351)
at org.glassfish.grizzly.filterchain.FilterChainContext.read(FilterChainContext.java:695)
at org.glassfish.grizzly.http.io.InputBuffer.blockingRead(InputBuffer.java:1119)
at org.glassfish.grizzly.http.server.io.ServerInputBuffer.blockingRead(ServerInputBuffer.java:95)
at org.glassfish.grizzly.http.io.InputBuffer.fill(InputBuffer.java:1143)
at org.glassfish.grizzly.http.io.InputBuffer.read(InputBuffer.java:353)
at org.glassfish.grizzly.http.server.NIOInputStreamImpl.read(NIOInputStreamImpl.java:83)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
at java.io.FilterInputStream.read(FilterInputStream.java:133)
at java.io.PushbackInputStream.read(PushbackInputStream.java:186)
at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:238)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158)
at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
at java.io.FilterInputStream.read(FilterInputStream.java:107)
at org.glassfish.admin.payload.ZipPayloadImpl$Inbound$ZipEntryInputStream.read(ZipPayloadImpl.java:220)
at org.glassfish.admin.payload.PayloadFilesManager.extractFile(PayloadFilesManager.java:549)
... 46 more
Caused by: java.util.concurrent.TimeoutException
at org.glassfish.grizzly.nio.tmpselectors.TemporarySelectorReader.read(TemporarySelectorReader.java:126)
at org.glassfish.grizzly.nio.tmpselectors.TemporarySelectorReader.read(TemporarySelectorReader.java:75)
at org.glassfish.grizzly.AbstractReader.read(AbstractReader.java:72)
at org.glassfish.grizzly.nio.transport.TCPNIOTransportFilter.handleRead(TCPNIOTransportFilter.java:77)
... 80 more
]]

Some notes:

The ear is approx 27 MB.

Have run asadmin enable-secure-admin on the server. I am able to restart GlassFish_4.1 on the server and see its logs from Netbeans.

Had tried setting environment variable AS_ADMIN_READTIMEOUT="3600000" on the server within the init script but this did not help.

I wanted to rule out a configuration issue with my application as the issue so I did the following:

I creating some small projects in NetBeans_8.0.1:

Created a sample web application (no extras) from NetBeans template and it ran/deployed fine.
Created a sample web application (maven - no extras) from NetBeans template and it ran/deployed fine.
Created a sample EAR application (no extras) from NetBeans template and it ran/deployed fine.
Created a sample EAR application (maven - no extras) from NetBeans template and it ran/deployed fine.

So, added some dependencies to the sample maven EAR just to bulk up its size – again nothing fancy just eclipselink and primefaces stuff. The sample EAR now stood at about 26MB.

Tried to run (remote deploy) the sample again got the same java.io.IOException: java.util.concurrent.TimeoutException indicated above as I did for my actual application.



 Comments   
Comment by bhicks01 [ 17/Sep/14 ]

Another bug for the same issue is 21180: https://java.net/jira/browse/GLASSFISH-21180

Comment by dennis@gesker.com [ 30/Sep/14 ]

Maybe what is going on here has something to to with the interaction between Netbeans_8.0.1/Maven_3.2.3/GlassFish_4.1

I had a little bit of time yesterday so I tried to revisit the remote deploy issue.

I pointed my actual project via NetBeans at my remote Glassfish and again got the java.io.IOException: java.util.concurrent.TimeoutException – OK no change there.

However, I went to the Admin console and deployed – no errors where thrown but after clicking on my application none of the modules were visible. I tired deploying several times this same way and got the same results. EAR deployed but with no modules (as if the WAR and EJB/JAR were not present)

Just for the heck of it I dropped by EAR in the autodeploy directory and the application deployed completely correct. All modules were found and the context root was correct.

So, I took a step back and created a new/empty maven EAR project. Tried a remote deploy via Netbeans and threw no errors. However, in the address bar of the browser rather than the root context it displayed the full name of the WAR file "MyProject-web-1.0-SNAPSHOT" Going into the admin console and clicking on the application to launch that way the options did show the correct context root.

I tried to remote deploy the empty EAR a couple more times via Netbeans. Sometimes it was successful. Sometimes it failed with "java.io.IOException: java.util.concurrent.TimeoutException" and sometimes it failed with "java.io.EOFException"

I tired adding the following to the "maven-ear-plugin" section of my pom.xml of my EAR:

<modules>
<webModule>
<groupId>com.mycompany</groupId>
<artifactId>MyProject-web</artifactId>
<contextRoot>/MyProject-web</contextRoot>
</webModule>
<ejbModule>
<groupId>com.mycompany</groupId>
<artifactId>MyProject-ejb</artifactId>
</ejbModule>
</modules>

But the behavior remained the same. I'm new to Maven. So, the above is just my poking about but maybe it will give someone with a better understanding of the interrelationship of these three tools a hint that is useful.

I really would like to stick with maven as I like how it handles dependencies and keeps my repository clean but if it just gets in the way of seamless remote deploys I can drop back to standard project templates, too.

Any advice or more information I can collect?

Comment by bhicks01 [ 30/Sep/14 ]

I'm not using netbeans or maven for deployment. I am using a custom ant build system to run the asadmin remote deployment, and it is failing. In fact, we had our deploy command defaulted to "--upload=true", which would fail every time for some projects (this was done even for localhost deployment).

We've worked around this by scp'ing the jar/ear/war to the destination host, then running the asadmin command via an "ssh -q <asadmin deploy cmd>".





[GLASSFISH-21215] UserError: ACC007 -- JAR does not contain a manifest Created: 26/Sep/14  Updated: 26/Sep/14

Status: Open
Project: glassfish
Component/s: deployment, ide-integration, packaging
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: thufir Assignee: Hong Zhang
Resolution: Unresolved Votes: 1
Labels: netbeans
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ubuntu 14.04



 Description   

background:

Java Web Start
Java Web Start allows your application client to be easily launched and automatically downloaded and updated. It is enabled for all application clients by default. For more information, see Using Java Web Start.

GlassFish Server Open Source Edition
Application Development Guide Release 4.0
page 172

and

Downloading and Launching an Application Client
If Java Web Start is enabled for your deployed application client, you can launch it for testing. Simply click on the Launch button next to the application client or application's listing on the App Client Modules page in the Administration Console.

GlassFish Server Open Source Edition
Application Development Guide Release 4.0
page 176

This, in fact, is incorrect. Appclient applications which run from the IDE launch from Glassfish missing the manifest. Glassfish fails to include the manifest with the JNLP file, resulting in errors such as:

org.glassfish.appclient.client.acc.UserError: ACC007: The app client file
/__JWSappclient/__app/SingletonQueue/SingletonQueueClient/
SingletonACCClient.jar does not contain a manifest; the app client
container cannot process it. Embedded programs should pass URIs with
scheme "jar:" for JAR files and scheme "file:" for directories.



 Comments   
Comment by thufir [ 26/Sep/14 ]

https://netbeans.org/bugzilla/show_bug.cgi?id=231769

http://markmail.org/message/5usjywzpyw3weesb#query:+page:1+mid:5usjywzpyw3weesb+state:results

http://forums.netbeans.org/topic22551.html

https://www.java.net/node/700937?force=967

http://stackoverflow.com/questions/11606529/need-help-running-an-ejb-app

apparently the error is caused by:

ACC007.diag.cause.1 = The file might not be a valid app client JAR or undeployed EAR. It might be another kind of file or have become corrupted.

neither of which is accurate. The EAR is valid and deploys, isn't corrupted.

https://community.oracle.com/thread/1570742?start=0&tstart=0

http://osdir.com/ml/java-netbeans-devel/2009-12/msg00043.html

https://forums.netbeans.org/topic21177.html

https://netbeans.org/bugzilla/show_bug.cgi?id=231769

https://www.java.net/node/700937?force=679

which is enough errors, and not enough solutions, to suggest that there's either a bug with glassfish itself or with the documentation. In any event, I can include logs if that's useful.





[GLASSFISH-21387] asadmin deploy failure won't yield error code != 0 Created: 07/Jul/15  Updated: 07/Jul/15

Status: Open
Project: glassfish
Component/s: admin, deployment
Affects Version/s: 4.1
Fix Version/s: None

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

linux



 Description   

Normally when I deploy my application war the asadmin deploy command would return a exit code != 0 if there was a problem (for instance if a @Startup annotated method threw an exception).

If I deploy the same war to a special target I get an error message but a error code of 0.

dev@devapp:/opt/dev/gfbin> asadmin --user admin --passwordfile /opt/dev/gfbin/work/gf.pwd --port 10000 deploy --target devcluster /var/opt/dev/transfer/gf/myapp.war
Application deployed with name myapp.
Warning: Command _deploy did not complete successfully on server instance dev1: remote failure: Failed to load the application on instance dev1. The application will not run properly. Please fix your application and redeploy.
Exception while loading the app : javax.ejb.CreateException: Initialization failed for Singleton MyStartupBean. Please see server.log for more details.
Command deploy completed with warnings.
dev@devapp:/opt/dev/gfbin> echo $?
0





[GLASSFISH-21378] can't redeploy Created: 19/Jun/15  Updated: 30/Jun/15

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

Type: Bug Priority: Major
Reporter: t.shimada Assignee: Arindam Bandyopadhyay
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Redhat linux 6.6



 Description   

We are using Glassfish 4.1 for our web-system. now we have problem that couldn't redeploy some applications.

behavior:

#1 To undeploy one application. It seems to be succeeded.
#2 But That Application don't stop. Because we can see too much log besides it continues outputting it.
------------------------------------------------
[2015-06-18T13:03:03.465+0900] [glassfish 4.1] [SEVERE] [] [javax.enterprise.web.util] [tid: _ThreadID=57 _ThreadName=admin-listener(5)] [timeMillis: 1434600183465] [levelValue: 1000] [[
The web application [/webpublisher] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@2458d471]) and a value of type [com.tangosol.net.GuardSupport.Context] (value [GuardContext {Guardable={WrapperGuardable Guard

{Daemon=DistributedCache:DistributedCache-StatusManagementData}

Service=PartitionedCache{Name=DistributedCache-StatusManagementData, State=(SERVICE_STARTED), LocalStorage=disabled, CoordinatorId=1}}, timeout=0, state=HEALTHY}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.]]
------------------------------------------------
#3 To deploy same application. But it didn't deploy.

I think that the problem is caused that logs.

Do you know workaround?



 Comments   
Comment by Arindam Bandyopadhyay [ 25/Jun/15 ]

Could you provide a sample application such that I can test the issue?

Comment by t.shimada [ 30/Jun/15 ]

Dear Arindam.

This is Toshikazu.(t.shimada)

Thank you for your reply.

I'm afraid to you.
we can't provide sample application.
Because that application is our customers's.

So if you know how to workaround, could you teach me it?
or please tell me if there are any examples.

I want to try these your knowledge.

I am looking forward to your reply.

Best Regards.

Comment by Arindam Bandyopadhyay [ 30/Jun/15 ]

In My Opinion this is a application specific problem . I have tried may application which are successfully deploying , undeploying and redeploying . So if I don't get the exact steps to reproduce the issue , I will not be able to identify the root cause and fix it .Please provide us the exact steps to reproduce the issue.





[GLASSFISH-21374] Custom Valve added without context Created: 11/Jun/15  Updated: 11/Jun/15

Status: Open
Project: glassfish
Component/s: deployment, web_container
Affects Version/s: 4.0, 4.1
Fix Version/s: None

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

Tags: valve

 Description   

Adding a custom valve (via the glassfish-web.xml) in which the custom class implements both org.apache.catalina.Valve and org.glassfish.web.valve.GlassFishValve results in the custom class being erroneously wrapped in the GlassFishValveAdapter. This means that the valve no longer implements any interfaces since the Adapter doesn't implement any interfaces. In particular the interfaces Contained and Lifecycle are lost when wrapped. If for example you are attempting to use the org.apache.catalina.authenticator.SpnegoAuthenticator from Tomcat (modified slightly) in GlassFish the valve will fail to invoke with a NullPointerException due to the context not being set. The context isn't set because the Contained interface is masked once the class is wrapped in the adapter.

There are actually two things going wrong, any one of which would solve the problem:

1. There are two addValve methods in org.apache.catalina.core.StandardPipeline, one for Valve and one for GlassFishValve. If the Valve method is called it will result in wrapping in an adapter. The com.sun.enterprise.web.WebModule.addValve(String className) is responsible for loading custom valves and it first checks if the valve is a Valve then calls the addValve(Valve) method, and only uses the addValve(GlassFishValve) if the first check fails. The order of these if statements should be reversed.

2. The addValve(Valve) method should check if the Valve is a GlassFishValve and call the addValve(GlassFishValve) method. It actually does a check using reflection and method signature to determined if the Valve is a legacy GlassFish specific version of org.apache.catalina.Valve (different than current version - yes apparently they changed the interface in the past!) and wraps in an adapter if it is. However, that legacy version of Valve looks like the new GlassFishValve (in my case it looks like it because it actually is it – the check does not check if the class actually IS GlassFishValve).



 Comments   
Comment by slominskir [ 11/Jun/15 ]

The title of this should be "Custom Valve Erroneously Wrapped in GlassFishValveAdaptor". However, looks like editing is not available. Also the sentence that reads "doesn't implement any interfaces" should read "doesn't implement any interfaces except GlassFishValve".

Comment by slominskir [ 11/Jun/15 ]

The "work around" is to create another custom valve that wraps the real valve and the custom valve wrapper implements all interfaces except org.apache.catalina.Valve.

Comment by slominskir [ 11/Jun/15 ]

See https://java.net/jira/browse/GLASSFISH-21373 about how this came about.





[GLASSFISH-21357] Entity Tables are not created during deployment time Created: 10/May/15  Updated: 11/May/15

Status: Open
Project: glassfish
Component/s: configuration, deployment
Affects Version/s: 4.1
Fix Version/s: None

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

GlassFish Server Open Source Edition 4.1 (build 13) with latest JDK 8


Tags: create, deployment, entity, generate, jpa, persistence, table

 Description   

It seems that in Glassfish 4.1 DB tables for JPA entity classes are not generated during deployment time. Previously, when deploying the application with the correct persistence.xml file and with generation type "create" (in GF 4.1 this would be <property name="javax.persistence.schema-generation.database.action" value="create"/>) then the tables should be created at deployment time.

This does not happen anymore. It seems to be a change of behavior and has caused heavy backwards compatibility issues for us after migrating from GF 3.1.2.2 to GF 4.1. It seems that since Glassfish 4.1 you need to use your PU somewhere before the tables are created. In other words: tables are created only when they are needed the first time.

The following stack overflow articles discuss that topic as well:

http://stackoverflow.com/questions/25489359/entity-table-is-not-creating-using-jpa-2-1

https://stackoverflow.com/questions/25935866/how-to-use-jpa-with-java-ee-7-glassfish-4-1-and-maven-on-javadb/28841583#28841583



 Comments   
Comment by Lukas Jungmann [ 11/May/15 ]

if you're using eclipselink, then adding 'eclipselink.deploy-on-startup=true' to your persistence.xml should resolve the problem





[GLASSFISH-21279] Application deployed failed, but application is deployed and alive Created: 25/Dec/14  Updated: 25/Dec/14

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

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

Windows 7 64-bit
Java JDK 1.7.0_45 64-bit



 Description   

Hi, I have war application, which used restEasy library to build rest interface. When I want to try deploy application via asadmin, then error message is shown:

remote failure: Request failed
Command deploy failed.

Step to reproduce
1. Download latest GlassFish version https://glassfish.java.net/download.html
2. Download war file from https://github.com/tomasma5/AFSwinx/blob/master/ExecutableArtifacts/AFServer.war or you can buy war file when you will clone repository and in root make: mvn clean install
3. Navigate to GlassFish directory to bin and type:
asadmin
start-domain domain1
deploy PATH_TO_APPLICATION
4. Deploy failed. Go to http://localhost:8080/AFServer and application is alive moreover you can try use web api on http://localhost:8080/AFServer/rest/country/list content-type:application/json method get
5. Running instance is freeze asadmin cant stop domain or shown you deployed application via list-applications command. Admin console on port 4848 is not working now. It helps when application is removed manually from applications folder.

Error log could be download here
This war works fine on GlassFish 3.1.2.

Sample from error log:

  An error occurred while processing the request. Please see the server logs for details.
org.glassfish.jersey.server.ContainerException: java.lang.AbstractMethodError: javax.ws.rs.core.Response.getStatusInfo()Ljavax/ws/rs/core/Response$StatusType;
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer$ResponseWriter.rethrow(GrizzlyHttpContainer.java:317)
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer$ResponseWriter.failure(GrizzlyHttpContainer.java:299)
	at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:439)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:277)





[GLASSFISH-21305] Glassfish 4.1 Application Client Java Web Start Compability Issue. Created: 13/Feb/15  Updated: 13/Feb/15

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

Type: Bug Priority: Major
Reporter: dbritton60 Assignee: Hong Zhang
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows x64 2008 Server



 Description   

I have created a Java EE "Enterprise Applicaiton Client" from Netbeans 8.02 (with not code changes whatsoever) and deployed it to
GlassFish 4.1 (b13) using java 1.8 u31.

I have replaced the glassfish s1as certificate with a signed one.

If I try and launch the Application Client I get the message "Application Blocked by Java Security", Reason: The Java security settings have prevented this application form running. You may change this behavior in the Java Control Panel. I get the same result from the glassfish control panel or javaws (1.8 u31).

Adding my site to the Exception Site List does not work.

It looks like the problem is between the newer Java Web Start clients and the Glassfish 4.1 auto-generated JNLP file .

If I install a java 1.7 u25 or earler javaws (Java Web Start 10.21.2.11 or earlier). I can start the application client and it will run in
the java 1.8 u31 environment.






[GLASSFISH-21233] NPE when deploying app with method returning lambda Created: 10/Oct/14  Updated: 11/May/15

Status: Open
Project: glassfish
Component/s: cdi, deployment
Affects Version/s: 4.1
Fix Version/s: None

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

Windows 8 64 bit

java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)

Eclipse, Java EE distribution, 4.4



 Description   

When deploying a WAR application (using the Eclipse Java EE development tools) to GlassFish a DeploymentException is thrown and the deployment is aborted.

This happens when the project contains a method which returns a lambda expression:

public class Utils {
public static <K, V> Function<K, V> noSuchElementThrower() {
return k ->

{ throw new NoSuchElementException(); }

;
}
}

The method does not need to be invoke anywhere.

The following is the log that is produced during the incident:

2014-10-10T11:39:54.560+0200|Info: Running GlassFish Version: GlassFish Server Open Source Edition 4.1 (build 13)
2014-10-10T11:39:54.560+0200|Info: Server log file is using Formatter class: com.sun.enterprise.server.logging.ODLLogFormatter
2014-10-10T11:39:54.638+0200|Info: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
2014-10-10T11:39:54.638+0200|Info: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
2014-10-10T11:39:54.638+0200|Info: Realm [certificate] of classtype [com.sun.enterprise.security.auth.realm.certificate.CertificateRealm] successfully created.
2014-10-10T11:39:54.654+0200|Info: Realm [seshat-realm] of classtype [com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm] successfully created.
2014-10-10T11:39:54.748+0200|Info: Authorization Service has successfully initialized.
2014-10-10T11:39:54.763+0200|Info: Registered org.glassfish.ha.store.adapter.cache.ShoalBackingStoreProxy for persistence-type = replicated in BackingStoreFactoryRegistry
2014-10-10T11:39:54.982+0200|Info: Grizzly Framework 2.3.15 started in: 140ms - bound to [/0.0.0.0:8080]
2014-10-10T11:39:55.107+0200|Info: Grizzly Framework 2.3.15 started in: 0ms - bound to [/0.0.0.0:8181]
2014-10-10T11:39:55.107+0200|Info: Grizzly Framework 2.3.15 started in: 0ms - bound to [/0.0.0.0:4848]
2014-10-10T11:39:55.138+0200|Info: Grizzly Framework 2.3.15 started in: 0ms - bound to [/0.0.0.0:3700]
2014-10-10T11:39:55.138+0200|Info: GlassFish Server Open Source Edition 4.1 (13) startup time : Felix (1,401ms), startup services(640ms), total(2,041ms)
2014-10-10T11:39:55.295+0200|Info: JMXStartupService has started JMXConnector on JMXService URL service:jmx:rmi://192.168.0.253:8686/jndi/rmi://192.168.0.253:8686/jmxrmi
2014-10-10T11:39:56.493+0200|Info: Initiating Jersey application, version Jersey: 2.10.4 2014-08-08 15:09:00...
2014-10-10T11:39:56.571+0200|Info: HV000001: Hibernate Validator 5.0.0.Final
2014-10-10T11:39:57.071+0200|Info: Listening to REST requests at context: /management/domain.
2014-10-10T11:39:57.149+0200|Info: Registered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl@2d6aca33 as OSGi service registration: org.apache.felix.framework.ServiceRegistrationImpl@6edaa77a.
2014-10-10T11:39:57.383+0200|Info: visiting unvisited references
2014-10-10T11:39:57.680+0200|Info: Created HTTP listener http-listener-1 on host/port 0.0.0.0:8080
2014-10-10T11:39:57.680+0200|Info: Created HTTP listener http-listener-2 on host/port 0.0.0.0:8181
2014-10-10T11:39:57.696+0200|Info: Created HTTP listener admin-listener on host/port 0.0.0.0:4848
2014-10-10T11:39:57.711+0200|Info: Created virtual server server
2014-10-10T11:39:57.711+0200|Info: Created virtual server __asadmin
2014-10-10T11:39:57.836+0200|Info: Setting JAAS app name glassfish-web
2014-10-10T11:39:57.852+0200|Info: Virtual server server loaded default web module
2014-10-10T11:39:58.039+0200|Info: Java security manager is disabled.
2014-10-10T11:39:58.039+0200|Info: Entering Security Startup Service.
2014-10-10T11:39:58.039+0200|Info: Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.
2014-10-10T11:39:58.071+0200|Info: Security Service(s) started successfully.
2014-10-10T11:39:58.258+0200|Info: visiting unvisited references
2014-10-10T11:39:58.274+0200|Info: visiting unvisited references
2014-10-10T11:39:58.274+0200|Info: visiting unvisited references
2014-10-10T11:39:59.102+0200|Info: Initializing Mojarra 2.2.7 ( 20140610-1547 https://svn.java.net/svn/mojarra~svn/tags/2.2.7@13362) for context ''
2014-10-10T11:40:00.336+0200|Info: Loading application [__admingui] at [/]
2014-10-10T11:40:00.336+0200|Info: Loading application __admingui done in 3,187 ms
2014-10-10T11:40:00.727+0200|Info: visiting unvisited references
2014-10-10T11:40:00.961+0200|Info: visiting unvisited references
2014-10-10T11:40:01.071+0200|Info: visiting unvisited references
2014-10-10T11:40:01.086+0200|Info: visiting unvisited references
2014-10-10T11:40:01.086+0200|Info: visiting unvisited references
2014-10-10T11:40:01.086+0200|Info: visiting unvisited references
2014-10-10T11:40:01.086+0200|Info: visiting unvisited references
2014-10-10T11:40:01.086+0200|Info: visiting unvisited references
2014-10-10T11:40:01.086+0200|Info: visiting unvisited references
2014-10-10T11:40:01.196+0200|Info: visiting unvisited references
2014-10-10T11:40:01.352+0200|Info: visiting unvisited references
2014-10-10T11:40:02.023+0200|Info: EclipseLink, version: Eclipse Persistence Services - 2.5.2.v20140319-9ad6abd
2014-10-10T11:40:02.314+0200|Info: file:/C:/Users/Jens/Programs/Glassfish/glassfish_4.1/glassfish/domains/domain1/eclipseApps/SeshatWAR/WEB-INF/classes/_seshat_pu login successful
2014-10-10T11:40:02.376+0200|Info: Portable JNDI names for EJB TestManager: [java:global/SeshatWAR/TestManager!com.codemint.seshat.test.TestManager, java:global/SeshatWAR/TestManager]
2014-10-10T11:40:02.407+0200|Info: Portable JNDI names for EJB UserStore: [java:global/SeshatWAR/UserStore!com.codemint.seshat.service.UserStore, java:global/SeshatWAR/UserStore]
2014-10-10T11:40:02.423+0200|Info: Portable JNDI names for EJB TimeStoreImpl: [java:global/SeshatWAR/TimeStoreImpl!com.codemint.seshat.service.TimeStore, java:global/SeshatWAR/TimeStoreImpl!com.codemint.seshat.service.TimeStoreImpl]
2014-10-10T11:40:02.423+0200|Info: Portable JNDI names for EJB ProjectFacade: [java:global/SeshatWAR/ProjectFacade!com.codemint.seshat.service.ProjectFacade, java:global/SeshatWAR/ProjectFacade]
2014-10-10T11:40:02.439+0200|Info: WELD-000900: 2.2.2 (Final)
2014-10-10T11:40:02.657+0200|WARN: WELD-001700: Interceptor annotation class javax.ejb.PostActivate not found, interception based on it is not enabled
2014-10-10T11:40:02.657+0200|WARN: WELD-001700: Interceptor annotation class javax.ejb.PrePassivate not found, interception based on it is not enabled
2014-10-10T11:40:02.736+0200|WARN: WELD-000411: Observer method [BackedAnnotatedMethod] org.glassfish.sse.impl.ServerSentEventCdiExtension.processAnnotatedType(@Observes ProcessAnnotatedType<Object>, BeanManager) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
2014-10-10T11:40:02.751+0200|WARN: WELD-000411: Observer method [BackedAnnotatedMethod] private org.glassfish.jersey.gf.cdi.internal.CdiComponentProvider.processAnnotatedType(@Observes ProcessAnnotatedType<Object>) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
2014-10-10T11:40:02.845+0200|Info: WELD-000119: Not generating any bean definitions from com.codemint.seshat.backing.TimeTable because of underlying class loading error: Type [unknown] not found. If this is unexpected, enable DEBUG logging to see the full error.
2014-10-10T11:40:02.861+0200|Info: WELD-000119: Not generating any bean definitions from com.codemint.seshat.test.TestData because of underlying class loading error: Type [unknown] not found. If this is unexpected, enable DEBUG logging to see the full error.
2014-10-10T11:40:02.876+0200|Severe: Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: CDI deployment failure:null
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:234)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:496)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandlerBase.service(StaticHttpHandlerBase.java:189)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
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:745)
Caused by: java.lang.NullPointerException
at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:191)
at com.google.common.cache.LocalCache.get(LocalCache.java:3989)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3994)
at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4878)
at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:49)
at org.jboss.weld.resources.SharedObjectCache.getTypeClosureHolder(SharedObjectCache.java:80)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedMember.initTypeClosure(BackedAnnotatedMember.java:29)
at org.jboss.weld.annotated.slim.backed.BackedAnnotated.<init>(BackedAnnotated.java:19)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedMember.<init>(BackedAnnotatedMember.java:23)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedCallable.<init>(BackedAnnotatedCallable.java:33)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedMethod.<init>(BackedAnnotatedMethod.java:38)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedMethod.of(BackedAnnotatedMethod.java:32)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.computeValue(BackedAnnotatedType.java:193)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.computeValue(BackedAnnotatedType.java:186)
at org.jboss.weld.util.LazyValueHolder.get(LazyValueHolder.java:35)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$EagerlyInitializedLazyValueHolder.<init>(BackedAnnotatedType.java:154)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.<init>(BackedAnnotatedType.java:186)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.<init>(BackedAnnotatedType.java:186)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType.<init>(BackedAnnotatedType.java:66)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType.of(BackedAnnotatedType.java:47)
at org.jboss.weld.resources.ClassTransformer$TransformClassToBackedAnnotatedType.load(ClassTransformer.java:83)
at org.jboss.weld.resources.ClassTransformer$TransformClassToBackedAnnotatedType.load(ClassTransformer.java:80)
at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3589)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2374)
at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2337)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2252)
at com.google.common.cache.LocalCache.get(LocalCache.java:3990)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3994)
at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4878)
at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:49)
at org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:74)
at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:175)
at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:194)
at org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadAnnotatedType(AnnotatedTypeLoader.java:78)
at org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadAnnotatedType(AnnotatedTypeLoader.java:60)
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:97)
at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:135)
at org.jboss.weld.bootstrap.BeanDeployment.createClasses(BeanDeployment.java:209)
at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:351)
at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:220)
... 41 more

2014-10-10T11:40:02.876+0200|Severe: Exception while loading the app
2014-10-10T11:40:02.876+0200|Severe: Undeployment failed for context /SeshatWAR
2014-10-10T11:40:02.876+0200|Info: file:/C:/Users/Jens/Programs/Glassfish/glassfish_4.1/glassfish/domains/domain1/eclipseApps/SeshatWAR/WEB-INF/classes/_seshat_pu logout successful
2014-10-10T11:40:02.876+0200|Severe: Exception while loading the app : CDI deployment failure:null
java.lang.NullPointerException
at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:191)
at com.google.common.cache.LocalCache.get(LocalCache.java:3989)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3994)
at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4878)
at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:49)
at org.jboss.weld.resources.SharedObjectCache.getTypeClosureHolder(SharedObjectCache.java:80)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedMember.initTypeClosure(BackedAnnotatedMember.java:29)
at org.jboss.weld.annotated.slim.backed.BackedAnnotated.<init>(BackedAnnotated.java:19)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedMember.<init>(BackedAnnotatedMember.java:23)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedCallable.<init>(BackedAnnotatedCallable.java:33)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedMethod.<init>(BackedAnnotatedMethod.java:38)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedMethod.of(BackedAnnotatedMethod.java:32)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.computeValue(BackedAnnotatedType.java:193)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.computeValue(BackedAnnotatedType.java:186)
at org.jboss.weld.util.LazyValueHolder.get(LazyValueHolder.java:35)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$EagerlyInitializedLazyValueHolder.<init>(BackedAnnotatedType.java:154)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.<init>(BackedAnnotatedType.java:186)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.<init>(BackedAnnotatedType.java:186)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType.<init>(BackedAnnotatedType.java:66)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType.of(BackedAnnotatedType.java:47)
at org.jboss.weld.resources.ClassTransformer$TransformClassToBackedAnnotatedType.load(ClassTransformer.java:83)
at org.jboss.weld.resources.ClassTransformer$TransformClassToBackedAnnotatedType.load(ClassTransformer.java:80)
at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3589)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2374)
at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2337)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2252)
at com.google.common.cache.LocalCache.get(LocalCache.java:3990)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3994)
at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4878)
at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:49)
at org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:74)
at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:175)
at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:194)
at org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadAnnotatedType(AnnotatedTypeLoader.java:78)
at org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadAnnotatedType(AnnotatedTypeLoader.java:60)
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:97)
at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:135)
at org.jboss.weld.bootstrap.BeanDeployment.createClasses(BeanDeployment.java:209)
at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:351)
at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:220)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:496)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandlerBase.service(StaticHttpHandlerBase.java:189)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
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:745)



 Comments   
Comment by jjsnyder83 [ 11/May/15 ]

Can you please retry this on the latest GlassFish trunk? We recently updated the version of Weld to 2.2.10.SP1 and I'm hoping it's fixed there.





[GLASSFISH-21347] Undeploy shows successful messages, but application is still as deployed Created: 10/Apr/15  Updated: 30/Jun/15

Status: In Progress
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1.2.2
Fix Version/s: None

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

Solaris 10 x86
GlassFish Server Open Source Edition 3.1.2.2 (build 5)



 Description   

The application is still shown after asadmin undeploy run successfully:

#/opt/glassfish3/glassfish/bin/asadmin --port 50500 --user admin --host masterservice undeploy pss
Enter admin password for user "admin">
Command undeploy executed successfully.

  1. /opt/glassfish3/glassfish/bin/asadmin --port 50500 --user admin --host masterservice list-applications
    Enter admin password for user "admin">
    RestCM-ear-1.1.1 <ear, ejb, web>
    SoapAuthorityService <ear, ejb>
    SoapNotificationIRP <ear, ejb, webservices>
    SoapBulkCMIRP <ear, ejb, webservices>
    SoapBasicCMIRP <ear, ejb, webservices>
    pms_compApplication <ejb, webservices>
    nms_shm <ear, ejb, web, connector>
    pmTrace_WebServices <ejb, webservices>
    pss <ear, web, ejb>
    com.ericsson.oss.common.alarm.manager.webapp <web>
    Command list-applications executed successfully.

===================================================
However, the application directory has been removed by the command from "./domains/domain1/applications" and "./domains/domain1/applications/__internal" directories..



 Comments   
Comment by enoefay [ 17/Apr/15 ]

Hi Hong,

Is there any update on this issue ..? What's the latest analysis ..?

Kind Regards,
Noel

Comment by Vinay Vishal [ 30/Jun/15 ]

Hi,

This issue couldn't be reproduced.

output:

bash-3.2$ cat /etc/release
Oracle Solaris 10 8/11 s10x_u10wos_17b X86
Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved.
Assembled 23 August 2011
bash-3.2$ cd glassfish3/glassfish/bin/
bash-3.2$ ./asadmin deploy /home/vivishal/sample.war
Enter admin user name> admin
Enter admin password for user "admin">
Application deployed with name sample.
Command deploy executed successfully.
bash-3.2$ ./asadmin list-applications
Enter admin user name> admin
Enter admin password for user "admin">
sample <web>
Command list-applications executed successfully.
bash-3.2$ ./asadmin undeploy sample
Enter admin user name> admin
Enter admin password for user "admin">
Command undeploy executed successfully.
bash-3.2$ ./asadmin list-applications
Enter admin user name> admin
Enter admin password for user "admin">
Nothing to list.
Command list-applications executed successfully.

Can you please confirm if this issue still exists? If so, can you please share a sample file with which you are able to reproduce the issue?





[GLASSFISH-20865] Deployment error, it seams there are 2 EJB implementing the same business interface Created: 20/Oct/13  Updated: 09/Nov/13

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

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


 Description   

I created an enterprise app with an ejb module, client app and web module.
Besides I put all interfaces in a common module that all other module depends on.
Then the app is very simple but GF have still problems ...

My ejb ( in ejb module ):

@Local(HBServiceLocal.class)
@Stateless
public class HBTestBean implements HBServiceLocal {

@Override
public String echo(final String parameter)

{ return "Echo "+parameter; }

// Add business logic below. (Right-click in editor and choose
// "Insert Code > Add Business Method")

}

The interface ( in common module) :

public interface HBServiceLocal extends HBService{

String echo(final String parameter);

}

And the error message :
Avvertenza: AS-DEPLOYMENT-00001
Grave: Eccezione durante la distribuzione dell'applicazione [HomeBankNB]
Grave: Exception during lifecycle processing
java.lang.IllegalArgumentException: Impossibile risolvere il riferimento [Remote ejb-ref name=homebankappclient.Main/bean,Remote 3.x interface =org.savino.hb.common.business.service.HBServiceLocal,ejb-link=null,lookup=,mappedName=,jndi-name=,refType=Session] perché sono presenti [2] EJB nell'applicazione con l'interfaccia org.savino.hb.common.business.service.HBServiceLocal.
Di seguito sono riportate alcune delle cause possibili.
1. The EJB bean class has been included in the package of a library LIB EAR (or by another library mechanism that makes the library visible to all modules of the components). Therefore all the modules of the components indirectly include this bean class.
2. The EJB bean class has been included in the package of a component module that refers EJB, directly or indirectly through the manifest file, WEB-INF/lib.
The EJB bean class must be included only in a package the EJB module declaration and not in the forms of reference. The reference modules must only include EJB interfaces.
at com.sun.enterprise.deployment.util.ComponentValidator.accept(ComponentValidator.java:356)
at com.sun.enterprise.deployment.util.DefaultDOLVisitor.accept(DefaultDOLVisitor.java:78)
at com.sun.enterprise.deployment.util.ComponentValidator.accept(ComponentValidator.java:123)
at com.sun.enterprise.deployment.util.ApplicationValidator.accept(ApplicationValidator.java:147)
at com.sun.enterprise.deployment.util.AppClientValidator.accept(AppClientValidator.java:67)
at com.sun.enterprise.deployment.BundleDescriptor.visit(BundleDescriptor.java:621)
at com.sun.enterprise.deployment.ApplicationClientDescriptor.visit(ApplicationClientDescriptor.java:623)
at com.sun.enterprise.deployment.util.ApplicationValidator.accept(ApplicationValidator.java:135)
at com.sun.enterprise.deployment.BundleDescriptor.visit(BundleDescriptor.java:621)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.validate(ApplicationArchivist.java:703)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:248)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:232)
at org.glassfish.javaee.core.deployment.DolProvider.processDOL(DolProvider.java:188)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:222)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:96)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:878)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:818)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:374)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:724)



 Comments   
Comment by Jeremy_Lv [ 21/Oct/13 ]

Hi, kronos72it:

Could you please upload your reproduced application to somewhere so that I can download it and reproduced this phenomenon on my local platform?

Anyway, I think the error won't be thrown out if you moved the interface HBServiceLocal to the EJB module instead of common module.

thanks

Comment by kronos72it [ 09/Nov/13 ]

Hi Jeremy , I re generate my Aplication and now it seams work with both 2 interface, I am testing my application and will give you a feedback.
Anyway a I'd like to have both interface in my shared library as I can share the interfaces with all projects and publish them to the world...





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

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

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


 Description   

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

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

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

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

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



 Comments   
Comment by Sanjeeb Sahoo [ 27/Mar/13 ]

Too late to fix in 4.0





[GLASSFISH-19530] javax/servlet/jsp/JspFactory javax/el/BeanELResolver are required for deployment for glassfish-jes Created: 14/Jan/13  Updated: 18/Jan/13

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

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


 Description   

Removing jsp/el from glassfish-jes to reduce its size results in these exceptions

[glassfish-embedded-deploy] Jan 14, 2013 5:44:06 PM com.sun.enterprise.v3.server.ApplicationLifecycle deploy
[glassfish-embedded-deploy] SEVERE: Exception during lifecycle processing
[glassfish-embedded-deploy] MultiException stack 1 of 1
[glassfish-embedded-deploy] java.lang.NoClassDefFoundError: javax/servlet/jsp/JspFactory
[glassfish-embedded-deploy] at java.lang.Class.getDeclaredConstructors0(Native Method)
[glassfish-embedded-deploy] at java.lang.Class.privateGetDeclaredConstructors(Class.java:2404)
[glassfish-embedded-deploy] at java.lang.Class.getDeclaredConstructors(Class.java:1853)
[glassfish-embedded-deploy] at org.jvnet.hk2.internal.Utilities.getAllConstructorKeys(Utilities.java:957)
[glassfish-embedded-deploy] at org.jvnet.hk2.internal.Utilities.getAllConstructors(Utilities.java:943)
[glassfish-embedded-deploy] at org.jvnet.hk2.internal.Utilities.findProducerConstructor(Utilities.java:862)
[glassfish-embedded-deploy] at org.jvnet.hk2.internal.ClazzCreator.<init>(ClazzCreator.java:93)
[glassfish-embedded-deploy] at org.jvnet.hk2.internal.SystemDescriptor.reify(SystemDescriptor.java:574)
[glassfish-embedded-deploy] at org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:361)
[glassfish-embedded-deploy] at org.jvnet.hk2.internal.ServiceLocatorImpl.narrow(ServiceLocatorImpl.java:1562)
[glassfish-embedded-deploy] at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetDescriptor(ServiceLocatorImpl.java:779)
[glassfish-embedded-deploy] at org.jvnet.hk2.internal.ServiceLocatorImpl.getServiceHandle(ServiceLocatorImpl.java:1025)
[glassfish-embedded-deploy] at org.jvnet.hk2.internal.ServiceLocatorImpl.getServiceHandle(ServiceLocatorImpl.java:1014)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.server.ContainerStarter.startContainer(ContainerStarter.java:112)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainer(ApplicationLifecycle.java:994)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:699)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:374)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
[glassfish-embedded-deploy] at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:490)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:561)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:557)
[glassfish-embedded-deploy] at java.security.AccessController.doPrivileged(Native Method)
[glassfish-embedded-deploy] at javax.security.auth.Subject.doAs(Subject.java:356)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:556)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:580)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1455)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1400(CommandRunnerImpl.java:108)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1782)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1712)
[glassfish-embedded-deploy] at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:129)
[glassfish-embedded-deploy] at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:105)
[glassfish-embedded-deploy] at org.glassfish.ant.embedded.tasks.Util.deploy(Util.java:114)
[glassfish-embedded-deploy] at org.glassfish.ant.embedded.tasks.DeployTask.execute(DeployTask.java:130)
[glassfish-embedded-deploy] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[glassfish-embedded-deploy] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[glassfish-embedded-deploy] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[glassfish-embedded-deploy] at java.lang.reflect.Method.invoke(Method.java:601)
[glassfish-embedded-deploy] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
[glassfish-embedded-deploy] at org.apache.tools.ant.Task.perform(Task.java:348)
[glassfish-embedded-deploy] at org.apache.tools.ant.Target.execute(Target.java:357)
[glassfish-embedded-deploy] at org.apache.tools.ant.Target.performTasks(Target.java:385)
[glassfish-embedded-deploy] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
[glassfish-embedded-deploy] at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
[glassfish-embedded-deploy] at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
[glassfish-embedded-deploy] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:416)
[glassfish-embedded-deploy] at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
[glassfish-embedded-deploy] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[glassfish-embedded-deploy] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[glassfish-embedded-deploy] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[glassfish-embedded-deploy] at java.lang.reflect.Method.invoke(Method.java:601)
[glassfish-embedded-deploy] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
[glassfish-embedded-deploy] at org.apache.tools.ant.Task.perform(Task.java:348)
[glassfish-embedded-deploy] at org.apache.tools.ant.Target.execute(Target.java:357)
[glassfish-embedded-deploy] at org.apache.tools.ant.Target.performTasks(Target.java:385)
[glassfish-embedded-deploy] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
[glassfish-embedded-deploy] at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
[glassfish-embedded-deploy] at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
[glassfish-embedded-deploy] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:416)
[glassfish-embedded-deploy] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[glassfish-embedded-deploy] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[glassfish-embedded-deploy] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[glassfish-embedded-deploy] at java.lang.reflect.Method.invoke(Method.java:601)
[glassfish-embedded-deploy] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
[glassfish-embedded-deploy] at org.apache.tools.ant.Task.perform(Task.java:348)
[glassfish-embedded-deploy] at org.apache.tools.ant.Target.execute(Target.java:357)
[glassfish-embedded-deploy] at org.apache.tools.ant.Target.performTasks(Target.java:385)
[glassfish-embedded-deploy] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
[glassfish-embedded-deploy] at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
[glassfish-embedded-deploy] at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
[glassfish-embedded-deploy] at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
[glassfish-embedded-deploy] at org.apache.tools.ant.Main.runBuild(Main.java:698)
[glassfish-embedded-deploy] at org.apache.tools.ant.Main.startAnt(Main.java:199)
[glassfish-embedded-deploy] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
[glassfish-embedded-deploy] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
[glassfish-embedded-deploy] Caused by: java.lang.ClassNotFoundException: javax.servlet.jsp.JspFactory
[glassfish-embedded-deploy] at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
[glassfish-embedded-deploy] at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
[glassfish-embedded-deploy] at java.security.AccessController.doPrivileged(Native Method)
[glassfish-embedded-deploy] at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
[glassfish-embedded-deploy] at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
[glassfish-embedded-deploy] at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
[glassfish-embedded-deploy] ... 74 more
[glassfish-embedded-deploy]
[glassfish-embedded-deploy] Jan 14, 2013 5:44:06 PM org.glassfish.deployment.admin.DeployCommand execute
[glassfish-embedded-deploy] SEVERE: javax/el/BeanELResolver
[glassfish-embedded-deploy] java.lang.ClassNotFoundException: javax.el.BeanELResolver
[glassfish-embedded-deploy] at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
[glassfish-embedded-deploy] at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
[glassfish-embedded-deploy] at java.security.AccessController.doPrivileged(Native Method)
[glassfish-embedded-deploy] at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
[glassfish-embedded-deploy] at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
[glassfish-embedded-deploy] at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
[glassfish-embedded-deploy] at org.glassfish.web.loader.WebappClassLoader.purgeELBeanClasses(WebappClassLoader.java:3313)
[glassfish-embedded-deploy] at org.glassfish.web.loader.WebappClassLoader.stop(WebappClassLoader.java:1872)
[glassfish-embedded-deploy] at org.glassfish.web.loader.WebappClassLoader.preDestroy(WebappClassLoader.java:1854)
[glassfish-embedded-deploy] at org.glassfish.deployment.common.DeploymentContextImpl.preDestroy(DeploymentContextImpl.java:165)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.server.ApplicationLifecycle$2.actOn(ApplicationLifecycle.java:274)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:517)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
[glassfish-embedded-deploy] at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:490)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:561)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:557)
[glassfish-embedded-deploy] at java.security.AccessController.doPrivileged(Native Method)
[glassfish-embedded-deploy] at javax.security.auth.Subject.doAs(Subject.java:356)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:556)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:580)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1455)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1400(CommandRunnerImpl.java:108)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1782)
[glassfish-embedded-deploy] at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1712)
[glassfish-embedded-deploy] at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:129)
[glassfish-embedded-deploy] at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:105)
[glassfish-embedded-deploy] at org.glassfish.ant.embedded.tasks.Util.deploy(Util.java:114)
[glassfish-embedded-deploy] at org.glassfish.ant.embedded.tasks.DeployTask.execute(DeployTask.java:130)
[glassfish-embedded-deploy] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[glassfish-embedded-deploy] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[glassfish-embedded-deploy] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[glassfish-embedded-deploy] at java.lang.reflect.Method.invoke(Method.java:601)
[glassfish-embedded-deploy] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
[glassfish-embedded-deploy] at org.apache.tools.ant.Task.perform(Task.java:348)
[glassfish-embedded-deploy] at org.apache.tools.ant.Target.execute(Target.java:357)
[glassfish-embedded-deploy] at org.apache.tools.ant.Target.performTasks(Target.java:385)
[glassfish-embedded-deploy] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
[glassfish-embedded-deploy] at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
[glassfish-embedded-deploy] at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
[glassfish-embedded-deploy] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:416)
[glassfish-embedded-deploy] at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
[glassfish-embedded-deploy] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[glassfish-embedded-deploy] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[glassfish-embedded-deploy] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[glassfish-embedded-deploy] at java.lang.reflect.Method.invoke(Method.java:601)
[glassfish-embedded-deploy] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
[glassfish-embedded-deploy] at org.apache.tools.ant.Task.perform(Task.java:348)
[glassfish-embedded-deploy] at org.apache.tools.ant.Target.execute(Target.java:357)
[glassfish-embedded-deploy] at org.apache.tools.ant.Target.performTasks(Target.java:385)
[glassfish-embedded-deploy] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
[glassfish-embedded-deploy] at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
[glassfish-embedded-deploy] at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
[glassfish-embedded-deploy] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:416)
[glassfish-embedded-deploy] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[glassfish-embedded-deploy] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[glassfish-embedded-deploy] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[glassfish-embedded-deploy] at java.lang.reflect.Method.invoke(Method.java:601)
[glassfish-embedded-deploy] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
[glassfish-embedded-deploy] at org.apache.tools.ant.Task.perform(Task.java:348)
[glassfish-embedded-deploy] at org.apache.tools.ant.Target.execute(Target.java:357)
[glassfish-embedded-deploy] at org.apache.tools.ant.Target.performTasks(Target.java:385)
[glassfish-embedded-deploy] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
[glassfish-embedded-deploy] at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
[glassfish-embedded-deploy] at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
[glassfish-embedded-deploy] at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
[glassfish-embedded-deploy] at org.apache.tools.ant.Main.runBuild(Main.java:698)
[glassfish-embedded-deploy] at org.apache.tools.ant.Main.startAnt(Main.java:199)
[glassfish-embedded-deploy] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
[glassfish-embedded-deploy] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)






[GLASSFISH-20743] Error while upgrading an application on glassfish3.1.2.2 Created: 06/Aug/13  Updated: 08/Aug/13

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

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


 Description   

Hi

While upgrading the application(pss) on glassfish server i have seen exception like this

22T14:40:52.854+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=39;_ThreadName=Thread-2;|Exception while loading the app : Error in linking security policy for pss – Inconsistent Module State|#]

Log Trace:

[#|2013-07-22T14:40:09.430+0100|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.com.sun.enterprise.container.common|_ThreadID=40;_ThreadName=Thread-2;|User [admin] from host atrcxb1345 does not have administration access|#]

[#|2013-07-22T14:40:09.459+0100|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.com.sun.enterprise.container.common|_ThreadID=39;_ThreadName=Thread-2;|User [admin] from host atrcxb1345 does not have administration access|#]

[#|2013-07-22T14:40:09.472+0100|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.com.sun.enterprise.container.common|_ThreadID=37;_ThreadName=Thread-2;|User [admin] from host atrcxb1345 does not have administration access|#]

[#|2013-07-22T14:40:24.552+0100|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.com.sun.enterprise.container.common|_ThreadID=36;_ThreadName=Thread-2;|User [admin] from host atrcxb1345 does not have administration access|#]

[#|2013-07-22T14:40:24.582+0100|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.com.sun.enterprise.container.common|_ThreadID=37;_ThreadName=Thread-2;|User [admin] from host atrcxb1345 does not have administration access|#]

[#|2013-07-22T14:40:47.622+0100|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.com.sun.enterprise.container.common|_ThreadID=37;_ThreadName=Thread-2;|User [admin] from host atrcxb1345 does not have administration access|#]

[#|2013-07-22T14:40:47.654+0100|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.com.sun.enterprise.container.common|_ThreadID=40;_ThreadName=Thread-2;|User [admin] from host atrcxb1345 does not have administration access|#]

[#|2013-07-22T14:40:52.671+0100|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=39;_ThreadName=Thread-2;|EJB5181:Portable JNDI names for EJB NotifBroker: [java:global/pss/pss-ejb/NotifBroker!se.ericsson.security.pss.webservice.NotifBroker, java:global/pss/pss-ejb/NotifBroker]|#]

[#|2013-07-22T14:40:52.689+0100|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=39;_ThreadName=Thread-2;|EJB5181:Portable JNDI names for EJB NotificationHandler: [java:global/pss/pss-ejb/NotificationHandler!com.ericsson.oss.utilities.cifadaptation.notification.IMoEventHandler, java:global/pss/pss-ejb/NotificationHandler!com.ericsson.oss.utilities.cifadaptation.notification.IAttributeChangeHandler]|#]

[#|2013-07-22T14:40:52.719+0100|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=39;_ThreadName=Thread-2;|EJB5181:Portable JNDI names for EJB CsData: [java:global/pss/pss-ejb/CsData, java:global/pss/pss-ejb/CsData!se.ericsson.security.pss.webservice.api.CsDataSource]|#]

[#|2013-07-22T14:40:52.757+0100|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers.builder|_ThreadID=39;_ThreadName=Thread-2;|TopLevel AvailabilityService.getAvailabilityEnabled => true|#]

[#|2013-07-22T14:40:52.757+0100|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers.builder|_ThreadID=39;_ThreadName=Thread-2;|TopLevel EjbAvailabilityService.getAvailabilityEnabled => true|#]

[#|2013-07-22T14:40:52.758+0100|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers.builder|_ThreadID=39;_ThreadName=Thread-2;|**Global AvailabilityEnabled => true; isAppHAEnabled: false|#]

[#|2013-07-22T14:40:52.758+0100|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers.builder|_ThreadID=39;_ThreadName=Thread-2;|StatefulContainerBuilder AvailabilityEnabled for this app => false|#]

[#|2013-07-22T14:40:52.759+0100|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers.builder|_ThreadID=39;_ThreadName=Thread-2;|StatefulContainerBuilder.buildStoreManager() storeName: certm.CertM-90079117418823685-BackingStore|#]

[#|2013-07-22T14:40:52.760+0100|INFO|glassfish3.1.2|org.glassfish.ha.store.adapter.file.FileBackingStore|_ThreadID=39;_ThreadName=Thread-2;|[FileBackingStore::initialize] Successfully Created and initialized store. Working dir: /opt/glassfish3/glassfish/domains/domain1/session-store/certm.CertM-90079117418823685; Configuration: BackingStoreConfiguration{clusterName='null', instanceName='null', storeName='certm.CertM-90079117418823685-BackingStore', shortUniqueName='90079117418823685', storeType='file', maxIdleTimeInSeconds=-1, relaxVersionCheck='null', maxLoadWaitTimeInSeconds=0, baseDirectoryName='/opt/glassfish3/glassfish/domains/domain1/session-store/certm.CertM-90079117418823685', keyClazz=interface java.io.Serializable, valueClazz=class org.glassfish.ha.store.util.SimpleMetadata, synchronousSave=false, typicalPayloadSizeInKiloBytes=0, vendorSpecificSettings={start.gms=false, async.replication=true, key.transformer=com.sun.ejb.base.sfsb.util.SimpleKeyGenerator@18671cd, local.caching=true, value.class.is.thread.safe=true, broadcast.remove.expired=false}}|#]

[#|2013-07-22T14:40:52.760+0100|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers.builder|_ThreadID=39;_ThreadName=Thread-2;|StatefulContainerbuilder instantiated store: org.glassfish.ha.store.adapter.file.FileBackingStore@1998709; ha-enabled: false ==> BackingStoreConfiguration{clusterName='null', instanceName='null', storeName='certm.CertM-90079117418823685-BackingStore', shortUniqueName='90079117418823685', storeType='file', maxIdleTimeInSeconds=-1, relaxVersionCheck='null', maxLoadWaitTimeInSeconds=0, baseDirectoryName='/opt/glassfish3/glassfish/domains/domain1/session-store/certm.CertM-90079117418823685', keyClazz=interface java.io.Serializable, valueClazz=class org.glassfish.ha.store.util.SimpleMetadata, synchronousSave=false, typicalPayloadSizeInKiloBytes=0, vendorSpecificSettings={start.gms=false, async.replication=true, key.transformer=com.sun.ejb.base.sfsb.util.SimpleKeyGenerator@18671cd, local.caching=true, value.class.is.thread.safe=true, broadcast.remove.expired=false}}|#]

[#|2013-07-22T14:40:52.764+0100|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=39;_ThreadName=Thread-2;|EJB5181:Portable JNDI names for EJB certm.CertM: [java:global/pss/pss-ejb/certm.CertM!se.ericsson.security.pss.webservice.api.certm.ICertM, java:global/pss/pss-ejb/certm.CertM]|#]

[#|2013-07-22T14:40:52.786+0100|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=39;_ThreadName=Thread-2;|EJB5181:Portable JNDI names for EJB PwService: [java:global/pss/pss-ejb/PwService!se.ericsson.security.pss.webservice.PwService, java:global/pss/pss-ejb/PwService]|#]

[#|2013-07-22T14:40:52.808+0100|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=39;_ThreadName=Thread-2;|EJB5181:Portable JNDI names for EJB WranCM: [java:global/pss/pss-ejb/WranCM, java:global/pss/pss-ejb/WranCM!se.ericsson.security.pss.webservice.WranCM]|#]

[#|2013-07-22T14:40:52.826+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=39;_ThreadName=Thread-2;|Exception while loading the app|#]

[#|2013-07-22T14:40:52.854+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=39;_ThreadName=Thread-2;|Exception while loading the app : Error in linking security policy for pss -- Inconsistent Module State|#]

[#|2013-07-22T14:40:52.861+0100|WARNING|glassfish3.1.2|javax.enterprise.system.core.classloading.com.sun.enterprise.loader|_ThreadID=41;_ThreadName=Thread-2;|LDR5207: ASURLClassLoader EarLibClassLoader :
doneCalled = true
doneSnapshot = ASURLClassLoader.done() called ON EarLibClassLoader :
urlSet = []
doneCalled = false
Parent -> org.glassfish.internal.api.DelegatingClassLoader@1d90d9

AT Mon Jul 22 14:40:52 IST 2013
BY :java.lang.Throwable: printStackTraceToString
at com.sun.enterprise.util.Print.printStackTraceToString(Print.java:639)
at com.sun.enterprise.loader.ASURLClassLoader.done(ASURLClassLoader.java:211)
at com.sun.enterprise.loader.ASURLClassLoader.preDestroy(ASURLClassLoader.java:179)
at org.glassfish.javaee.full.deployment.EarClassLoader.preDestroy(EarClassLoader.java:114)
at org.glassfish.deployment.common.DeploymentContextImpl.preDestroy(DeploymentContextImpl.java:151)
at com.sun.enterprise.v3.server.ApplicationLifecycle$1.actOn(ApplicationLifecycle.java:281)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:465)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Parent -> org.glassfish.internal.api.DelegatingClassLoader@1d90d9
was requested to find class com.sun.jndi.url._internal_java_app_for_app_clientpssjava.internal_java_app_for_app_clientpss_javaURLContextFactory after done was invoked from the following stack trace
java.lang.Throwable
at com.sun.enterprise.loader.ASURLClassLoader.findClassData(ASURLClassLoader.java:780)
at com.sun.enterprise.loader.ASURLClassLoader.findClass(ASURLClassLoader.java:696)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at com.sun.naming.internal.VersionHelper12.loadClass(VersionHelper12.java:54)
at com.sun.naming.internal.ResourceManager.getFactory(ResourceManager.java:371)
at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:575)
at javax.naming.spi.NamingManager.getURLContext(NamingManager.java:533)
at com.sun.enterprise.naming.impl.WrappedSerialContext.getURLOrDefaultInitCtx(WrappedSerialContext.java:106)
at javax.naming.InitialContext.unbind(InitialContext.java:416)
at javax.naming.InitialContext.unbind(InitialContext.java:416)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.unpublishObject(GlassfishNamingManagerImpl.java:246)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.unbindAppScopedNameForAppclient(ResourceNamingService.java:191)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.unpublishObject(ResourceNamingService.java:182)
at com.sun.enterprise.resource.deployer.CustomResourceDeployer.deleteResource(CustomResourceDeployer.java:166)
at com.sun.enterprise.resource.deployer.CustomResourceDeployer.undeployResource(CustomResourceDeployer.java:146)
at com.sun.enterprise.connectors.module.ResourcesDeployer.undeployResources(ResourcesDeployer.java:977)
at com.sun.enterprise.connectors.module.ResourcesDeployer.cleanupResources(ResourcesDeployer.java:946)
at com.sun.enterprise.connectors.module.ResourcesDeployer.event(ResourcesDeployer.java:760)
at org.glassfish.kernel.event.EventsImpl$1.run(EventsImpl.java:120)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

#]

[#|2013-07-22T14:40:52.863+0100|WARNING|glassfish3.1.2|javax.enterprise.system.core.classloading.com.sun.enterprise.loader|_ThreadID=41;_ThreadName=Thread-2;|LDR5207: ASURLClassLoader EarClassLoader :
doneCalled = true
doneSnapshot = ASURLClassLoader.done() called ON EarClassLoader :
urlSet = [URLEntry : file:/opt/glassfish3/glassfish/domains/domain1/applications/pss/pss-ejb_jar/, URLEntry : file:/opt/glassfish3/glassfish/domains/domain1/generated/ejb/pss/pss-ejb_jar]
doneCalled = false
Parent -> org.glassfish.internal.api.DelegatingClassLoader@9a3c36

AT Mon Jul 22 14:40:52 IST 2013
BY :java.lang.Throwable: printStackTraceToString
at com.sun.enterprise.util.Print.printStackTraceToString(Print.java:639)
at com.sun.enterprise.loader.ASURLClassLoader.done(ASURLClassLoader.java:211)
at com.sun.enterprise.loader.ASURLClassLoader.preDestroy(ASURLClassLoader.java:179)
at org.glassfish.javaee.full.deployment.EarClassLoader.preDestroy(EarClassLoader.java:100)
at org.glassfish.deployment.common.DeploymentContextImpl.preDestroy(DeploymentContextImpl.java:151)
at com.sun.enterprise.v3.server.ApplicationLifecycle$1.actOn(ApplicationLifecycle.java:281)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:465)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Parent -> org.glassfish.internal.api.DelegatingClassLoader@9a3c36
was requested to find class com.sun.jndi.url._internal_java_app_for_app_clientpssjava.internal_java_app_for_app_clientpss_javaURLContextFactory after done was invoked from the following stack trace
java.lang.Throwable
at com.sun.enterprise.loader.ASURLClassLoader.findClassData(ASURLClassLoader.java:780)
at com.sun.enterprise.loader.ASURLClassLoader.findClass(ASURLClassLoader.java:696)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at com.sun.naming.internal.VersionHelper12.loadClass(VersionHelper12.java:54)
at com.sun.naming.internal.ResourceManager.getFactory(ResourceManager.java:371)
at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:575)
at javax.naming.spi.NamingManager.getURLContext(NamingManager.java:533)
at com.sun.enterprise.naming.impl.WrappedSerialContext.getURLOrDefaultInitCtx(WrappedSerialContext.java:106)
at javax.naming.InitialContext.unbind(InitialContext.java:416)
at javax.naming.InitialContext.unbind(InitialContext.java:416)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.unpublishObject(GlassfishNamingManagerImpl.java:246)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.unbindAppScopedNameForAppclient(ResourceNamingService.java:191)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.unpublishObject(ResourceNamingService.java:182)
at com.sun.enterprise.resource.deployer.CustomResourceDeployer.deleteResource(CustomResourceDeployer.java:166)
at com.sun.enterprise.resource.deployer.CustomResourceDeployer.undeployResource(CustomResourceDeployer.java:146)
at com.sun.enterprise.connectors.module.ResourcesDeployer.undeployResources(ResourcesDeployer.java:977)
at com.sun.enterprise.connectors.module.ResourcesDeployer.cleanupResources(ResourcesDeployer.java:946)
at com.sun.enterprise.connectors.module.ResourcesDeployer.event(ResourcesDeployer.java:760)
at org.glassfish.kernel.event.EventsImpl$1.run(EventsImpl.java:120)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

#]

Thanks,
Vinod



 Comments   
Comment by Jeremy_Lv [ 06/Aug/13 ]

vinodkumarbolla:
It seems the security's problem from the server log, maybe you just use the user role to load the application that the user can't access. Could you please use the administrator's role to update your application first?

Thanks
-Jeremy

Comment by vinodkumarbolla [ 06/Aug/13 ]

Hi Jeremy,

Thanks for the response.I just want to add one more thing.For the same issue if we undeploy the ear and deploy the ear then the application was properly deployed.

And we are not specifying any roles in sun-application.xml for the application do you think is this the root cause of the issue.

Thanks,
Vinod

Comment by Jeremy_Lv [ 06/Aug/13 ]

Vinod:

You can try to use the root role to update the application, if you still come across the same issue, please tell me your reproduced steps so that I can help you to found out the reason.

Jeremy

Comment by vinodkumarbolla [ 07/Aug/13 ]

Hi Jeremy

Actually i am new to this glassfish.
Can you please explain in which file(eg application.xml) i need to keep this,with syntax(root role to add).

my project structure is like this
ear
--application.xml
--glassfish-resources.xml
--sun-application.xml(recently added as fix for client not authorized for invocation exception but still we are facing that exception. It does not have any roles)

jar
--META-INF
--ejb-jar.xml
--sun-ejb-jar.xml
--web.xml

war
--web.xml

And also We have not specified roles any where in above files.

One more thing is the exception occured in testing environments i am trying to reproduce the issue but i am not able to reproduce that issue.

Can you please provide your mail id so that if you want i can add the content of thise files.

One of the solutions i found in google is like remove osgi-cache before deploy the application.Please help us on this.

Thanks,
Vinod

Comment by Jeremy_Lv [ 08/Aug/13 ]

Here's my mail address: lvsongping@cn.fujitsu.com or lvsongping@gmail.com

BTW: I want to make sure how did you update your application when you get such failure messages?





[GLASSFISH-20739] @ManagedBean-hosted @EJB references cannot be targeted by <ejb-local-ref> in application.xml Created: 02/Aug/13  Updated: 02/Aug/13

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

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

Tags: deployment

 Description   

The attached project demonstrates an application with a @ManagedBean in the library directory.

The @ManagedBean has an @EJB reference in it.

The @EJB reference has a name() of java:app/Greeter so that it can be targeted by META-INF/application.xml-level configuration.

The META-INF/application.xml attempts to target this reference to disambiguate it.

The application deploys "successfully", but leaves behind unresolved reference errors in server.log.

To reproduce:

  1. Extract the attached Maven project to a directory somewhere.
  2. Run mvn clean install.
  3. asadmin deploy the resulting .ear file on a GlassFish 3.1.2.2 environment.
  4. Observe that it claims deployment was successful.
  5. Locate and open server.log.
  6. Observe the following stack snippet:
    Caused by: java.lang.IllegalArgumentException: Cannot resolve reference Remote ejb-ref name=java:app/Greeter,Remote 3.x interface =com.edugility.managedbeans.api.Greeter,ejb-link=null,lookup=,mappedName=,jndi-name=,refType=Session because there are 2 ejbs in the application with interface com.edugility.managedbeans.api.Greeter. 
    Some of the possible causes: 
    1. The EJB bean class was packaged in an ear lib library (or through any other library mechanism which makes the library visible to all component modules), this makes all the component modules include this bean class indirectly. 
    2. The EJB bean class was packaged in a component module which references the EJB, either directly or indirectly through Manifest, WEB-INF/lib. 
    The EJB bean class should only be packaged in the declaring ejb module and not the referencing modules. The referencing modules should only include EJB interfaces.
    

Please note that in the .ear file's Maven project src/main/application/META-INF/application.xml exists, is being used, and contains a <ejb-local-ref> element that attempts to disambiguate the reference that GlassFish claims has not been disambiguated.

More discussion on this StackOverflow question.



 Comments   
Comment by ljnelson [ 02/Aug/13 ]

Looks like I cannot attach a file here; see this DropBox link





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

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

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


 Description   

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

SYNOPSIS
list-applications [--help]
[--long=

{false|true}

] [--resources] [--subcomponents]
[--type type] [target]

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

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



 Comments   
Comment by Hong Zhang [ 31/Oct/12 ]

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

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

Comment by Sanjeeb Sahoo [ 02/Nov/12 ]

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

Comment by Hong Zhang [ 02/Nov/12 ]

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

Comment by Hong Zhang [ 05/Mar/13 ]

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





[GLASSFISH-11178] Deployment can half-succeed, half-fail Created: 25/Nov/09  Updated: 02/Dec/11

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

Type: Bug Priority: Minor
Reporter: Tim Quinn Assignee: Hong Zhang
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,178
Status Whiteboard:

v3_exclude


 Description   

Before fixing 11143, a side effect was that the failed download (described in
11143) would seem to partially invalidate the deployment but not entirely.
Attempting to redeploy the app would be accepted - so the app was still
partially registered - but the redeployment would fail because the
UndeployCommandParameters retrieved from the deployment context would be null.



 Comments   
Comment by Tim Quinn [ 25/Nov/09 ]

Excluding from v3, targeting v3.1.

Comment by Hong Zhang [ 03/Feb/10 ]

tim: do you still have the steps to reproduce this?

Comment by Tim Quinn [ 03/Feb/10 ]

The fix to 11143 removed the only trigger I know of that caused this error.

We could revert that change (locally only, only to reproduce the problem) and
use the sample app attached to 11143. Or, we could probably insert some
temporary logic to simulate the error condition of 11143...maybe just a "throw"
in the right place would be enough.

Let me look into it shortly to see if it's easy to create the error scenario.

Comment by Hong Zhang [ 28/Sep/10 ]

scrubbing issue, move state to NEW

Comment by Hong Zhang [ 04/Oct/10 ]

scrubbing issues

Comment by Hong Zhang [ 08/Dec/10 ]

Discussed this with Tim, as this error condition can only occur due to internal error and there is not an easy/simple fix to handle the error condition more gracefully, we will just revisit this if/when needed.





[GLASSFISH-10533] Report useful error message Created: 23/Oct/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: Sanjeeb Sahoo Assignee: Hong Zhang
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: File test1-osgi.war    
Issuezilla Id: 10,533

 Description   

ss141213@Sahoo:/space/ss141213/WS/gf/v3$ deploy --type=osgi
~/rfc66/test1/test1-osgi.war
com.sun.enterprise.admin.cli.CommandException: remote failure: Exception while
deploying the app : java.lang.RuntimeException: Cannot install bundle
com.sun.enterprise.deploy.shared.FileArchive@18b622 in osgi runtime

where as, server.log contains much more useful information as shown below:
WARNING: Exception org.osgi.framework.BundleException: Bundle
"sahoo.rfc66.test1" version "1.0.0" has already been installed from:
/space/ss141213/WS/gf/v3/publish/glassfishv3/glassfish/domains/domain1/autodeploy/bundles/test1-osgi.war
while adding location =
reference:file:/space/ss141213/WS/gf/v3/publish/glassfishv3/glassfish/domains/domain1/applications/test1-osgi/

To reproduce this behavior, do the following:
cp the attached test1-osgi.war to domain1/autodeploy/bundles
then run asadmin deploy --type=osgi osgi-test1.war



 Comments   
Comment by Sanjeeb Sahoo [ 23/Oct/09 ]

Created an attachment (id=3601)
Test case

Comment by Hong Zhang [ 02/Nov/09 ]

Scrubbing v3 bugs per Ahbijit's request.

Downgrade to P4 as the server.log contains the necessary information.

(I did not get a chance to take a look what it takes to fix this yet, I will
still try to get to it if I have time before HCF).

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-10297] Autodeployer should log what files it ignores only once, not each iteration Created: 15/Oct/09  Updated: 23/May/13

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

Type: Bug Priority: Minor
Reporter: Tim Quinn Assignee: Hong Zhang
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: 10,297

 Description   

FINE-level logging from the autodeployer reports what files are ignored each
time the autodeployer runs.

It has been requested that this be logged only once.

I am marking this as a p4. No functionality is broken or missing.

Although the specification of what files or directories to ignore is static
(currently), the actual files on disk might be created or deleted while the
server is running. To suppress extra log messages would require the
autodeployer to keep a record of which files it has logged as ignored already,
adjust this list as files which match the ignore set are added or deleted, etc.
This seems like more overhead than is warranted.

We might just log once, during autodeployer start-up, what the ignore set is and
leave it at that.



 Comments   
Comment by Tim Quinn [ 15/Oct/09 ]

adding Sahoo to cc list

Comment by Tom Mueller [ 06/Mar/12 ]

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

Comment by Tim Quinn [ 23/May/13 ]

Reassigning to the deployment lead.





[GLASSFISH-11372] "Application deployed sucessfully with name" show in english for ml version Created: 29/Dec/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: not determined

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

Operating System: Solaris
Platform: Sun


Issuezilla Id: 11,372

 Description   

Install v3 ml build. Run './asadmin deploy xxx.ear' to deploy one application
under supported locale such as Simplified Chinese locale. Following message
still show in english:

Application deployed sucessfully with name xxx.ear.



 Comments   
Comment by Bill Shannon [ 29/Dec/09 ]

Reassign.

Comment by Hong Zhang [ 05/Jan/10 ]

I am not sure what happens. Looking at the code, we have already localized this
message. This is the message that's defined in the LocalStrings.properties.

v3/deployment/admin/src/main/java/org/glassfish/deployment/admin
deploy.command.success=Application deployed successfully with name

{0}

.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-9393] On first deployment, asadmin does not prompt me for the "name" option. Created: 05/Sep/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: not determined

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

Operating System: All
Platform: Linux


Issuezilla Id: 9,393

 Description   

On first deployment, asadmin does not prompt me for the "name" option. On
redeployment it does.

e.g.

$ asadmin deploy target/ffit.war

Command deploy executed successfully.

$ asadmin redeploy target/ffit.war
Enter the value for the name option> ffit

Looks like the name parameter is optional in one case and has a default in another.



 Comments   
Comment by Hong Zhang [ 07/Sep/09 ]

Is your issue more of why the asadmin does not prompt for name for deploy
command or why the name param is optional for deploy command?

If it's former, I think it's expected as the name is an optional param of the
deploy command. If it's latter, the name param has always been optional for
deploy command since earlier days (a default will be derived when the name param
is not present).

The redeploy command is different where the name is a required param, this is
because we have to know which application it replaces/upgrades.

Comment by marina vatkina [ 08/Sep/09 ]

Hmmm... if redeploy is equal to 'deploy --force=true', won't it be able to
survive without the app name?

Comment by Hong Zhang [ 08/Sep/09 ]

marina: the redeploy command syntax is a little different. With the mandatory
name option, user does not need to re-specify the path information in case of
directory redeployment.

Comment by km [ 09/Sep/09 ]

Hong, I am issue_daemon :-P

I am confused by what you are asking. All I am referring you to is the developer
experience of the deploy-debug-redeploy cycle. When I am developing an app, in
v2, I used to do:

  • deploy ffit.war (first time deployment)
  • test, make modifications
  • deploy ffit.war -> results in redeployment.

Now, I have to do:

  • deploy ffit.war
  • test, make modifications
  • either: redeploy ffit.war --name ffit (which is pretty lame), or
    deploy --force ffit.war

both of the last step are unnecessary in my opinion.

So, yes, redeploy command should default the name of the app as the name
(excluding the extension) of the archive. If user provides one, that overrides
the default. Same thing with directory redeployment. Name of the directory is
the name of the app, by default.

Comment by Hong Zhang [ 15/Sep/09 ]

But in redeploy command case, the path param is optional which means you cannot
always derive a name from it.

Comment by Hong Zhang [ 15/Sep/09 ]

(Clicked submit accidentally before I was able to finish my comments)

A redeploy is more like an undeploy, user needs to provide something which can
help us uniquely identify the application he/she wants to redeploy.

Comment by Hong Zhang [ 15/Sep/09 ]

But in redeploy command case, the path param is optional which means you cannot
always derive a name from it.

Comment by km [ 15/Sep/09 ]

But, but, you don't tell me under what "name" you deployed my ffit.war when I
did "asadmin deploy ffit.war". All it tells me is: Command deploy executed
successfully.

Anyway,
asadmin deploy foo.war followed by several
asadmin redeploy foo.war was what I thought was intuitive. If you think what we
have now is ok, please close the bug (after you fix the deploy command's success
message like above).

Comment by marina vatkina [ 15/Sep/09 ]

I think it should work...
While the archive is optional on redeploy, the cli can get the app name from it
if it is specified and match it to the existing entry, and complain if it
doesn't match. Right?
If the problem is that with the name optional all args become optional, the
redeployment can complain if there are indeed no args and ask that at least name
or archive is provided.

Comment by dochez [ 30/Oct/09 ]

ok say you do :

asadmin deploy hello.jar
and
asadmin deploy --name hello1 hello.jar

now you do :
asadmin redeploy hello.jar

if you don't specify the name, which one should we pick ?

Specifying the name might be an annoyance but it's the safest way.

Comment by km [ 30/Oct/09 ]

>asadmin deploy hello.jar
>and
>asadmin deploy --name hello1 hello.jar

>now you do :
>asadmin redeploy hello.jar

Since on this command line, --name was not specified, you should use the name as
"hello", derived from the name of the archive (because that's what you did on
deploy command in the first place!)

Simple enough, eh?

Comment by Hong Zhang [ 02/Nov/09 ]

As I mentioned earlier, the path in the redeploy command is optional so we
cannot always derive the name.

I have made the change to tell user what application name it is deployed under now:
"Application deployed successfully with name XXX".

I will downgrade the bug to P4 and we can decide if we need to better align the
deploy/redeploy command syntax based on the user feedback.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-13629] list-components --long looks cheap Created: 27/Sep/10  Updated: 06/Mar/12

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

Type: Improvement Priority: Minor
Reporter: Byron Nevins Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows (generic)
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-12236 Review CLI Output Consistency Resolved
Duplicate
duplicates GLASSFISH-12382 reformat output from list-components ... Resolved
Issuezilla Id: 13,629

 Description   

No formatting. The long option adds enabled inside parenthesis (!!!)
See list-instances for tips on --long output

Other info can be added. E.g. what URL can I use to access the component?

c:\glassfishv3\glassfish>asadmin list-components --long
Math <web> (enabled)
hello <web> (enabled)
monitoring-scripting-client <web> (enabled)

c:\glassfishv3\glassfish>asadmin list-components
Math <web>
hello <web>
monitoring-scripting-client <web>



 Comments   
Comment by Tom Mueller [ 27/Sep/10 ]

Please see the following for guidelines on command output:

http://wikis.sun.com/display/GlassFish/Asadmin+Command+Output+Guidelines

Comment by Hong Zhang [ 28/Sep/10 ]

move under deployment category

Comment by Hong Zhang [ 04/Oct/10 ]

Assign to romain to see how we could improve the format of the current output
of the --long option to conform to the standard.

For adding any additional information for the --long output, we will look in
the next release as potential enhancement.

Comment by Romain Grécourt [ 29/Nov/10 ]

reassign to Herve

Comment by herve_souchaud [ 30/Nov/10 ]

Formatting was added to list-components, list-sub-components and list-application-refs commands output. Now, these commands generate columnar output. Changes are part of the SVN revision #42966.

As Hong already said, adding any additional information for the --long output should be looked in the next release.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-13552] deploy error not as clear as with GFv2.1.1 when no class found Created: 20/Sep/10  Updated: 02/Dec/11

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

Type: Bug Priority: Minor
Reporter: Dies Koper Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Attachments: File is_classloader-web.war    
Issuezilla Id: 13,552

 Description   

I'm comparing deployment error messages in GFv3.1 and GFv2.1.1.
In this WS app, a class is missing.

On glassfish-3.1-b21-09_17_2010, the error message has four exception class
names but nothing related to a user class missing:

D:\GFv3.1\glassfish-3.1-b21-09_17_2010\glassfishv3>bin\asadmin deploy
\is_classloader-web.war
remote failure: Error occur during deployment: Exception while loading the app :
java.lang.IllegalStateException: ContainerBase.addChild: st
art: org.apache.catalina.LifecycleException:
org.apache.catalina.LifecycleException: javax.servlet.ServletException. Please
see server.log f
or more details.

Command deploy failed.

The server log has many stacktraces with one having a NoClassDefFoundError with
the missing class name in its 'caused by' part.

On GFv2.1.1 the missing class name is included in the initial error message:

D:\GFv2.1.1\glassfish-v2.1.1-b22\glassfish>bin\asadmin deploy
\is_classloader-web.war
CLI171 Command deploy failed : Deploying application in domain failed;
annotations/server/common/AddNumbersCommon

The server log here has only three error messages, all clearly indicating the
missing class name and the fact that it could not be loaded.



 Comments   
Comment by Dies Koper [ 20/Sep/10 ]

Created an attachment (id=4925)
test app

Comment by Hong Zhang [ 21/Sep/10 ]

Yes, from tracing the code, this part of the code paths have changed so the
exception got thrown at a different place (therefore different stack traces and
different error messages).

I will check with webservices team to see why the code paths have changed, but
this is something we may not be able to change.

I do see this exception in the very beginning of the first stack trace of my
server.log though when I deployed it to 3.1:

[#|2010-09-21T09:25:52.549-
0400|WARNING|glassfish3.1|javax.enterprise.webservices.org.glassfish.webservices

_ThreadID=14;_ThreadName=Thread-1; Servlet web service endpoint 'j2w_base'
failure
java.lang.NoClassDefFoundError: annotations/server/common/AddNumbersCommon
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at org.glassfish.webservices.JAXWSServlet.registerEndpoint
(JAXWSServlet.java:292)
at org.glassfish.webservices.JAXWSServlet.doInit(JAXWSServlet.java:274)
at org.glassfish.webservices.JAXWSServlet.init(JAXWSServlet.java:109)
at org.apache.catalina.core.StandardWrapper.initServlet
(StandardWrapper.java:1427)
at org.apache.catalina.core.StandardWrapper.load
(StandardWrapper.java:1229)
at org.apache.catalina.core.StandardContext.loadOnStartup
(StandardContext.java:5045)
at org.apache.catalina.core.StandardContext.start
(StandardContext.java:5337)
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:1929)
at com.sun.enterprise.web.WebContainer.loadWebModule
(WebContainer.java:1606)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:100)
...
Comment by Dies Koper [ 22/Sep/10 ]

I found the NoClassDefFoundError with the class name in my old logs as first
message. Must have missed it the first time. So there is enough info in server.log.

This issue can focus on the (lack of useful) details in the CUI error message.

Comment by Hong Zhang [ 04/Oct/10 ]

scrubbing issues

Comment by Hong Zhang [ 10/Dec/10 ]

I took a look at this again today, there is not much we can do (the message is different as the code path has changed). As the error message is pointing to the server.log where the cause could be found, I am going to downgrade the bug and revisit in the future release if needed.





[GLASSFISH-11670] NPE when deploying app with mistakes in sun-ejb-jar.xml Created: 10/Mar/10  Updated: 02/Dec/11

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

Type: Bug Priority: Minor
Reporter: Dies Koper Assignee: Hong Zhang
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: File MyApplication.ear    
Issuezilla Id: 11,670

 Description   

When I deploy an application with illegal values in sun-ejb-jar.xml, I get the
following message:

D:\GFv3.1\glassfish-v3_1-b01-03_10_2010\glassfishv3\bin>asadmin deploy
D:\shared\MyApplication.ear
com.sun.enterprise.admin.cli.CommandException: remote failure: Exception while
deploying the app : java.lang.NullPointerException

Command deploy failed.

The server log has more useful messages (and a stacktrace).
Why not list the warnings and errors in the message above and not mention or log
the NPE?

[#|2010-03-11T14:04:31.453+1100|WARNING|glassfishv3.0|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=23;_ThreadName=Thread-1;|This
bean [MyEjb] has no ejb reference by the name of [...]|#]

[#|2010-03-11T14:04:31.453+1100|SEVERE|glassfishv3.0|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=23;_ThreadName=Thread-1;|DPL8006:
get/add descriptor failure : ejb-ref TO ...|#]

[#|2010-03-11T14:04:31.453+1100|SEVERE|glassfishv3.0|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=23;_ThreadName=Thread-1;|DPL8007:
Invalid Deployment Descriptors element jndi-name value ...|#]

[#|2010-03-11T14:04:31.453+1100|WARNING|glassfishv3.0|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=23;_ThreadName=Thread-1;|This
bean [MyEjb] has no resource reference by the name of [...]|#]

[#|2010-03-11T14:04:31.453+1100|SEVERE|glassfishv3.0|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=23;_ThreadName=Thread-1;|DPL8007:
Invalid Deployment Descriptors element jndi-name value ...|#]

[#|2010-03-11T14:04:31.453+1100|SEVERE|glassfishv3.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=23;_ThreadName=Thread-1;|Exception
while deploying the app
java.lang.NullPointerException
at
com.sun.enterprise.deployment.node.runtime.ResourceRefNode.addDescriptor(ResourceRefNode.java:116)
at
com.sun.enterprise.deployment.node.runtime.DefaultResourcePrincipalNode.postParsing(DefaultResourcePrincipalNode.java:86)
at
com.sun.enterprise.deployment.node.DeploymentDescriptorNode.endElement(DeploymentDescriptorNode.java:330)
at
com.sun.enterprise.deployment.node.SaxParserHandler.endElement(SaxParserHandler.java:450)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
at
com.sun.org.apache.xerces.internal.impl.dtd.XMLNSDTDValidator.endNamespaceScope(XMLNSDTDValidator.java:263)



 Comments   
Comment by Dies Koper [ 10/Mar/10 ]

Created an attachment (id=4265)
reproducible test app

Comment by Hong Zhang [ 04/Oct/10 ]

scrubbing issues

Comment by Hong Zhang [ 13/Dec/10 ]

I have fixed the NPE. We still don't have the ability to show the warnings from DOL code back to the user yet. But the error message as other error messages will have "Please see server.log for more details.", so at least we point user to the server.log where they could see the warnings. And once we fix 15114, user will be able to see these warnings from the verifier output.
I am downgrading this issue to P4 but keep it open to see if there is any improvement we can make to pass the warnings back to the user in the normal deployment in the future release.





[GLASSFISH-11642] EJB deploys and silently fails Created: 04/Mar/10  Updated: 02/Dec/11

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

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

Operating System: All
Platform: Linux


Attachments: Java Archive File ejbproblem-0.0.1-SNAPSHOT.jar     Zip Archive ejbproblem.zip     Text File ejbproblem0.0.2-SNAPSHOT.zip    
Issuezilla Id: 11,642

 Description   

I have an example EJB that deploys, but not all of the EJB's materialize.
i.e. the deploy fails silently

In the example app you will see a reference to log4j logger in the EJBs EJBTest1
and EJBTest2

The server log says the following :
[#|2010-03-04T09:54:15.414+0200|SEVERE|glassfishv3.0|global|_ThreadID=25;_ThreadName=Thread-1;|Class
[ Lorg/apache/log4j/Logger; ] not found. Error while loading [ class
za.co.enerweb.entity.ejbs.EJBTest1 ]|#]

But the application deploys on the admin GUI.

(Log4j is not in the EJB jar.)

I spent hours trying to figure out why I could not resolve my EJB in my WAR
application.



 Comments   
Comment by rjdkolb [ 04/Mar/10 ]

Created an attachment (id=4252)
Sample maven app