[GLASSFISH-14076] Report an error on a ManagedBean or an EJB with missing no-arg or @Inject constructor Created: 19/Oct/10  Updated: 13/Dec/10

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

Type: Improvement Priority: Major
Reporter: Sivakumar Thyagarajan Assignee: Sanjeeb Sahoo
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: 14,076

 Description   

As per the Managed Beans specification, a @ManagedBean annotated ManagedBean
must have a no-arg constructor. Today deployment succeeds for a CDI-enabled
ManagedBean with a no-arg constructor, and it fails at runtime with an Weld
instantiation error as shown below:
Caused by: org.jboss.weld.exceptions.DeploymentException:
test.beans.org$jboss$weld$bean-
$export$work$workspaces$gfv3$v3$distributions$glassfish$target$glassfish3$glassf
ish$domains$domain1$applications$cdi-simple-managed-bean-interceptor-web$-
ManagedBean-class_test$beans$TestManagedBean_$$_WeldProxy
at
org.jboss.weld.bean.ManagedBean.applyInterceptors(ManagedBean.java:600)
at
org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.produce(ManagedBean.j
ava:256)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:338)
at org.jboss.weld.context.DependentContext.get(DependentContext.java:62)
at
org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:660)
at
org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:734)
at
org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.ja
va:757)
at
org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:118
)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:840)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:852)
at
org.jboss.weld.manager.SimpleInjectionTarget$1.proceed(SimpleInjectionTarget.jav
a:122)
at
org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServices
Impl.java:134)
at
org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:50)
at
org.jboss.weld.manager.SimpleInjectionTarget.inject(SimpleInjectionTarget.java:1
16)
at
org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.
java:227)
at
org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.
java:181)
at
com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.crea
teManagedBean(ManagedBeanManagerImpl.java:478)
at
com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.crea
teManagedBean(ManagedBeanManagerImpl.java:428)
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManaged
Object(InjectionManagerImpl.java:300)
... 28 more
Caused by: org.jboss.weld.exceptions.DefinitionException:
test.beans.org$jboss$weld$bean-
$export$work$workspaces$gfv3$v3$distributions$glassfish$target$glassfish3$glassf
ish$domains$domain1$applications$cdi-simple-managed-bean-interceptor-web$-
ManagedBean-class_test$beans$TestManagedBean_$$_WeldProxy
at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:223)
at
org.jboss.weld.bean.ManagedBean.applyInterceptors(ManagedBean.java:594)
... 46 more
Caused by: java.lang.InstantiationException: test.beans.org$jboss$weld$bean-
$export$work$workspaces$gfv3$v3$distributions$glassfish$target$glassfish3$glassf
ish$domains$domain1$applications$cdi-simple-managed-bean-interceptor-web$-
ManagedBean-class_test$beans$TestManagedBean_$$_WeldProxy
at java.lang.Class.newInstance0(Class.java:340)
at java.lang.Class.newInstance(Class.java:308)
at
org.jboss.weld.util.reflection.SecureReflections$16.work(SecureReflections.java:
396)
at
org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess
.java:54)
at
org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInstantiation(SecureR
eflectionAccess.java:216)
at
org.jboss.weld.util.reflection.SecureReflections.newInstance(SecureReflections.j
ava:391)
at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:218)
... 47 more

#]

We could instead detect this error early during deployment of the archive and
fail deployment. Please see a proposed patch below for doing this.
[16:17:36] [siva@spiff ../gfv3/v3/deployment/dol] $ svn diff
Index:
src/main/java/com/sun/enterprise/deployment/annotation/handlers/ManagedBeanHandl
er.java
===================================================================

src/main/java/com/sun/enterprise/deployment/annotation/handlers/ManagedBeanHandl
er.java (revision 41835)
+++
src/main/java/com/sun/enterprise/deployment/annotation/handlers/ManagedBeanHandl
er.java (working copy)
@@ -54,6 +54,7 @@
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;
import java.lang.reflect.Method;
+import java.lang.reflect.Constructor;

import java.util.List;
import java.util.LinkedList;
@@ -98,6 +99,16 @@

Class managedBeanClass = (Class) element.getAnnotatedElement();

+ //check to see if the ManagedBean has a no-argument constructor
+ //see MB2 and MB.2.1.1
+ try

{ + Constructor c = managedBeanClass.getConstructor(null); + }

catch (NoSuchMethodException nsme)

{ + throw new IllegalStateException ("Class " + managedBeanClass + + " is not a valid EE ManagedBean class as it " + + "does not have a no-arg constructor. "); + }

+
managedBeanDesc.setBeanClassName(managedBeanClass.getName());



 Comments   
Comment by marina vatkina [ 20/Oct/10 ]

This is not as simple. As Managed Bean support constructor injection, it doesn't
need to have a no-arg constructor.

The Managed Bean specification, per se, doesn't support constructor based
injection. However it lets other specifications and MB implementations to
support MBs without a no-arg constructor [last part in the initial description
of MB.2 in the Managed Beans specification].

Since, in our container, we can only support constructor injection in cases
where Managed Beans are CDI Beans, we are left to conditions when a @ManagedBean
annotated bean is a CDI bean. As per section EE.5.20 (Java EE6 specification)
and Section 3.1.1 of the CDI 1.0 specification, this leaves us to cases where a
@ManagedBean annotated bean that has a @Inject annotated constructor alone can
be considered as a case where constructor based injection is supported.

So, we can modify the requirement and the proposed fix in this issue to consider
cases where a @ManagedBean neither has a no-arg constructor nor a constructor
that is annotated with @Inject, to be an error and fail deployment. So, for
instance in the scenarios below, Foo1 is allowed but Foo2 deployment would fail.

@ManagedBean
public class Foo1 {
...
//no no-arg constructor
...
@Inject
Foo1(Bar b)

{...}
...
}

@ManagedBean
public class Foo2 {
...
//no no-arg constructor
...
Foo2(Bar b){...}

...
}

Comment by marina vatkina [ 29/Oct/10 ]

We do not currently do constructor validation for EJBs either.

Comment by marina vatkina [ 29/Oct/10 ]

Transferring to verifier to add the assertions. As of Java EE 5 verifier
correctly identified missing no-arg constructor in a SLSB.

Comment by Sanjeeb Sahoo [ 09/Nov/10 ]

deferring to a future release.





[GLASSFISH-18428] Verifier: Inspect JDK 7 getMethods()/getDeclaredMethods() usage Created: 28/Feb/12  Updated: 28/Feb/12

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

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


 Description   

Recent JDK 7 releases have altered the order of methods returned by the
Class.getMethods() and Class.getDeclaredMethods() calls. The order is
no longer stable and can change from one JVM run to the next.

This caused a number of sporadic bugs to appear during 3.1.2 development
when running with JDK 7. Those have been fixed, but further inspection
of the source has found a number of cases where we use getMethods() and
getDeclaredMethods().

Each of these cases should be visually inspected to see if the code is
making any assumptions on the order of methods returned by get*Methods().
In particular it should handle the case of multiple methods having the
same name.

For more details on what to look for and how to fix it see this document:

https://wikis.oracle.com/display/GlassFish/Method+Ordering+from+Class.getMethods

Please inspect the following files for their use of getMethods() /
getDeclaredMethods() to ensure the code is not making any assumptions
with respect to the order of methods returned. Create bugs for
any issues that need to be fixed and link them to this task. Once you
have completed inspection update this task with status and close it.

Verifier implementation module
    BusinessInterfaceException.java
    BusinessMethodException.java
    BusinessMethodExceptionCheck.java
    BusinessMethodFinal.java
    BusinessMethodMatchesWithDD.java
    BusinessMethodName.java
    BusinessMethodPublic.java
    BusinessMethodRmiIIOPArgs.java
    BusinessMethodRmiIIOPReturn.java
    BusinessMethodStatic.java
    ConnectionFactoryGetConnection.java
    ContainerTransactionStyle3.java
    EJBCreatePostConstruct.java
    EjbCreateMatchesCreate.java
    EjbCreateMatchesCreate.java
    EndPointImplBeanClassChecker.java
    HomeInterfaceFindMethodMatch.java
    HomeMethodException.java
    HomeMethodRmiIIOPArgs.java
    HomeMethodRmiIIOPReturn.java
    LocalInterfaceRemoteException.java
    MDBImplementsListenerMethods.java
    MessageListenerMethodModifiers.java
    MethodsExist.java
    QueryMethodTest.java
    TaglibFunctionMethodTest.java
    TransactionDemarcationComponentInterface.java
    WSTest.java

    ASEjbIsReadOnlyBean.java
    ApplicationExceptionComponentInterfaceMethods.java
    ApplicationExceptionHomeInterfaceMethods.java
    CmpEjbCreateMethod.java
    CmpEjbNoInvalidCreateMethod.java
    EjbClassExposed.java
    EjbCreateMethodArgs.java
    EjbCreateMethodArgs.java
    EjbCreateMethodException.java
    EjbCreateMethodExceptions.java
    EjbCreateMethodFinal.java
    EjbCreateMethodFinal.java
    EjbCreateMethodName.java
    EjbCreateMethodName.java
    EjbCreateMethodPublic.java
    EjbCreateMethodPublic.java
    EjbCreateMethodReturn.java
    EjbCreateMethodReturn.java
    EjbCreateMethodStatic.java
    EjbCreateMethodStatic.java
    EjbFindByPrimaryKeyArgs.java
    EjbFindByPrimaryKeyException.java
    EjbFindByPrimaryKeyFinal.java
    EjbFindByPrimaryKeyName.java
    EjbFindByPrimaryKeyPublic.java
    EjbFindByPrimaryKeyReturn.java
    EjbFindByPrimaryKeyStatic.java
    EjbFinderMethodArgs.java
    EjbFinderMethodException.java
    EjbFinderMethodFinal.java
    EjbFinderMethodName.java
    EjbFinderMethodNameCmp.java
    EjbFinderMethodObjectNotFoundException.java
    EjbFinderMethodPublic.java
    EjbFinderMethodReturn.java
    EjbFinderMethodStatic.java
    EjbPostCreateMethodArgs.java
    EjbPostCreateMethodException.java
    EjbPostCreateMethodFinal.java
    EjbPostCreateMethodName.java
    EjbPostCreateMethodPublic.java
    EjbPostCreateMethodReturn.java
    EjbPostCreateMethodStatic.java
    EjbRemoveMethodNameExistInSLSB.java
    HomeInterfaceCreateMethodExceptionCreate.java
    HomeInterfaceCreateMethodExceptionCreate.java
    HomeInterfaceCreateMethodExceptionMatch.java
    HomeInterfaceCreateMethodExceptionMatch.java
    HomeInterfaceCreateMethodExceptionRemote.java
    HomeInterfaceCreateMethodExceptionRemote.java
    HomeInterfaceCreateMethodMatchArgs.java
    HomeInterfaceCreateMethodMatchArgs.java
    HomeInterfaceCreateMethodReturn.java
    HomeInterfaceCreateMethodReturn.java
    HomeInterfaceFindByPrimaryKeyArg.java
    HomeInterfaceFindByPrimaryKeyName.java
    HomeInterfaceFindByPrimaryKeyReturn.java
    HomeInterfaceFindMethodExceptionFinder.java
    HomeInterfaceFindMethodExceptionMatch.java
    HomeInterfaceFindMethodExceptionRemote.java
    HomeInterfaceFindMethodHasQuery.java
    HomeInterfaceFindMethodReturn.java
    HomeInterfaceNoFinderMethodNames.java
    HomeInterfacePostCreateMethodExceptionMatch.java
    HomeMethodRmiIIOPArgs.java
    HomeMethodRmiIIOPReturn.java
    HomeMethodTest.java
    InjectionTargetTest.java
    InterfaceMatchMethodArgs.java
    InterfaceMatchMethodException.java
    InterfaceMatchMethodReturn.java
    InterfaceMethodTest.java
    LocalInterfaceExposed.java
    PrimaryKeyClassMethodEqual.java
    PrimaryKeyClassMethodHashCode.java
    PrimaryKeyClassOpt.java
    PrimaryKeyClassOptReturn.java
    RmiIIOPUtils.java
    SelectMethodTest.java
    StatelessCreateNoArgs.java
    StatelessCreateOnlyOne.java
    StatelessCreateReturn.java
    StatelessEjbCreateHome.java
    TransactionDemarcationComponentInterface.java
    TransactionDemarcationHomeInterface.java
    TransactionDemarcationHomeInterface.java





[GLASSFISH-21515] Possible null pointer dereference Created: 12/Feb/16  Updated: 12/Feb/16

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

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


 Description   

Strangely that variable specMappingInfo was used before it was checked:

  if (specMappingInfo.length()!=0 && specMappingInfo!=null)

it seems it should be

  if (specMappingInfo!=null && specMappingInfo.length()!=0)

File: appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/Result.java
Line: 119

This possible defect found by static analyzer AppChecker






[GLASSFISH-4202] "WARNING: Visiting non-standard Signature object" Created: 16/Feb/08  Updated: 04/May/12

Status: Open
Project: glassfish
Component/s: verifier
Affects Version/s: 9.1peur1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: mkarg Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File server.log    
Issuezilla Id: 4,202
Status Whiteboard:

v3_exclude,V2.1.1exclude


 Description   

It happens quite often that I see the following WARNING in GlassFish's log after
doing some deploy-undeploy cycles. To be it looks like the admin gui is
procuding that warnings. It is a bit scary that GlassFish stumbles over it's own
behaviour. Users will think they did something wrong, while actually they did
nothing wrong.



 Comments   
Comment by Anissa Lam [ 16/Feb/08 ]

Please attach server.log or copy & paste the warning here. There is no way for
us to work on this issue without even knowing what warning you are getting.

Comment by mkarg [ 17/Feb/08 ]

Created an attachment (id=1338)
GlassFish server.log containing several "Visiting non-standard Signature object" WARNINGs

Comment by Anissa Lam [ 17/Feb/08 ]

Thanks for providing the warning message.
I believe this is warning from the verifier. Reassign the bug to 'verifier' for
further investigation.

Comment by harpreet [ 16/Apr/08 ]

Not critical to v2.1 - marking issue for next release

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 as this bug is
neither invisible nor internal. The administrator will see a bug and try to fix
it, what results in costs for the customer. This is not acceptable from an
economic view.

Comment by Sanjeeb Sahoo [ 17/Sep/09 ]

v3_exclude

Comment by Sanjeeb Sahoo [ 17/Sep/09 ]

The actual warning comes from BCEL which verifier uses. Since BCEL is bundled
with JDK, we have to wait for JDK to bundle newer version of BCEL. Until then,
we have to live with this message. Hence, v3_exclude.

Comment by jagadesh [ 15/Oct/09 ]

Will not be fixed for V2.1.1

Comment by edrandall [ 04/May/12 ]

Just upgraded to 3.1.2 and this issue is still present.

The verifier outputs the message 107,130 times during the verification of our .ear file, with no clue as to what object is actually non-standard.

Will it ever be fixed?





[GLASSFISH-19543] Running verifier - Connection refused Created: 17/Jan/13  Updated: 17/Jan/13

Status: Open
Project: glassfish
Component/s: verifier
Affects Version/s: 3.1.2_b22
Fix Version/s: None

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

Windows XP



 Description   

I am trying to deploy an application with a verifier turned on. The application is comprised of EJB 3 module and a Web part. When the verifier is on, the following error pops up in the log:

STATIC VERIFICATION RESULTS
---------------------------

----------------------------------
NUMBER OF FAILURES/WARNINGS/ERRORS
----------------------------------

  1. of Failures : 0
  2. of Warnings : 0
  3. of Errors : 1

-----------------------------------------------------
ERRORS THAT OCCURRED WHILE RUNNING STATIC VERIFICATION
-----------------------------------------------------

Error Name : Problem in running tests for :ADTI#ADTI-war.war
Error Description : java.net.ConnectException: Connection refused: connect

at java.net.TwoStacksPlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:157)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:388)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:483)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:213)
at sun.net.www.http.HttpClient.New(HttpClient.java:300)
at sun.net.www.http.HttpClient.New(HttpClient.java:316)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:992)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:928)
at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:846)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1296)
at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:653)
at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:1291)
at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:1258)
at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:260)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.dispatch(XMLDocumentScannerImpl.java:1151)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.next(XMLDocumentScannerImpl.java:1047)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:960)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:607)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:488)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:835)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123)
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:240)
at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:300)
at com.sun.enterprise.tools.verifier.BaseVerifier.createDOMObject(BaseVerifier.java:162)
at com.sun.enterprise.tools.verifier.BaseVerifier.createDocumentObject(BaseVerifier.java:115)
at com.sun.enterprise.tools.verifier.BaseVerifier.verify(BaseVerifier.java:147)
at com.sun.enterprise.tools.verifier.web.WebVerifier.verify(WebVerifier.java:96)
at com.sun.enterprise.tools.verifier.Verifier.runVerifier(Verifier.java:391)
at com.sun.enterprise.tools.verifier.Verifier.verifyArchive(Verifier.java:330)
at com.sun.enterprise.tools.verifier.Verifier.verify(Verifier.java:214)
at com.sun.enterprise.tools.verifier.Verifier.verify(Verifier.java:140)
at org.glassfish.deployment.admin.DeployCommand.event(DeployCommand.java:794)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:397)
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 org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:214)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:207)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:148)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer._service(GrizzlyContainer.java:182)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer.service(GrizzlyContainer.java:147)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:148)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:722)

The same error is produced when I launch the verifier from a command line.
Without verification the application is deployed successfully.
The project was developed in NetBeans; it passes all verifications and compiles without warnings.

What could be the most likely reason for such an error? How can find a particular XML file with WAR which blows the parser?



 Comments   
Comment by Sanjeeb Sahoo [ 17/Jan/13 ]

Seems something to do with DOL configures the XML parser to locate schemas and dtds. So assigning to Hong to look into it.





[GLASSFISH-2707] NPE if res-type element missing Created: 26/Mar/07  Updated: 06/Jan/11

Status: Open
Project: glassfish
Component/s: verifier
Affects Version/s: 9.1pe
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: edek234 Assignee: Sanjeeb Sahoo
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: 2,707

 Description   

9.1 build b33e-beta

Both verifier and deployment throw NPE when resource-ref element does not
contain res-type element.
1. Schema does not specify this element mandatory, and indeed resource type can
be obtained from JNDI (so maybe this qualifies as a bug?)
2. Even if point 1 is not true, there should be a meaningful message telling why
verifier fails (otherwise it is necessary to look into the glassfish source to
find out what the real problem is)



 Comments   
Comment by Sanjeeb Sahoo [ 26/Mar/07 ]

Accept this as an enhancement request for 9.2

Comment by getaceres [ 07/Nov/08 ]

I tested this bug in Glassfish V2 UR2.
I changed it to DEFECT because it fails even if the type is defined in the
@Resource annotation (explicitly or implicitly since it must default to the
field type).

I have this deployment:

<session>
<ejb-name>TrimBean</ejb-name>
<ejb-class>org.tolven.app.bean.TrimBean</ejb-class>
<resource-ref>
<res-ref-name>queue/adminApp</res-ref-name>
</resource-ref>
</session>

and this in my code:

public class TrimBean implements TrimLocal, TrimRemote {
.............
@Resource(name="queue/adminApp")
private Queue adminAppQueue;

But when I try to deploy it to Glassfish, I get the following error:

Se produjo una excepción en la fase de J2EECjava.lang.NullPointerException
com.sun.enterprise.deployment.backend.IASDeploymentException: Error al cargar
los descriptores de implementación para el módulo [base-tolven] – null
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.explodeArchive(AppDeployer.java:294)
at
com.sun.enterprise.deployment.backend.AppDeployer.deploy(AppDeployer.java:207)
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:279)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:788)
at
com.sun.enterprise.management.deploy.DeployThread.deploy(DeployThread.java:187)
at
com.sun.enterprise.management.deploy.DeployThread.run(DeployThread.java:223)
Caused by: java.lang.NullPointerException
at
com.sun.enterprise.deployment.util.EjbBundleValidator.computeRuntimeDefault(EjbBundleValidator.java:892)
at
com.sun.enterprise.deployment.util.EjbBundleValidator.accept(EjbBundleValidator.java:683)
at
com.sun.enterprise.deployment.EjbDescriptor.visit(EjbDescriptor.java:2101)
at
com.sun.enterprise.deployment.EjbBundleDescriptor.visit(EjbBundleDescriptor.java:734)
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.backend.Deployer.loadDescriptors(Deployer.java:366)
... 11 more

Sorry but I have it in the spanish locale.

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."





Generated at Thu Sep 29 11:38:40 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.