[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-1778] <BT6352690>JBI Service Enigine:Newly deployed endpoints should not be activated in JBI after SE uninstallation Created: 15/Dec/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jbi
Affects Version/s: 9.1pe
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: 1,778

 Description   

*********READ-ONLY Data from Bugtraq*********************
Description Make sure that SE has started Uninstall SE
Deploy web service(s)

Notice debug statements in server.log indicating activation of new web service endpoints in JBI environment.

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Evaluation The service engine jar file is not in the classpath of application server. It is loaded by Shasta. It appears that the classes are not really unloaded during undeployment. In any case, we should semantics to BootStrapContext and block the endpoints from getting activated. Basically JavaEEServiceEngineBootstrap.onUnInstall can have a flag set to indicate that the service engine is getting uninstalled.
Core logic of the service engine should discontinue or disable all activity when the flag is set.

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to [2-High]After uninstallation of service engine, new web service deployments should not result in activation of endpoints in XXXXXX 2005-11-18 08:17:41 GMT

Priority changed from [2-High] to [3-Medium]
Ideally user never have to uninstall the serviceengine manually. So, this is not a XXXXXX 2005-12-16 10:43:42 GMT

Priority changed from [3-Medium] to [4-Low]
Less important compared to others. Will be considered XXXXXX 2006-03-15 02:34:36 GMT

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6352690
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6352690
**********READ-ONLY Data from Bugtraq Ends********



 Comments   
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-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-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-2063] Missing resource bundles for French locale Created: 14/Jan/07  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: Alexis MP 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: 2,063

 Description   

GF 2 b31 on Windows with French Locale

[#|2007-01-15T00:11:45.078+0100|WARNING|sun-appserver9.1|com.sun.enterprise.jbi.serviceengine.core|_ThreadID=12;_ThreadName=JavaEEServiceEngine;_RequestID=2bd3fcc1-ba23-4ed9-af57-3f2bd08e0861;|Unable
to load resource bundle com.sun.enterprise.jbi.serviceengine.core.LocalStrings
for locale fr_FR: java.util.MissingResourceException: Can't find bundle for base
name com.sun.enterprise.jbi.serviceengine.core.LocalStrings, locale fr_FR|#]

[#|2007-01-15T00:11:45.078+0100|WARNING|sun-appserver9.1|com.sun.enterprise.jbi.serviceengine.core|_ThreadID=12;_ThreadName=JavaEEServiceEngine;_RequestID=2bd3fcc1-ba23-4ed9-af57-3f2bd08e0861;|Using
resource bundle for locale en_US instead.|#]



 Comments   
Comment by gfbugbridge [ 18/Jan/07 ]

<BT6514968>

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.





Generated at Wed Jul 29 07:48:05 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.