[GLASSFISH-3625] Report non-portable annotation use in code Created: 19/Sep/07  Updated: 06/Mar/12

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

Type: Improvement Priority: Blocker
Reporter: Sanjeeb Sahoo 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: All


Attachments: Text File Bug3625.zip     Text File Bug3625.zip    
Issuezilla Id: 3,625

 Description   

Verifier currently does not report about non-portable annotation usage in the
code. The API scanning facility needs to be improved to scan class data section
that contains annotations. An example of where current verifier does not report
a failure is given below:

@WebService
public class MyServletEndpoint {
@javax.ejb.TransactionAttribute(REQUIRES_NEW) // incorrect use
public void registerUser(String username, String encodedPW)

{ // ... }


}

I think, we need to switch to ASM based API scanning implementation to address
this issue.

Sahoo



 Comments   
Comment by Sanjeeb Sahoo [ 26/May/08 ]

Confirming the issue.

Comment by seemarich [ 05/Jun/08 ]

Created an attachment (id=1537)
New files, old files, patch and a readme

Comment by seemarich [ 14/Jun/08 ]

Created an attachment (id=1558)
Updated patch is attached

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-4148] Verifier should be aware of Java EE 6 specification Created: 10/Feb/08  Updated: 06/Mar/12

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

Type: New Feature Priority: Blocker
Reporter: Sanjeeb Sahoo 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: All


Issuezilla Id: 4,148
Status Whiteboard:

v3-prd-item


 Description   

This is an umbrella RFE. When we write the one-pager, we need to break this down
into multiple manegable RFEs. In a nutshell, verifier needs to be aware of Java
EE 6 rules. At a minimum, it must not flag valid Java EE 6 archive as failures.



 Comments   
Comment by Sanjeeb Sahoo [ 10/Feb/08 ]

Tagged as v3 prd item.

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-11745] add option to clear the verifier-cache Created: 01/Apr/10  Updated: 06/Mar/12

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

Type: Improvement Priority: Critical
Reporter: vince kraemer Assignee: Sanjeeb Sahoo
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,745

 Description   

I have run into this a couple times.

I have a couple different v3 installs that I have updated to include the verifier.

If I run the verifier from install A, then run the verifier from install B, I
end up with some really interesting stack traces... including traces that
indicate that the verifier from install B is looking for jars from install A.

Once I clear the /tmp/verifier-cache, the stack traces go away.

maybe we should add an option to clear this cache... or detect that cache is
invalid and clear it automagically.

I think https://netbeans.org/bugzilla/show_bug.cgi?id=183000 is related to this
invalid cache issue.



 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-7086] Support passing of arguments to underlying JVM Created: 23/Jan/09  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: sekhar 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: All


Issuezilla Id: 7,086

 Description   

When verifier is run on a large ear file (containing about 90 ejb modules)

verifier ear-file

it fails with

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

The exception seems to be generated when generating the reports. So I workted
around this by restricting the reports to failures only like:

verifier -rf ear-file



 Comments   
Comment by sekhar [ 23/Jan/09 ]

A way to pass JVM option to increase the heap size would be nice. Currently,
there seems to be no way to do this short of editing the verifier script in
<glassfish-install>/bin tree.

Comment by Sanjeeb Sahoo [ 17/Sep/09 ]

defect -> enhancement

Comment by Sanjeeb Sahoo [ 17/Sep/09 ]

Changed subject

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-7066] EJB3 bean silently not published if it inherits the Remote interface from a POJO Created: 19/Jan/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: verifier
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: al130959 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: All


Attachments: GZip Archive BeanClassHierarchyTest.tar.gz    
Issuezilla Id: 7,066

 Description   

Consider the following scenario:

@Remote
public interface TheRealRemote {

String sayHello(String name);

}

public class SomeOrdinaryClassImplementingTheRealRemote implements TheRealRemote {

public String sayHello(String name)

{ return "Hello, " + name + "!"; }

}

@Stateless
public class TheRealBean extends SomeOrdinaryClassImplementingTheRealRemote {

}

Using plain Glassfish v2 UR2 b04, the Verifier returns 0 failures, 0 warnings
and 0 errors for the EJB-JAR/EAR containing these classes. Deployment of the EAR
also seems to complete fine without any error messages.

However, the SLSB will not be properly deployed and its Remote interface not be
published into JNDI. Any attempts to call this bean will therefore fail.

But when we change TheRealBean to explicitly, but redundantly state that it
implements TheRealRemote:

@Stateless
public class TheRealBean extends SomeOrdinaryClassImplementingTheRealRemote
implements TheRealRemote {

}

the SLSB deploys fine, its remote interface will be bound to JNDI and the bean
can successfully be called.

The error seems to be that some statical analysis on TheRealBean class fails to
detect that this class implements TheRealRemote indirectly, because it extends
another POJO class that implements it.

This issue has been found in a real-world customer application and was very hard
to debug due to the complete lack of any error messages other than the inability
to look up any Remote interfaces.

The attached NetBeans project contains the full source for a test case EAR.
Running the verifier on the EAR returns no errors, but TheRealRemote will not be
bound into JNDI after deployment. Then add the redundant "implements
TheRealRemote", and everything is fine.

Many thanks in advance for fixing this!



 Comments   
Comment by al130959 [ 19/Jan/09 ]

Created an attachment (id=2226)
Test case containing the scenario for issue #7066

Comment by Alexis MP [ 20/Jan/09 ]

adding myself to CC list

Comment by ksak [ 20/Jan/09 ]

Client views are not inherited through processing of super-classes. They can only be defined directly on
the bean class or through the deployment descriptor. This is an area that has been clarified in the 3.1
spec. See section 4.9.2.1 – Session Bean Superclasses. At best there could be some verifier warning,
though Changing category to verifier.

Comment by al130959 [ 20/Jan/09 ]

Still my question would be:

The EJB 3.0 spec did not make any statements regarding the need to explicitly
include superclass-implemented interfaces in its own interface list. If
implementing parent class interfaces this shall be explicitly handled and
required by the EJB 3.1 spec - then fine from the EJB container point of view.

But in this case I would at least require a mandatory message rejecting a
bean class that has been set up like in my example - it's definitely not a
nice-to have thing to have "at best"....

So please change the Verifier to reject my bean and point to this section for
the reason why - although it will be "interesting" to refuse deployment of an
EJB 3.0 SLSB due to restrictions only being raised for the first time in the EJB
3.1 spec...

Many thanks!

Andreas

Comment by Sanjeeb Sahoo [ 17/Sep/09 ]

As per conventions in verifier project, new assertions are classified as
enhancements. So, marking this issue as an enhancement.

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-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-3266] TagLibrary Descriptor related tests may not be needed any more Created: 27/Jun/07  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo 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: All


Issuezilla Id: 3,266

 Description   

Since verifier now calls JSPC to compile JSPs bundled in a war file, and the
JSPC parses/validates the TLDs, verifier does not have to validate any TLDs any
more. All the following tests might be redundant:
tests/web/TagClassExtendsValidInterface.java
tests/web/TagClassImplementsValidInterface.java
tests/web/TagLibPublicID.java
tests/web/TagNameIsUnique.java
tests/web/Taglib.java
tests/web/TaglibFunctionMethodTest.java
tests/web/TaglibFunctionSignatureIsValid.java
tests/web/TaglibListenerClassExists.java
tests/web/TaglibLocation.java
tests/web/TaglibUri.java

Please check them, and remove if so. This will speed up verifier. More over, we
might be able to remove the use of web/TagLibFactory from verifier.



 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-613] server call for validation only need adjustment Created: 27/Apr/06  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: tware 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: All


Issuezilla Id: 613

 Description   

As of April 20, the entity-persistence module has been changed to delay some of
its initialization until the first EntityManager is created (rather than
initializing at the time the an EntityManagerFactory is created.)

This requires a change to the validation only feature.

Currently the validation only feature just creates and EntityManagerFactory.
It will now have to create an EntityManager in addition.

When this is done, the following code from
EntityManagerFactoryProvider.createContainerEntityManagerFactory should be
changed to remove the check for validation-only (Note, a separate bug will be
filed for a similar task for ddl generation. - when both bugs are fixed, the
call to factory.getServerSession(); should be removed.

// This code has been added to allow validation to occur without
actually calling createEntityManager
if (validationOnly || !ddlGeneration.equalsIgnoreCase(NONE))

{ factory.getServerSession(); }

 Comments   
Comment by tware [ 27/Apr/06 ]

see

https://glassfish.dev.java.net/issues/show_bug.cgi?id=612

for related bug

Comment by marina vatkina [ 03/May/06 ]

Reassigned module and owner

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-209] warning for unimplemented interfaces Created: 31/Jan/06  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: vince kraemer Assignee: va146370
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: Java Archive File Greeter.jar    
Issuezilla Id: 209

 Description   

I created an ejb jar that had one @Stateless class, an @Local and an @Remote
interface.

The @Stateless class implemented the @Local interface and had a method that
matched the signature of the method defined in the @Remote interface [BUT the
class did NOT implement the interface].

if I run the verifier over that ejb-jar, it would be nice to get a warning that
this situation has happened.

The check could be even wider, warning the user that they have an unimplemented
"EJB interface" in their jar. This would probably be computable.



 Comments   
Comment by vince kraemer [ 31/Jan/06 ]

Created an attachment (id=59)
a jar that should generate a warning when verified

Comment by Sanjeeb Sahoo [ 31/Jan/06 ]

Vikas,
If possible, let's address this in 9.0 itself.

Thanks,
Sahoo

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.





[GLASSFISH-121] new assertion: getTransaction() must not be called for JTA entity manager Created: 28/Dec/05  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo 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: All


Issuezilla Id: 121

 Description   

Secion 3.1.1 of Java Persistence API 1.0 PFD says the following:

/**

  • Return the resource-level transaction object.
  • The EntityTransaction instance may be used serially to
  • begin and commit multiple transactions.
  • @return EntityTransaction instance
  • @throws IllegalStateException if invoked on a JTA
  • EntityManager or an EntityManager that has been closed.
    */
    public EntityTransaction getTransaction();

Verifier should report error if a program uses getTransaction() on a JTA entity
manager.



 Comments   
Comment by Sanjeeb Sahoo [ 12/Feb/06 ]

Difficult to do without doing call flow analysis. This should be implemented
inside NB environment. Marking it as an RFE.
– Sahoo

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-825] new assertion: container managed entity manager must be of type JTA Created: 13/Jul/06  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Bhavanishankar
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: Zip Archive issue_825.zip    
Issuezilla Id: 825

 Description   

Persistence spec #5.5 has the following:
A container-managed entity manager must be a JTA entity manager.

In the attached test case, PU called pu1 is defined as RESOURCE_LOCAL, yet an
entity manager for this PU is injected into the EJB. Verifier does not catch
this problem.



 Comments   
Comment by Sanjeeb Sahoo [ 13/Jul/06 ]

Created an attachment (id=312)
run 'verifier app.ear'

Comment by Sanjeeb Sahoo [ 10/Oct/06 ]

Needs to be fixed in 9.1pe. This needs to be fixed in the context of web as well
as EJB applications.

– Sahoo

Comment by Sanjeeb Sahoo [ 08/Feb/07 ]

This is not a bug. marking as an enhancement.

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-703] Verify EL expressions in JSF pages Created: 02/Jun/06  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: cayhorstmann Assignee: Bhavanishankar
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: 703

 Description   

A common error is a typo in an EL expression, such as this one:

<h:inputText value="#

{usre.name}

">

Oops...that should have been user.name.

The error will cause an unpleasant stack trace when the enclosing page is
evaluated.

It would be good to check these in the verifier. Verificaton of a page would
involve:

  • harvesting all bean definitions and resolvers from faces-config.xml and other
    application configuration files
  • building an EL resolver as in the JSF spec section 5.6.1, but without the last
    part (ELResolvers from Application.addELResolver)
  • harvesting all EL expressions in the page
  • feeding them to the resolver and flagging those that fail to resolve as warnings

Unfortunately, due to the dynamic nature of the resolution process, this is not
foolproof, even if all resolvers are known at deployment time.

Still, a warning that an expression could not be statically resolved would be
very useful in many practical cases. It might also influence the next EL spec to
give better support for static checking.



 Comments   
Comment by Sanjeeb Sahoo [ 05/Sep/06 ]

reassign

Comment by Sanjeeb Sahoo [ 05/Sep/06 ]

changed target milestone to 9.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.





[GLASSFISH-4836] Verifier result should be improved in case of missing classes Created: 21/Apr/08  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: mkarg 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: All


Issuezilla Id: 4,836

 Description   

Today I noticed that when a needed class is missing, the verifier "just" prints
a very ugly stack trace:

Error Name :
com.sun.enterprise.tools.verifier.tests.persistence.DefaultProviderVerification
Error Description : java.lang.NoClassDefFoundError: junit/framework/TestCase

at java.lang.ClassLoader.defineClass1(Native Method)

at java.lang.ClassLoader.defineClass(ClassLoader.java:620)

at
com.sun.enterprise.loader.EJBClassLoader$DelegatingClassLoader.findClass(EJBClassLoader.java:1406)

at java.lang.ClassLoader.loadClass(ClassLoader.java:306)

at java.lang.ClassLoader.loadClass(ClassLoader.java:251)

at
oracle.toplink.essentials.ejb.cmp3.persistence.PersistenceUnitProcessor.isEntity(PersistenceUnitProcessor.java:316)

at
oracle.toplink.essentials.ejb.cmp3.persistence.PersistenceUnitProcessor.getEntityClassNamesFromURL(PersistenceUnitProcessor.java:301)

at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.MetadataProcessor.buildEntityClassSetFromAnnotations(MetadataProcessor.java:501)

at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.MetadataProcessor.buildEntityList(MetadataProcessor.java:462)

at
oracle.toplink.essentials.ejb.cmp3.persistence.PersistenceUnitProcessor.processORMetadata(PersistenceUnitProcessor.java:366)

at
oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:607)

at
oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider.createContainerEntityManagerFactory(EntityManagerFactoryProvider.java:244)

at
com.sun.enterprise.tools.verifier.tests.persistence.DefaultProviderVerification.check(DefaultProviderVerification.java:103)

at com.sun.enterprise.tools.verifier.CheckMgr.check(CheckMgr.java:133)

at
com.sun.enterprise.tools.verifier.persistence.PersistenceUnitCheckMgrImpl.check(PersistenceUnitCheckMgrImpl.java:96)

at
com.sun.enterprise.tools.verifier.CheckMgr.checkPersistenceUnits(CheckMgr.java:390)

at
com.sun.enterprise.tools.verifier.ejb.EjbCheckMgrImpl.check(EjbCheckMgrImpl.java:80)

at com.sun.enterprise.tools.verifier.BaseVerifier.verify(BaseVerifier.java:146)

at com.sun.enterprise.tools.verifier.ejb.EjbVerifier.verify(EjbVerifier.java:78)

at
com.sun.enterprise.tools.verifier.VerificationHandler.runVerifier(VerificationHandler.java:236)

at
com.sun.enterprise.tools.verifier.VerificationHandler.verifyArchive(VerificationHandler.java:141)

at com.sun.enterprise.tools.verifier.Verifier.verify(Verifier.java:144)

at com.sun.enterprise.tools.verifier.Verifier.main(Verifier.java:114)

Caused by: java.lang.ClassNotFoundException: junit.framework.TestCase

at
com.sun.enterprise.loader.EJBClassLoader.findClassData(EJBClassLoader.java:737)

at
com.sun.enterprise.loader.EJBClassLoader$DelegatingClassLoader.findClass(EJBClassLoader.java:1376)

at java.lang.ClassLoader.loadClass(ClassLoader.java:306)

at java.lang.ClassLoader.loadClass(ClassLoader.java:251)

at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)

... 23 more

That stack trace was not part of the result, but part of the verfier'S very own
status printout.

It would be great if there would be no stack trace in the veryfier's status
printout, but instead a nice message to be found in the result report (including
the stack trace).



 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-4831] Warnings should be warnings Created: 21/Apr/08  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: mkarg 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: All


Issuezilla Id: 4,831

 Description   

I got the following message from the verifier:

INFO: Verifying: [ Simple ]
WARNUNG: Ignoring the @NamedQuery [Customer.findAll] speci
WARNUNG: Ignoring the @NamedQuery [Customer.ejbSelectAllNa
xists.
WARNUNG: Ignoring the @NamedQuery [Customer.findByName] sp
WARNUNG: Ignoring the @NamedQuery [Customer.ejbSelectFilte
xists.
INFO:

  1. of Failures : 1
  2. of Warnings : 0
  3. of Errors : 0
    INFO: Look in file "Simple.jar.txt" for detailed results.

As you can see, the verifier posts four warnings. But in the result it says:
zero warning. If the programmer doesn't take good care, and just looks for the
number of warnings, he might think that everything is ok. So he will not take
notice of the four warnings.

I would suggest that all warnings are summed up in the warnings sum.



 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-4760] Verifier results in STDOUT instead of file Created: 14/Apr/08  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: mkarg 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: All


Issuezilla Id: 4,760

 Description   

The verifier is a great developer tool, but there is one thing that is really
annoying: It outputs its results into files always. I would be really glad if
the result, either in XML or Plain Text format, would be printed just STDOUT /
STDERR instead of a file. It is much easier to handle for IDEs (as tools
typically output their results in STDOUT) and it is easier for the programmer
when using the tool at the command line.

I would suggest adding two new command line options:

Option 1 switches between output to file and output to STDOUT / STDERR. The
default should be to output to STDOUT / STDERR, as typical with CLI tools.

Option 2 switches between XML and Plain Text output. The default is plain text,
as typical with CLI tools.



 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-4718] Verifier should check names queries for correct QL syntax Created: 10/Apr/08  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: mkarg 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: All


Issuezilla Id: 4,718

 Description   

I just noticed that the GlassFish server contained in Java EE 5 SDK (Sun Java
System Application Server 9.1_01) seems to not check for correct QL syntax of
named queries.

In my particular case, there was a typo: query="SELECTx adr FROM Address adr".

The verifier told me that there are no problems with my entity!

It would be great if the verifier would check for correct QL syntax of named
queries.



 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-1297] Verify Java SE archives that uses JPA Created: 12/Oct/06  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: sherryshen 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: All


Attachments: Zip Archive issue_1297.zip    
Issuezilla Id: 1,297

 Description   

Please add support for verifcation of Java SE archives that uses JPA.

The work around is to turn Java SE jar to an appclient jar
by just having a manifest with Main-Class attribute in it.
The attached test case shows this workaround with usage, e.g.
javac -classpath $S1AS_HOME/lib/javaee.jar *.java
jar cvfm client.jar manifest *.class META-INF/persistence.xml
verifier -p client.jar
Look at result in the file called client.jar.txt.



 Comments   
Comment by sherryshen [ 12/Oct/06 ]

Created an attachment (id=503)
Testcase with README

Comment by marina vatkina [ 12/Oct/06 ]

It's in the verifier

Comment by sherryshen [ 19/Oct/06 ]

More examples of the workaround of JavaSE verifier are in issue 499 or issue 1294.

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-1065] verifier does not show error for Lob/Id field Created: 01/Sep/06  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: raccah 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: All


Issuezilla Id: 1,065

 Description   

I have a class which does not cause a verifier error. It should because Lob Id
on the same field is not allowed:

@Id
@Lob
@Column(name = "GENRE", nullable = false)
private Object genre;



 Comments   
Comment by Sanjeeb Sahoo [ 09/Feb/07 ]

Marking as an enhancement.

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-3845] Standalone verifier needs a domain named 'domain1' Created: 07/Nov/07  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: olafos 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: All


Issuezilla Id: 3,845

 Description   

When running standalone verifier, and there's no domain named 'domain1' the
verifier throws java.lang.NullPointerException.



 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-17123] Parsing verifier options failed Created: 28/Jul/11  Updated: 13/Feb/13

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

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

Operating System: Windows 7(64bit)


Tags: 3_1_x-exclude

 Description   

I can execute verifier.bat normally if I don't specify any options.
verifier $

{archiveName}

However verifier with any options always seems to fail except for --version and --help.
(Note that I translated some labels such as "Fatal" of command results into the corresponding English words when I wrote the following description because they were originally output as Japanese.)
I show the Case1 - Case 4 to explain this.

Case1) This is the same command as described in help description (--help).
verifier -v -ra -d ${absolutePathToResultDir} ${archiveName}

2011/07/28 16:56:30 com.sun.enterprise.tools.verifier.Initializer parseArgs
Detailed Level (Low): Setting verbose flag to TRUE.
2011/07/28 16:56:30 com.sun.enterprise.tools.verifier.Initializer parseArgs
Fatal: verifier: option [ - ] is not valid.
2011/07/28 16:56:30 com.sun.enterprise.tools.verifier.Initializer usage
Info:
usage: verifier [optional_params] <jarFile>

Case2) This command also returns the same results as Case 1. Parsing "-ra" doesn't work normally.
verifier -v -ra

Case3) This command seems to return collect result because I didn't specify any archives,
but I cannot find this usage in help description (--help).
verifier -vra

2011/07/28 17:08:54 com.sun.enterprise.tools.verifier.Initializer parseArgs
Detailed Level (Low): Setting verbose flag to TRUE.
2011/07/28 17:08:54 com.sun.enterprise.tools.verifier.Initializer setReportingLevel
Detailed Level (Low): Setting output report level to display all results.
2011/07/28 17:08:54 com.sun.enterprise.tools.verifier.Initializer parseArgs
Fatal: verifier: no <jarfilename> specified on command line.
2011/07/28 17:08:54 com.sun.enterprise.tools.verifier.Initializer usage
Info:
usage: verifier [optional_params] <jarFile>

Case4) In this case, the string of "a $

{archiveName}" was parsed as the reporting level wrongly.
verifier -vra ${archiveName}

2011/07/28 17:13:48 com.sun.enterprise.tools.verifier.Initializer parseArgs
Detailed Level (Low): Setting verbose flag to TRUE.
2011/07/28 17:13:48 com.sun.enterprise.tools.verifier.Initializer parseArgs
Fatal: verifier: missing argument for -r or unknown reporting level [ a $

{archiveName}

].
2011/07/28 17:13:48 com.sun.enterprise.tools.verifier.Initializer usage
Info:
usage: verifier [optional_params] <jarFile>

Note that I set up verifier on GFv3.2(r47843) in the following order to use verifier functionality.
1. unzip trunk/v3/packager/glassfish-verifier/target/glassfish-verifier.zip and copy it to glassfish3 dir.
2. get glassfish-javahelp-3.2-SNAPSHOT.zip from maven repo and copy javahelp.jar to glassfish3/glassfish/lib



 Comments   
Comment by Sanjeeb Sahoo [ 20/Oct/11 ]

Will fix it in 4.0 where the bug is reported.





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

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

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

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: build, maven, proprietary-api, verifier, warning

 Description   

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






[GLASSFISH-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-15111] debug(?) messages printed by verifier Created: 11/Dec/10  Updated: 11/Mar/13

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

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

WinXP


Attachments: File ExitTestAppClient.ear     File isdebug3.ear    

 Description   

The first two messages (about parsing domain.xml performance, user doesn't care - they're GF internals, and jdbc driver not being available, not relevant when using verifier) should be suppressed.

D:\tests\GFv3.1\glassfish-3.1-b33-12_10_2010\glassfish3\glassfish>bin\verifier d:\shared\JavaEE\ExitTestAppClient.ear
INFO: Total time to parse domain.xml: 101 milliseconds
INFO: Cannot find javadb client jar file, derby jdbc driver will not be available by default.
INFO: Verifying: [ d:\shared\JavaEE\ExitTestAppClient.ear ]
WARNING: setRuntimeDDPresent method not implemented
INFO: Verifying: [ ExitTestEjb_jar ]
WARNING: setRuntimeDDPresent method not implemented
INFO: Verifying: [ Client_jar ]
WARNING: setRuntimeDDPresent method not implemented
INFO:

  1. of Failures : 0
  2. of Warnings : 0
  3. of Errors : 0
    INFO: No errors found in the archive.


 Comments   
Comment by Dies Koper [ 11/Dec/10 ]

This test app shows more internal message:

Visiting non-standard Signature object

and an exception with stacktrace about a container class's method being missing.
Note that only "WARNING: DPL8007: Unsupported deployment descriptors element resource-adapter-mid value testra" is expected as the app's sun-ejb-jar.xml has a tag defined on a session bean which only applies to MDBs.

Comment by Sanjeeb Sahoo [ 11/Dec/10 ]

Since those warning and info message does not appear in the final report, I don't think it is a serious issue and indeed the submitter has already classified it as a MINOR issue. So, targeting it for 4.0.





[GLASSFISH-15110] unclear warning "setRuntimeDDPresent method not implemented" from verifier Created: 11/Dec/10  Updated: 11/Mar/13

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

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

Windows XP


Attachments: File is_classloader-web.war    

 Description   

Check the output from the verifier. Am I supposed to implement a "setRuntimeDDPresent" method somewhere to make my application Java EE compliant?? That's the impression the tool is giving.

D:\tests\GFv3.1\glassfish-3.1-b33-12_10_2010\glassfish3\glassfish>bin\verifier d:\shared\JavaEE\ExitTestAppClient.ear
INFO: Total time to parse domain.xml: 101 milliseconds
INFO: Cannot find javadb client jar file, derby jdbc driver will not be available by default.
INFO: Verifying: [ d:\shared\JavaEE\ExitTestAppClient.ear ]
WARNING: setRuntimeDDPresent method not implemented
INFO: Verifying: [ ExitTestEjb_jar ]
WARNING: setRuntimeDDPresent method not implemented
INFO: Verifying: [ Client_jar ]
WARNING: setRuntimeDDPresent method not implemented
INFO:

  1. of Failures : 0
  2. of Warnings : 0
  3. of Errors : 0
    INFO: No errors found in the archive.


 Comments   
Comment by Dies Koper [ 11/Dec/10 ]

Ah, I accidentally attached a different test app. But this app gives the same message.
(Note that the error about the missing class is expected. It's just that that should have been the only error displayed.)

Comment by Sanjeeb Sahoo [ 11/Dec/10 ]

Since those warning and info message do not appear in the final report, I don't think it is a serious issue and indeed the submitter has already classified it as a MINOR issue. So, targeting it for 4.0. 3.1 is pretty close to release date and 3.2 will probably have different release requirement.





[GLASSFISH-5510] EJBClassPathUtils.getApplicationClassPath gives NPE Created: 15/Aug/08  Updated: 06/Mar/12

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

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

Operating System: SunOS
Platform: All


Issuezilla Id: 5,510
Status Whiteboard:

gfv3-prelude-excluded


 Description   

Standalone verifier of Resource Adapter gives Exception.
getApplicationClassPath call method on not initialized application.

Error Name : Could not verify successfully.
Error Description : java.lang.NullPointerException
at
com.sun.enterprise.loader.EJBClassPathUtils.getApplicationClassPath(EJBClassPathUtils.java:238)
at
com.sun.enterprise.tools.verifier.VerificationHandler.getEarClassLoader(VerificationHandler.java:405)
at
com.sun.enterprise.tools.verifier.VerificationHandler.createApplicationDescriptor0(VerificationHandler.java:450)
at
com.sun.enterprise.tools.verifier.VerificationHandler.createApplicationDescriptor(VerificationHandler.java:265)
at
com.sun.enterprise.tools.verifier.VerificationHandler.initStandalone(VerificationHandler.java:216)
at
com.sun.enterprise.tools.verifier.VerificationHandler.<init>(VerificationHandler.java:109)
at com.sun.enterprise.tools.verifier.Verifier.verify(Verifier.java:186)



 Comments   
Comment by Hong Zhang [ 15/Aug/08 ]

Can you please provide more information? Please attach a test case and also
provide the build number you were using so we could reproduce the problem.

Assign to verifier team to follow up on this.

Comment by Sanjeeb Sahoo [ 02/Sep/08 ]

Exclude from v3-prelude

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 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-5290] Verifier produces messages with wrong references to EJB specification Created: 10/Jul/08  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: pslechta 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: All


Issuezilla Id: 5,290

 Description   

Please see NetBeans issue http://www.netbeans.org/issues/show_bug.cgi?id=129366
Verifier reported some errors, but reference to specification is wrong (non
existing section numbers, section numbers are shifted).

Also some link to specification should be part of the error message, so the user
may easily download it.



 Comments   
Comment by sanandal [ 11/Jan/09 ]

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

Comment by 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-3576] Verifier uses TopLink essentials to verify application that uses Hibernate Created: 02/Sep/07  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: hadrabap Assignee: Sanjeeb Sahoo
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: 3,576

 Description   

When deploying application conatining Entity Beans that are intended for Hibernate (that is correctly
installed under GlassFish) with the "Verify" deploy option, verifier uses TopLink Essentials to verify the
applications that runs into Exceptions about unsupported features and breaks the deploy. My GlassFish
version is GlassFish V2 b58b.



 Comments   
Comment by Dhiru Pandey [ 02/Sep/07 ]

Not a release stopper for 9.1. Targeted for next release 9.1peur1

Comment by gfbugbridge [ 02/Sep/07 ]

<BT6600182>

Comment by Sanjeeb Sahoo [ 02/Sep/07 ]

The behavior you are observing is by design. Verifier always uses GlassFish's
default persistence provider, TopLink Essentials, to verify JPA entities. What
kind of errors are being reported in your case?

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-3556] [V2 RC4] Will not validate a simple jsp file Created: 29/Aug/07  Updated: 06/Mar/12

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

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

Operating System: other
Platform: PC


Issuezilla Id: 3,556

 Description   

Vista 64, GlassFish V2 RC4

Throwing exceptions during validation of a simple jsp.

I have a working web application. All I change is the web.xml from BASIC auth to
FORM, with...

<login-config>
<auth-method>FORM</auth-method>
<realm-name>grenade</realm-name>
<form-login-config>
<form-login-page>login.jsp</form-login-page>
<form-error-page>fail_login.xhtml</form-error-page>
</form-login-config>
</login-config>

...create a war, and then reload the app. I get...

Deploying application in domain failed; Error loading deployment descriptors for
module [client] Line 80 Column 54 – Deployment descriptor file WEB-INF/web.xml
in archive [client]. cvc-pattern-valid: Value 'login.jsp' is not facet-valid
with respect to pattern '/.*' for type 'null'.

My 'jsp' has no jsp in it...

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title></title>
</head>
<body>
<form method="post" action="j_security_check">
Username: <input type="text" name="j_username"/><br/>
Password: <input type="password" name="j_password"/><br/>
<br/>
<input type="submit" value="Login"/>
<input type="reset" value="Reset"/>
</form>
</body>
</html>



 Comments   
Comment by gfbugbridge [ 29/Aug/07 ]

<BT6599018>

Comment by jluehe [ 30/Aug/07 ]

Please add a leading slash to your form login and error page resources, i.e.,

<form-login-page>/login.jsp</form-login-page>

Verifier error message:

cvc-pattern-valid: Value 'login.jsp' is not facet-valid with respect to
pattern '/.*' for type 'null'

could be improved, though: Not sure why type is "null".

Downgrading to P4.

Comment by dberkman [ 30/Aug/07 ]

Ah, yes, of course. OK, meaningful error message, like 'You forgot the leading
slash dumbass' would be appreciated. Not facet-valid with respect to pattern
'/.*' is a bit baroque, never mind the nice 'null'.

Oh well, thanks for looking at this.

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-1903] Null pointer dereference in com.sun.enterprise.tools.verifier.tests.ejb Created: 04/Jan/07  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: llc 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: All


Issuezilla Id: 1,903

 Description   

Bug type NP_ALWAYS_NULL (click for details)
In class com.sun.enterprise.tools.verifier.tests.ejb.TransactionDemarcationType
In method com.sun.enterprise.tools.verifier.tests.ejb.TransactionDemarcationType.check
(com.sun.enterprise.deployment.EjbDescriptor)
At TransactionDemarcationType.java:[line 87]

Bug type NP_ALWAYS_NULL (click for details)
In class com.sun.enterprise.tools.verifier.tests.web.runtime.ASSessionManager
In method com.sun.enterprise.tools.verifier.tests.web.runtime.ASSessionManager.check
(com.sun.enterprise.deployment.WebBundleDescriptor)
At ASSessionManager.java:[line 75]

Bug type NP_ALWAYS_NULL (click for details)
In class com.sun.enterprise.tools.verifier.tests.web.runtime.ASSessionManager
In method com.sun.enterprise.tools.verifier.tests.web.runtime.ASSessionManager.check
(com.sun.enterprise.deployment.WebBundleDescriptor)
At ASSessionManager.java:[line 85]



 Comments   
Comment by gfbugbridge [ 17/Jan/07 ]

<BT6514431>

Comment by Sanjeeb Sahoo [ 19/Feb/07 ]

Won't fix in V2.

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-616] When verifier fails on deployment, tell me the reason instead of making me run it separately Created: 27/Apr/06  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: cayhorstmann Assignee: Bhavanishankar
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issue Links:
Dependency
blocks GLASSFISH-986 improve weak error messages based on ... Resolved
Issuezilla Id: 616

 Description   

Deploy an app that won't verify with --verify=true
An error message is displayed

An exception occurred while running the command. The exception message is:
CLI171 Command deploy failed : Deploying application in domain failed; Some
verifier tests failed for the given application. Aborting deployment. Please
verify your application using the verifier separately for more details

Elvis hates this. You could

  • display the verifier error message
  • display a message with the location of the verifier results (such as
    domains/domain1/logs/verifier-results/myapp0427052708.xml)
  • copy the report into the current directory, as the verifier would do when it
    is run separately.


 Comments   
Comment by Sanjeeb Sahoo [ 27/Apr/06 ]

Very good suggestion. We shall try to do it in 9.1.

Comment by gfbugbridge [ 26/Jun/06 ]

<BT6443406>

Comment by Sanjeeb Sahoo [ 04/Sep/06 ]

reassigning

Comment by Sanjeeb Sahoo [ 04/Sep/06 ]

Also check if we can report the verifier output to admin console.

Comment by vince kraemer [ 13/Sep/06 ]

error message improvement initiative

Comment by va146370 [ 16/Apr/07 ]

Will not be fixed for V2.

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-568] verifier should ALWAYS report when one module uses classes from another module without using Class-Path manifets entry Created: 12/Apr/06  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: Sanjeeb Sahoo 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: All


Issuezilla Id: 568

 Description   

See the following mail thread. Bill Shannon says verifier should always (not
just in -p mode) report about modules using classes from other module without
using Class-Path mechanism.

Sanjeeb Kumar Sahoo wrote:
>> b. Sahoo: we need to add a verifier test for invalid appclient packaging. We
noticed quite a few incorrectly packaged appclient jar when we were testing our
packaging changes. When the appclient is referencing EJBs, it didn't package the
ejb interfaces inside the jar as expected. Instead it was relying on the ejb jar
that's packaged inside the retrieved appclient jar. We should have a verifier
test catching this if we don't have the test already.
>
> I am assuming you are talking about using appclient packaged inside an ear
file. For such a case, verifier already has this test. To see such failure,
you have to run verifier with -p option. You may be knowing that verifier has
two modes of operation, viz: a) sun-appserver mode (this is the default), b)
portability mode (-p option, always used by AVK product). In the default case,
verifier uses a single ClassLoader for the entire application and allows a
module to use classes from other modules in an ear even when there is no
explicit Class-Path attribute set up in the referencing module's manifest
file. Verifier does this because our appserver also allows the same. So,
verifier does not complain when appclient-jar does not have ejb interface
classes in its classpath. Are you suggesting us to change this behavior of
verifier in sun-appserver mode especially for appclients?
> In portable mode, verifier always uses separate ClassLoader for each module
and uses classes from other modules only when Class-Path manifest is used and
hence will report such missing classes.

There's a difference between explicitly depending on Sun app server
features, and accidentally depending on artifacts of the implementation.
I think the class loader case we're talking about is the latter, and the
verifier should always complain.



 Comments   
Comment by gfbugbridge [ 26/Jun/06 ]

<BTnull>

Comment by Sanjeeb Sahoo [ 09/Feb/07 ]

Won't fix in V2. Changing priority to p4.

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-478] resource injection issue Created: 26/Mar/06  Updated: 06/Mar/12

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

Type: Improvement Priority: Minor
Reporter: vince kraemer Assignee: va146370
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: 478

 Description   

Executive summary:

a Java EE 5 servlet cannot "get" an EJB 2.1 Stateless Session bean injected?
That makes the adoption story kind of hard to tell, doesn't it...

See http://forums.java.net/jive/thread.jspa?threadID=14175&tstart=0 for details.



 Comments   
Comment by ksak [ 27/Mar/06 ]

Could you post the snippet of code showing the @EJB usage? Also please attach the source for the
LocalHome and Local interfaces for the target ejb. My guess from looking at the stack trace would be that
the @EJB is referring to the Local interface instead of LocalHome.

Comment by Hong Zhang [ 27/Mar/06 ]

Will take a look once the user attach the application and source.

Comment by vince kraemer [ 27/Mar/06 ]

The @EJB usage in the servlet

public class NewServlet extends HttpServlet {
@EJB test.NewSessionLocal bean;
//@EJB test.NewSession5Local bean;

Relevant ejb-jar.xml snippit

<session>
<display-name>NewSessionSB</display-name>
<ejb-name>NewSessionBean</ejb-name>
<local-home>test.NewSessionLocalHome</local-home>
<local>test.NewSessionLocal</local>
<ejb-class>test.NewSessionBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>

NewSessionLocal.java

package test;
import javax.ejb.EJBLocalObject;
public interface NewSessionLocal extends EJBLocalObject,
NewSessionLocalBusiness {
}

NewSessionLocalBusiness.java:

package test;
public interface NewSessionLocalBusiness

{ String echo(String par0); }

NewSessionLocalHome.java

package test;
import javax.ejb.CreateException;
import javax.ejb.EJBLocalHome;
public interface NewSessionLocalHome extends EJBLocalHome

{ NewSessionLocal create() throws CreateException; }

Comment by Hong Zhang [ 27/Mar/06 ]

As Ken pointed out, the reference type in @EJB should be local home instead of
local for 2.1 bean.

Please change
@EJB test.NewSessionLocal bean;

to this:
@EJB test.NewSessionLocalHome beanHome;

Let us know how this works out.

Comment by Hong Zhang [ 27/Mar/06 ]

Lower the priority to P4 since this seems like a user-error. Will close the bug
once Vince verifies the local home works for him.

Comment by ksak [ 27/Mar/06 ]

When used with a 2.x (and earlier) remote/local view, @EJB needs to refer to the Home/LocalHome
interface, so this should be :

--> @EJB test.NewSessionLocalHome bean;

Changing to an Enhancement Request for the verifier. It's possible for the verifier to detect this case
since 2.x Remote/Local component interfaces always subtype EJBObject/EJBLocalObject and 3.0 business
interfaces never do.

Comment by vince kraemer [ 27/Mar/06 ]

The exception in the server log should be better, too...

What is the jsr-220 spec x-ref for this advice....

As a user, it is very counter intuitive that I would use the home instead of the
local when injecting a 2.1 bean... For a 3.0 bean, it seems like I am
injectinng the local...

And I don't have to do an explicit create when I inject a 3.0 bean...

Comment by ksak [ 27/Mar/06 ]

>> As a user, it is very counter intuitive that I would use the home instead of the
>> local when injecting a 2.1 bean... For a 3.0 bean, it seems like I am
>> injectinng the local...

>> And I don't have to do an explicit create when I inject a 3.0 bean...

Yes, that's exactly what was wrong with the 2.x view, which is why the 3.0 business
interface was added. Nothing about the 2.x view changed. The 2.x client
programming model is still based on the usage of a Home.

It's covered in the javadoc and the spec. I don't think the tutorial has
any coverage for how to use 2.x beans with @EJB.

Comment by Sanjeeb Sahoo [ 04/Sep/06 ]

Reassigning to Vikas

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.





[GLASSFISH-446] When using Mustang, verifier gets ZipException trying to read JRE optional package Created: 20/Mar/06  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: Sanjeeb Sahoo Assignee: Bhavanishankar
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: Zip Archive Archive.java.zip    
Issuezilla Id: 446

 Description   

java version "1.6.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-beta2-b72)
Java HotSpot(TM) Client VM (build 1.6.0-beta2-b72, mixed mode, sharing)

I tried running verifier using above JDK. When I tried verifying any application
in '-p' mode, verifier console output reports about a ZipException as shown below:

WARNING: DPL5400:Exception occurred : error in opening zip file.
INFO: Verifying: [ build/jpa_acc_option1.ear ]
INFO: Verifying: [ appclient_jar ]
INFO: Ignoring optional pkg
/space/ss141213/software/jdk1.6.0/jre/../jre/lib/ext/meta-index
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:113)
at java.util.jar.JarFile.<init>(JarFile.java:132)
at java.util.jar.JarFile.<init>(JarFile.java:97)
at
com.sun.enterprise.tools.verifier.apiscan.packaging.Archive$1.accept(Archive.java:77)
at java.io.File.listFiles(File.java:1129)
at
com.sun.enterprise.tools.verifier.apiscan.packaging.Archive.getAllOptPkgsInstalledInJRE(Archive.java:73)
at
com.sun.enterprise.tools.verifier.apiscan.packaging.ClassPathBuilder.buildClassPathForEar(ClassPathBuilder.java:244)
at
com.sun.enterprise.tools.verifier.apiscan.packaging.ClassPathBuilder.buildClassPathForEar(ClassPathBuilder.java:235)
at
com.sun.enterprise.tools.verifier.appclient.AppClientVerifier.getClassPath(AppClientVerifier.java:109)
at
com.sun.enterprise.tools.verifier.BaseVerifier.preVerification(BaseVerifier.java:123)
at
com.sun.enterprise.tools.verifier.appclient.AppClientVerifier.verify(AppClientVerifier.java:66)
at
com.sun.enterprise.tools.verifier.VerificationHandler.runVerifier(VerificationHandler.java:223)
at
com.sun.enterprise.tools.verifier.VerificationHandler.verifyArchive(VerificationHandler.java:142)
at com.sun.enterprise.tools.verifier.Verifier.verify(Verifier.java:131)
at com.sun.enterprise.tools.verifier.Verifier.main(Verifier.java:101)
INFO:

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

Needs further investigation as to why the ZipException is coming. More over, the
first WARNING is coming from DOL. Let's ignore that for the moment. We will
files a separate bug against deployment for that WARNING.

– Sahoo



 Comments   
Comment by Sanjeeb Sahoo [ 20/Mar/06 ]

When I looked at the source code, I see that verifier is assuming every file
installed in jre/lib/ext is a jar file. This assumption is not valid in Mustang
as there is a file called jre/lib/ext/meta-index there, which seem to be
containing index information about jars in that folder. So, in our code, we
should try to filter only *.jar files from ext dirs.

Sahoo

Comment by deepasobhana [ 06/Jun/08 ]

Created an attachment (id=1542)
Attaching the patch for this issue

Comment by Sanjeeb Sahoo [ 06/Jun/08 ]
      • Issue 5113 has been marked as a duplicate of this issue. ***
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-783] <BT6416989>verifier failed for @TimeOut methods with tx attribute that are not defined in bean business interfa Created: 26/Jun/06  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: gfbugbridge Assignee: va146370
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: 783

 Description   

<Note> Comments more details at:http://slade.east.sun.com/results/JTReport/cts5_b44_s1as9pe/Verifier/ejb30/verifier-results/index.html</Note><Note> Description Some cts tests failed verifier with such errors: Basically, it wascomplaining about @TimeOut methods with tx attribute are not defined inbusiness interface.My understanding is @TimeOut methods are not defined as business methods,and @TimeOut methods can have tx attributes (required or requires_new). Test Name : tests.ejb.ContainerTransactionStyle3 Test Assertion : The container transaction method must be definedin the home, component, webservice endpoint or business interface(s) ofthe specified enterprise bean. Please refer to EJB 3.0 "Core Contracts andRequirements" Specification Section #12.3 for further information. Test Description : For ejb3_bb_stateless_cm_allowed#ejb3_bb_stateless_cm_allowed_ejb.jar#CallbackAllowedBeanError: Container Transaction method name [ timeout ] not defined in Beaninterface(s). Test Name : tests.ejb.ContainerTransactionStyle3 Test Assertion : The container transaction method must be definedin the home, component, webservice endpoint or business interface(s) ofthe specified enterprise bean. Please refer to EJB 3.0 "Core Contracts andRequirements" Specification Section #12.3 for further information. Test Description : For ejb3_bb_stateless_cm_allowed#ejb3_bb_stateless_cm_allowed_ejb.jar#SessionContextAllowedBeanError: Container Transaction method name [ timeout ] not defined in Beaninterface(s). Test Name : tests.ejb.ContainerTransactionStyle3 Test Assertion : The container transaction method must be definedin the home, component, webservice endpoint or business interface(s) ofthe specified enterprise bean. Please refer to EJB 3.0 "Core Contracts andRequirements" Specification Section #12.3 for further information. Test Description : For ejb3_bb_stateless_cm_allowed#ejb3_bb_stateless_cm_allowed_ejb.jar#AllowedBeanError: Container Transaction method name [ timeout ] not defined in Beaninterface(s).</Note><Note> Evaluation The verifier asserion "tests.ejb.ContainerTransactionStyle3" should be updated for the fix. It checks whether the bean class is assignable from javax.ejb.TimedObject interface. Since 3.0 enterprise beans can also use annotations this check is not correct.</Note><Note> Justification Priority changed from [] to [3-Medium]spec requirmentcheng.fangXXX 2006-04-24 12:47:24 GMT</Note>



 Comments   
Comment by Sanjeeb Sahoo [ 04/Sep/06 ]

reassign

Comment by Sanjeeb Sahoo [ 04/Sep/06 ]

updated target milestone to 9.1pe

Comment by Sanjeeb Sahoo [ 08/Feb/07 ]
      • Issue 2087 has been marked as a duplicate of this issue. ***
Comment by sridatta [ 15/May/07 ]

syncing bugster priority

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.





[GLASSFISH-698] verifier's xml output doesn't conform to dtd Created: 01/Jun/06  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: vince kraemer Assignee: Bhavanishankar
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: 698

 Description   

If I verify an empty ejb jar file, I end up with output that doesn't conform to
the static-verification_1_3_1.dtd or static-verification_1_4.dtd

There are 2 error-name and error-description elements under a single error element.



 Comments   
Comment by gfbugbridge [ 26/Jun/06 ]

<BT6443430>

Comment by Sanjeeb Sahoo [ 04/Sep/06 ]

Also check if we can report the verifier output to admin console.

Comment by Sanjeeb Sahoo [ 04/Sep/06 ]

Bhavani,

Ignore my previous comment which I intended for some other bug. Please look into
this bug for 9.1.

Thanks,
Sahoo

Comment by va146370 [ 18/Apr/07 ]

This issue will not be fixed for V2.

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-4856] Improved warning text Created: 22/Apr/08  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: mkarg Assignee: mkarg
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,856
Status Whiteboard:

v2.1.1_exclude


 Description   

Just got this message:

Exception Description: The @JoinColumns on the annotated element [private
de.quipsy.entities.person.Person de.quipsy.entities.groupuser.GroupUser.usexr]
from the entity class [class de.quipsy.entities.groupuser.GroupUser] is
incomplete. When the source entity class uses a composite primary key, a
@JoinColumn must be specified for each join column using the @JoinColumns. Both
the name and the referenceColumnName elements must be specified in each such
@JoinColumn.

The verifier complains that I am using a composite primary key. In fact, I do
not. My code is using an @Embeddable primary key class, but that class has only
one single non-transient field, so it is not a composite primary key but "just"
an embedded id.

Either the message should be changed to replace the work "composite primary key"
by "@EmbeddableId", or the verifier should just not complain (depending on
whether or not it is correct to complain is this case, since it makes no sense
to have JoinColumnS be used – as there is only ONE JoinColumn).



 Comments   
Comment by mkarg [ 24/Apr/08 ]

I checked the EJB 3.0 Persistence specification, and in chapter "9.1.6
JoinColumn Annotation" it says:

"If there is more than one join column, a JoinColumn annotation must be
specified for each join column using the JoinColumns annotation. Both the name
and the referencedColumnName elements must be specified in each such JoinColumn
annotation."

"(Optional) ... (Default only applies if single join column is being used.) The
same name as the primary key column of the referenced table."

The specification clearly says that it is solely about the number of join
columns ("single join column", "more than one join column") not about whether
that single column is inside of the entity itself or whether it is a
@EmbeddedId. That means, that the verifier does a failure when asking for
referencedColumnName to be specified in my case.

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 P2 according to
https://glassfish.dev.java.net/public/IssueTrackerPriority.html as this is a
violation of the JPA specification. As I mentioned in my comments on April 25, 2008:

The specification clearly says that it is solely about the number of join
columns ("single join column", "more than one join column") not about whether
that single column is inside of the entity itself or whether it is a
@EmbeddedId. That means, that the verifier does a failure when asking for
referencedColumnName to be specified in my case.

Comment by Sanjeeb Sahoo [ 19/Sep/09 ]

Please attach a test case and assign the issue back to me.

Comment by mkarg [ 25/Sep/09 ]

Requested test case will get provided in October.

Comment by Ed Bratt [ 15/Oct/09 ]

Will not fix in v2.1.1

Comment by mkarg [ 25/Jul/11 ]

Sorry for not answering for so long time, but we had lots of other things to do.

Here is how to reproduce the problem:

Entity X references Entity Y using a column named "foo". Since the column has a different name ("foo") than the Java variable ("y"), the annotation @JoinColumn is used to specify that column name:

@Entity public class X

{ @Id private int id; @ManyToOne @JoinColumn(name = "foo") private Y y; }

Entity Y is (for design reasons) not using @Id but @EmbeddedId:

@Entity
public class Y

{ @EmbeddedId private YPK pk; }

The primary key class YPK looks like this:

@Embeddable public class YPK

{ private int id; }

Obviously this is a primary key class, but it is not NOT a COMPOUND key. All code is compliant to the JPA 1.0 and 2.0 specifications. A JPA provider should find all information needed since it is either explicitly provided or can be found implicitly.

But what TopLink did and what EclipseLink still does is to complain:

Exception [EclipseLink-7220] (Eclipse Persistence Services - 2.3.0.v20110604-r9504): org.eclipse.persistence.exceptions.ValidationException
Exception Description: The @JoinColumns on the annotated element [field y] from the entity class [class entities.X] is incomplete. When the source entity class uses a composite primary key, a @JoinColumn must be specified for each join column using the @JoinColumns. Both the name and the referencedColumnName elements must be specified in each such @JoinColumn.

This is just ridiculous and false. The @JoinColumns (look at the trailing s!) is not incomplete, as it is not provided at all. The source entity class is NOT using a composite primary key, so the need for referencedColumn name is NOT given.

This is a violation of the JPA specification, as it enforces referencedColumnName not only for COMPOUND keys (as per the spec) but also for SINGLE-COLUMN-EMBEDDED-KEYS (as NOT per the spec). Such, the application will run on other JPA providers, but enforces a source code change to run on EclipseLink. This breaks WORA and thus is inacceptable for ISVs.

Either change the JPA specification to clearly mandate that referenceColumnName is to be used for SINGLE-COLUMN-EMBEDDED-KEYS in addition to COMPOUND keys, OR fix EclipseLink to not complain about this. But in any case, you must change the text of the error message as it says the @JoinColumns (look a tht trailins!) annotations would be incomplete – it actually is not given at all, so it cannot be INCOMPLETE.

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-1398] Bad error message for failure in CmpFieldsAccessorExposition test Created: 30/Oct/06  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: wfay 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: All


Issuezilla Id: 1,398

 Description   

Failure reported by verifier:
Test Name : tests.ejb.entity.cmp2.CmpFieldsAccessorExposition
Test Assertion : Set accessor method for primary key fields should not be
exposed in the remote interface.
Test Description : For [ C:\dev\glassfish\glassfish-v2-b22\domains\domain1
\applications\j2ee-modules\ejb-1#PD ]
Error: Primary key field set accessor method [ id ] is exposed through the
remote interface [ ejb.entity.pd.PDLocal ].

The error is correct, I did have a few setXXX methods including setId in my
interface, but it was actually my LOCAL interface (as correctly identified
PDLocal) and not the remote interface PDRemote.

The problem is in LocalStrings.properties and in the test itself. The test does
not really look to see if this is a local or remote interface (extends
EJBLocalObject vs EJBObject) but instead always reports "through the remote
interface".

Ideally this test would determine if it was in fact a local or remote interface
and remote properly. A relatively minor issue but it had me scratching my head
for a while last week!

com.sun.enterprise.tools.verifier.tests.ejb.entity.cmp2.CmpFieldsAccessorExposit
ion.failed=\
Error: Primary key field set accessor method [

{0} ] is exposed through the
remote interface [ {1} ].
com.sun.enterprise.tools.verifier.tests.ejb.entity.cmp2.CmpFieldsAccessorExposit
ion.passed=\
Primary key field set accessor method [ {0}

] is not exposed through the remote
interface [

{1}

].



 Comments   
Comment by gfbugbridge [ 17/Jan/07 ]

<BT6514430>

Comment by Sanjeeb Sahoo [ 19/Feb/07 ]

Won't fix in V2 because CMP is not that important in Java EE stack any more.

– Sahoo

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-1199] JarNotFound test description is incorrect Created: 28/Sep/06  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: Sanjeeb Sahoo 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: All


Issuezilla Id: 1,199

 Description   

As evident from the following output:
"Test Name : tests.persistence.JarNotFound
Test Assertion : All the jar file names specified using <class> element in
persistence.xml should be available in the application."

the description text incorrectly mentioned <class> element instead of <jar-file>
element.

A fix is required in localstrings.properties.

– Sahoo



 Comments   
Comment by gfbugbridge [ 17/Jan/07 ]

<BT6514429>

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-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-4041] Verifier fails to validate sun-ejb-jar.xml against DTD Created: 28/Jan/08  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
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
URL: http://www.nabble.com/forum/ViewPost.jtp?post=15109278&framed=y


Issuezilla Id: 4,041

 Description   

As explained in the forum thread
http://www.nabble.com/forum/ViewPost.jtp?post=15109278&framed=y and in the bug
report 4037, verifier apparently fails to recognize that the sun-ejb-jar.xml is
not compilant with the DTD. I am raising a separate issue against verifier for
this issue to be addressed as 4037 seems to be raised as a bug to fix the dev guide.



 Comments   
Comment by Sivakumar Thyagarajan [ 28/Jan/08 ]

copied mkarg

Comment by Sanjeeb Sahoo [ 10/Feb/08 ]

We shall look into it in v3

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 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-5007] Missing class in standard-apis.xml Created: 12/May/08  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: Sanjeeb Sahoo 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: All


Attachments: Zip Archive standard-apis.xml.zip    
Issuezilla Id: 5,007

 Description   

MappedSuperclass is listed as MappedSupe in standard-apis.xml under
JavaPersistence_1.0 section.



 Comments   
Comment by seemarich [ 13/May/08 ]

Created an attachment (id=1496)
Zip of the patch file

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 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-5006] JavaPersistence_1.0 apis missing from apilist in JavaEE_5 Created: 12/May/08  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: Sanjeeb Sahoo 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: All


Attachments: Zip Archive standard-apis.xml.zip    
Issuezilla Id: 5,006

 Description   

standard-apis.xml does not list JavaPersistence_1.0 under JavaEE_5. It's a bug
that needs to be fixed.



 Comments   
Comment by seemarich [ 13/May/08 ]

Created an attachment (id=1497)
Zip of the patch file

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 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-4991] Classes of declared fields not included in ASM-based closure implementation Created: 05/May/08  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: seemarich 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: All


Issuezilla Id: 4,991

 Description   

In the ASM-based closure implementation, the owning classes of referenced
methods are included. But I think the classes of the declared fields are not
included.

1. Enable ASM-based binary verification in the Glassfish Verifier by setting
the system property "apiscan.ClassFileLoader" to the
value "com.sun.enterprise.tools.verifier.apiscan.classfile.ASMClassFileLoader"

2. Verify a Java EE archive file using the verifier. The archive includes a
class which has an unused instance variable of a non-portable class.

The Verifier does not detect the non-portable class that has been declared.



 Comments   
Comment by sanandal [ 11/Jan/09 ]

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

Comment by 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-4990] UnsupportedOperationException is logged in the verification results when using ASM for binary verification Created: 05/May/08  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: seemarich 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: All


Attachments: Text File Bug4990.zip    
Issuezilla Id: 4,990

 Description   

1. Enable ASM-based binary verification in the Glassfish Verifier by setting
the system property "apiscan.ClassFileLoader" to the
value "com.sun.enterprise.tools.verifier.apiscan.classfile.ASMClassFileLoader"

2. Verify a Java EE archive file using the verifier

It causes the following exception to be logged into the verification results.

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

Error Name :
com.sun.enterprise.tools.verifier.tests.ClassContainsNativeMethod
Error Description : java.lang.UnsupportedOperationException

at
com.sun.enterprise.tools.verifier.apiscan.classfile.ClosureCompilerImplBase.getN
ativeMethods(ClosureCompilerImplBase.java:146)

at
com.sun.enterprise.tools.verifier.apiscan.classfile.ClosureCompilerImpl.getNativ
eMethods(ClosureCompilerImpl.java:206)

at
com.sun.enterprise.tools.verifier.tests.ClassContainsNativeMethod.check
(ClassContainsNativeMethod.java:58)

at com.sun.enterprise.tools.verifier.CheckMgr.check(CheckMgr.java:133)

at com.sun.enterprise.tools.verifier.web.WebCheckMgrImpl.check
(WebCheckMgrImpl.java:118)

at com.sun.enterprise.tools.verifier.BaseVerifier.verify
(BaseVerifier.java:146)

at com.sun.enterprise.tools.verifier.web.WebVerifier.verify
(WebVerifier.java:92)

at com.sun.enterprise.tools.verifier.VerificationHandler.runVerifier
(VerificationHandler.java:236)

at com.sun.enterprise.tools.verifier.VerificationHandler.verifyArchive
(VerificationHandler.java:147)

at com.sun.enterprise.tools.verifier.Verifier.verify(Verifier.java:144)

at com.sun.enterprise.tools.verifier.Verifier.main(Verifier.java:114)



 Comments   
Comment by Sanjeeb Sahoo [ 14/May/08 ]

Confirmed as a bug.

Comment by seemarich [ 05/Jun/08 ]

Created an attachment (id=1536)
Changed class, old version of the class, cvs patch and a readme

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





[GLASSFISH-1049] cannot verify nb ejb module project for java ee 5 Created: 30/Aug/06  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: raccah 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: All


Attachments: Java Archive File EJBModule2.jar    
Issue Links:
Dependency
blocks GLASSFISH-986 improve weak error messages based on ... Resolved
blocks GLASSFISH-897 Improve error message for deployment Resolved
Issuezilla Id: 1,049

 Description   

Here's what I did in NB 5.5 daily build:
new ejb module proj (java ee 5, glassfish)
paste dbschema into src/conf
new entity beans from db
verify project

Could not verify successfully.
java.io.IOException: Cannot determine the Java EE module type for
/tmp/EJBModule2/dist/EJBModule2.jar
at
com.sun.enterprise.deployment.archivist.PluggableArchivistsHelper.getArchivistForArchive(PluggableArchivistsHelper.java:124)
at
com.sun.enterprise.deployment.archivist.PluggableArchivistsHelper.getArchivistForArchive(PluggableArchivistsHelper.java:85)
at
com.sun.enterprise.deployment.archivist.PluggableArchivistsHelper.getArchivistForArchive(PluggableArchivistsHelper.java:97)
at
com.sun.enterprise.deployment.archivist.ArchivistFactory.getArchivistForArchive(ArchivistFactory.java:84)
at
com.sun.enterprise.tools.verifier.VerificationHandler.initStandalone(VerificationHandler.java:191)
at
com.sun.enterprise.tools.verifier.VerificationHandler.<init>(VerificationHandler.java:96)
at com.sun.enterprise.tools.verifier.Verifier.verify(Verifier.java:127)
at com.sun.enterprise.tools.verifier.Verifier.main(Verifier.java:101)



 Comments   
Comment by raccah [ 30/Aug/06 ]

wrong java ee number in subject - correcting

Comment by vince kraemer [ 30/Aug/06 ]

...

Comment by Sanjeeb Sahoo [ 30/Aug/06 ]

Is there an ejb-jar.xml in EJBModule2.jar? A jar file is a valid EJB type module
if it either has an ejb-jar.xml or some Java class annotated as @Stateless or
@Stateful.

Thanks,
Sahoo

Comment by raccah [ 31/Aug/06 ]

No, there is not.

Comment by raccah [ 31/Aug/06 ]

If I add a stateless session bean into the project, the verifier succeeds. But,
there's still no ejb-jar.xml.

Comment by marina vatkina [ 31/Aug/06 ]

Can you attach the jar?

Comment by raccah [ 31/Aug/06 ]

Created an attachment (id=411)
jar file that has verifier error

Comment by marina vatkina [ 31/Aug/06 ]

Do original classes in this jar have any class level annotations?

Comment by raccah [ 31/Aug/06 ]

Yes, @Entity, @Table, @NamedQueries

Comment by marina vatkina [ 31/Aug/06 ]

The attached jar has 2 sets of classes that are called NewSession... do they
have any kind of annotations?

This jar is not a PU either - there is no persistence.xml in it. I'm not sure
what is the expectation of running a verifier on an arbitrary jar.

Comment by raccah [ 31/Aug/06 ]

I spoke to Vince and I get the same problem if I just create a new project and
then verify it. It has to do with the lack of any ejbs in a project I said was
an ejb module and nothing to do with the fact that I have regular java classes
or JPA entity classes in there.

The fix should be for the error message to actually tell me what's wrong.

Comment by Sanjeeb Sahoo [ 31/Aug/06 ]

A message like "no -ejb-jar found and no class with ejb annotation found" will
be helpful to user to diagnose the problem. Marking it a P4 as it's a ease of
use type of bug. Transferring this bug to deployment team who is responsible for
reporting that error.
It has been reported several times to NB team that NB is not generating valid
ejb-jar files. Sometimes it generates ejb-jar with empty ejb-jar.xml (see
http://www.netbeans.org/issues/show_bug.cgi?id=50323), sometimes with no
ejb-jar.xml (this case). While NB team can get this bug fixed in GlassFish, they
may not have that much say in other appserver environment. So, NB team should
solve this problem at their end as well.

– Sahoo

Comment by vince kraemer [ 31/Aug/06 ]

...

Comment by raccah [ 07/Sep/06 ]

<https://glassfish.dev.java.net/public/IssueTrackerPriority.html>

I think this is more than a minor usability error - I really had no idea what
was wrong. That's why I still think it's P3.

As for solving it on the NB side - I added a link to this issue in the NB bug
you referenced.

Comment by Hong Zhang [ 27/Aug/09 ]

-> verifier

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-2088] <BT6421228>Remove all AVK instrumentation code from appserver code Created: 17/Jan/07  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: gfbugbridge 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: All


Issuezilla Id: 2,088

 Description   

*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6421228
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6421228
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description Starting with rel 5, AVK uses callflow tracing mechanism to profile user's application. So we do not need the AVK specific intrumentation code that was added in appserver any more.
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description The following package can be removed from appserv-core:com.sun.enterprise.appverification.factory.
Any code that references this package can also be removed.

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to [3-Medium]This will also clean up the appserver XXXXXX 2006-05-03 14:34:11 GMT

Priority changed from [3-Medium] to [4-Low]
nice to XXXXXX 2006-05-03 14:54:17 GMT

**********READ-ONLY Data from Bugtraq Ends********



 Comments   
Comment by gfbugbridge [ 24/Jan/07 ]

*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6421228
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6421228
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description Starting with rel 5, AVK uses callflow tracing mechanism to profile user's application. So we do not need the AVK specific intrumentation code that was added in appserver any more.
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description The following package can be removed from appserv-core:com.sun.enterprise.appverification.factory.
Any code that references this package can also be removed.

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to [3-Medium]This will also clean up the appserver XXXXXX 2006-05-03 14:34:11 GMT

Priority changed from [3-Medium] to [4-Low]
nice to XXXXXX 2006-05-03 14:54:17 GMT

**********READ-ONLY Data from Bugtraq Ends********

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





Generated at Fri Mar 27 21:53:54 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.