[THUCYDIDES-172] @Title annotation suppresses step parameters Created: 29/May/13  Updated: 06/May/14  Resolved: 11/Aug/13

Status: Resolved
Project: thucydides
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: polisha Assignee: johnsmart
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, 0.9.88


Tags: annotation, title

 Description   

Disclaimer: Now I have to use 0.9.88 version of Thucydides, and upgrade to the latest one is coming, so maybe this problem is already fixed.

I use the @Title annotation for test methods and test steps and it suppresses step parameters in the reports. At the same time test parameters are shown correctly if the test is parameterized.



 Comments   
Comment by johnsmart [ 08/Jun/13 ]

Use the @Step annotation directly, e.g.

@Step("a step about a person called

{0}

, aged

{1}

")
public void a_customized_step_with_two_parameters(String name, int age)

{..}
Comment by pavlo [ 06/May/14 ]

Thanks for this tip
Unfortunately this is not documented anywhere
Also unfortunately, this is not working with @StepGroup annotation

Comment by johnsmart [ 06/May/14 ]

The @StepGroup annotation is deprecated - you can now just use the @Step annotation at any level (@Step methods can call other @Step methods).





[OZARK-47] Need test for method annotation inheritance Created: 03/Jun/15  Updated: 07/Aug/15  Resolved: 07/Aug/15

Status: Closed
Project: ozark
Component/s: None
Affects Version/s: 1.0.0-m02
Fix Version/s: 1.0.0-m02

Type: Task Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Santiago Pericas-Geertsen
Resolution: Fixed Votes: 0
Labels: annotation, inheritance
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: annotation, inheritance

 Description   

We need a test for annotation inheritance according to the JAX-RS rules. See util.AnnotationUtils.



 Comments   
Comment by Santiago Pericas-Geertsen [ 07/Aug/15 ]

Tested.





[OZARK-45] Ensure method annotation inheritance is compatible with JAX-RS Created: 02/Jun/15  Updated: 05/Oct/15  Resolved: 03/Jun/15

Status: Closed
Project: ozark
Component/s: None
Affects Version/s: 1.0.0-m01
Fix Version/s: 1.0.0-m02

Type: Task Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Santiago Pericas-Geertsen
Resolution: Fixed Votes: 0
Labels: annotation, inheritance
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: annotation, inheritance

 Description   

The rules related to method inheritance from JAX-RS should be respected. When looking up a method's annotation, methods on base classes may need to be inspected.



 Comments   
Comment by Santiago Pericas-Geertsen [ 03/Jun/15 ]

New utility class written for annotation scanning. Needs more testing, but a new JIRA will be filed for that.





[MVC_SPEC-43] Section about annotation inheritance Created: 03/Jun/15  Updated: 31/Jul/15  Resolved: 31/Jul/15

Status: Closed
Project: mvc-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0-edr2

Type: Task Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Santiago Pericas-Geertsen
Resolution: Fixed Votes: 0
Labels: annotation, inheritance
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: annotation, inheritance

 Description   

We need a section that describes annotation inheritance in accordance to the JAX-RS rules.



 Comments   
Comment by Santiago Pericas-Geertsen [ 31/Jul/15 ]

Done.





[JERSEY-2167] Injecting a custom parameter type causes REST method to run twice Created: 24/Oct/13  Updated: 10/Sep/15  Resolved: 31/Jan/14

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.3.1
Fix Version/s: 2.6

Type: Bug Priority: Major
Reporter: allanx2000 Assignee: Adam Lindenthal
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 6 hours
Original Estimate: 30 minutes
Environment:

Windows 7


Tags: annotation, hk2, injection

 Description   

I have a method like:

@GET
@Path ...
#Produces ...
public Response get(@MyObjectAnn MyObject object)
{
return Response.ok().build();
}

When a client requests this, it gets run twice; once where object is injected, the other with it being null.



 Comments   
Comment by allanx2000 [ 24/Oct/13 ]

Details:

MyObjectAnn.java
@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
public @interface MyObjectAnn {
}
Binder.java
public class Binder extends AbstractBinder {
    @Override
    protected void configure() {
    	bind(Provider.class)
        	.to(new TypeLiteral<InjectionResolver<MyObjectAnn>>() {})
        	.in(Singleton.class);
   	
    }
}
Provider.java
@Singleton
public class Provider 
implements InjectionResolver<MyObjectAnn> {
	
	@Context
	protected UriInfo URLINFO;
	
	@Context 
	protected Request REQUEST;
	
	@Context 
	protected HttpHeaders HEADERS;

        @Override
	public boolean isConstructorParameterIndicator() {
		return false;
	}

	@Override
	public boolean isMethodParameterIndicator() {
		return true;
	}
AppHost.java
public class AppHost extends ResourceConfig
{
	public AppHost()
	{
		super(
		//Resources/Handlers
		
		JacksonJaxbJsonProvider.class,
		JacksonJsonProvider.class,
		JacksonFeature.class
		);
		
		this.register(new Binder());
		
	}
}
Comment by Marek Potociar [ 10/Dec/13 ]

Please rename the method to something else than "get" as a workaround for now. IMO the injection framework is confused and tries to inject this as a getter.

Comment by allanx2000 [ 10/Dec/13 ]

Maybe... didnt think of that... unfortunately its not that easy to change now that the system pretty much done using a work around. but yea will give it try when i get some time

Comment by Miroslav Fuksa [ 14/Jan/14 ]

Solution could be to fix this issue and not inject this "getter". If the problem is in HK2 then move the bug to HK2.

Comment by allanx2000 [ 30/Jan/14 ]

Thanks. I used a work around where I don't inject any custom parameter types. In request we build these custom objects manually from the Context information. Not as elegant but it works I guess

Comment by allanx2000 [ 30/Jan/14 ]

@Miroslav Fuksa The problem, I remember, is it's not really because of the function name. It worked fine if I remove my custom parameter.

Comment by Adam Lindenthal [ 30/Jan/14 ]

Hi allanx2000,

you are right, it has nothing to do with the function name, but due to the way how you've implemented your InjectionResolver. Setting the isMethodParameterIndicator return value to true causes hk2 to invoke the resource method preliminary and out of Jersey lifecycle.

The second invocation (by Jersey) does not have the parameter injected already.

But just setting the return value to false does not solve the problem. The resource method won't be called twice, but the injection won't work either.

The solution is a bit more complex.
I've prepared a (non)reproducer testcase of this issue, it shows how to do your own custom annotation injection into resource method parameter.

I'll paste here a link as soon as it is on github.

In the meantime, you can check e.g. how QueryParam injection is implemented in Jersey.

Also, instead of using the described workaround, have you considered using a field injection to the resource instead of directly to the method parameter?

Regards,
Adam

Comment by allanx2000 [ 30/Jan/14 ]

Hi Adam,

Actually as you can see this has been here for a long time already. At this point the work around is pretty deeply integrated into the design already and the application is pretty much ready to be released, so I guess it's a bit too late to change now.

I don't think I've tried injecting it as a field. I guess will try that next time.

Comment by Adam Lindenthal [ 30/Jan/14 ]

Hi allanx2000,

I see. Glad, that you've found some viable solution. Anyway, there is a sample on github now, so you can check how to implement it next time.

This is actually not a bug in Jersey, no code changes have been done to make it work, you just have not used the hk2 API properly (but honestly, it is really not obvious from javadoc).

The main difference against your solution is the provider implementation, extending ParamInjectionResolver is not enough. It has to be done like this:
provider

And you also need to change the binding a bit:
binder

The rest remains roughly the same. So if you are doing some refactoring in your project one day, you can remove the workaround and give it a try...

...and also upgrade to the latest Jersey to enjoy all the new features

Best wishes,
Adam





[JAXB2_COMMONS-32] Annotation plugin does not include the project's classpath when annotating generated code Created: 22/May/12  Updated: 24/Dec/15  Resolved: 24/Dec/15

Status: Closed
Project: jaxb2-commons
Component/s: jaxb2-basics
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ioannism Assignee: Unassigned
Resolution: Duplicate Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: annotation, classpath, xjc

 Description   

Given the following annotation (defined in the same project along with ExistingCustomerValidator class )

 
package com.tktserver.constraints;

@Target({ ElementType.TYPE, ElementType.ANNOTATION_TYPE })
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = { ExistingCustomerValidator.class })
@Documented
public @interface ExistingCustomerMatch {
    String message() default "{customer.notfound}";

    Class<?>[] groups() default {};

    Class<? extends Payload>[] payload() default {};

    /**
     * @return The field
     */
    String field();
}

and the following jxb customisation

<jaxb:bindings node="xsd:complexType[@name='customer']">
	<annox:annotate>
		<annox:annotate
			annox:class="com.tktserver.constraints.ExistingCustomerMatch"
			field="electronicUserId" />
	</annox:annotate>
</jaxb:bindings>

I get this when I generate my sources ( it's a Maven project)

Caused by: org.jvnet.annox.annotation.AnnotationClassNotFoundException: Annotation class [com.tktserver.constraints.ExistingCustomerMatch] could not be found.
	... 32 more
Caused by: java.lang.ClassNotFoundException: com.tktserver.constraints.ExistingCustomerMatch
	at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:169)
	at org.jvnet.annox.parser.XAnnotationParser.parse(XAnnotationParser.java:76)
	... 31 more

Other JSR-303 annotations work fine. I believe that the problem lies in the fact that the xjc plugin does not consider the project's classpath and therefore won't compile for Annotations that have class references in the main project. A workaround is to create a separate maven project and use it as a dependency but this is Ugly.



 Comments   
Comment by lexi [ 23/May/12 ]

Thanks for the report.

Comment by ioannism [ 23/May/12 ]

You're welcome, let me know if you need any more info.

Comment by jesseplymale [ 04/Dec/12 ]

I had a similar issue, but the annotations that I was trying to annotate on the JAXB class were not custom annotations that I had defined, but rather just annotations that were from a library (Jackson) that was not part of the Java API. Turns out that Maven was not using the project dependencies (of which Jackson was a part) in the classpath when running XJC via the maven JAXB plugin. When I added a <dependencies> element underneath the <plugin> for the JAXB maven plugin, and added Jackson <dependency> element to that, it worked.

Definitely seems like a shortcoming of the Maven JAXB plugin, that it does not put the project dependencies on its classpath during code generation.

Comment by lexi [ 16/Mar/14 ]

http://jira.highsource.org/browse/JIIB-55

Comment by lexi [ 24/Dec/15 ]

Continued in https://github.com/highsource/jaxb2-annotate-plugin/issues/20.





[JAXB-888] Nullpointer from JAnnotationUse.getAnnotationMembers Created: 05/Mar/12  Updated: 05/Mar/12

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.5
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: AndreasZ Assignee: Martin Grebac
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Tags: Annotation, NPE, Nullpointer

 Description   

Calling JAnnotationUse.getAnnotationMembers before a param is added leads to a NPE because the uninitialized map is passed to Collections.unmodifiableMap(...)

Also See Comments on JAXB-784






[JAX_RS_SPEC-506] Consider using @javax.annotation.Priority Created: 16/Jan/15  Updated: 24/Nov/16

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: annotation, priority
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 2.1-candidate, annotation, priority

 Description   

Instead of JAX-RS' @Priority annotation, which could be deprecated in favor of the common one.






[JAVASERVERFACES_SPEC_PUBLIC-1193] Declaring component attributes via annotations Created: 11/May/13  Updated: 17/Aug/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: arjan tijms Assignee: arjan tijms
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: annotation, annotations, ease-of-use, ease_of_development, no-xml

 Description   

As of JAVASERVERFACES_SPEC_PUBLIC-594, custom components can be declared to be useable in Facelets via the @FacesComponent annotation. Via this it's no longer required to have an entry in a taglib.xml file.

However, if the component author wishes to declare the component's attributes (for documentation, tooling, etc), XML still has to be used.

I therefor would like to propose declaring these attributes via annotations as well.

E.g.

@FacesComponent(value="components.CustomComponent", createTag=true)
public class Foo extends UIComponentBase {

    @Attribute
    String color; // will be injected with getAttributes("color") 

    @Attribute(description="This will determine the ...", required=true)
    String style;

    @Attribute(description="The cost of ... ", default="100")
    Integer cost;

}


 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by c.beikov [ 07/Aug/14 ]

In my opinion the @Attribute annotation should go on an abstract getter and the component class should be declared as abstract. This way you could define reusable behavior in interfaces and inherit these attributes by implementing an interface.
The runtime can just generate an appropriate subclass of a component class that implements those methods. This also gives the implementation flexibility regarding the representation of the data.
If the values of EL expressions are bound to the component instance on creation of the component, how would the component get a changed value if the original EL expression would evaluate to a different value later in the lifecycle?

I implemented an annotation processor that generates these Java classes and XML files based on annotations for me at build time. I think Richfaces did something similar. JSF could just move that process to the runtime.

Comment by Ed Burns [ 17/Aug/15 ]

"Properties" is a hot button topic. It was recently booted out of Java SE 9. This is a decent writeup: http://blog.joda.org/2014/11/no-properties-in-java-language.html





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

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

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

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


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

 Description   

Using the following EAR file:

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

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

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

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

I've attached a JVisualVM profiling file.



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

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

Comment by fmeili [ 05/May/11 ]

Are you sure that the GF 3.1 only scan each jar file once for annotation processing? What we see in the profiling data (see attached file), each jar file is scanned very often. We have 152 jar files in the ./lib directory, but the method addScanURI() is called 8208 times for one EAR deploy task.

In the attached nbs-file you'll see the profile for one EAR deploying. When you open the largest time consuming tree's you'll find that the Method com.sun.enterprise.deployment.annotation.impl.ModuleScanner.addScanURI() is called 5472 times from com.sun.enterprise.deployment.annotation.impl.ModuleScanner.process() and 2736 times from com.sun.enterprise.deployment.annotation.impl.WarScanner.process()). Both are the cpu hot spot points in the profile.

By the way, can you explain me in short why it's necessary to scan the whole ./lib directory for annotations, while deploying an ear?

Thanks for your fast answer,
Frank

Comment by Hong Zhang [ 05/May/11 ]

It's a Java EE platform spec requirement that all classes packaged inside the archive needs to be scanned for annotation. It's not recommended for the library jars to contain component annotations like @EJB etc, but it can include annotation like @ApplicationException.

I am a little surprised to hear that the addScanURI will be invoked so many times, I will look into the code to see what I can find.

Comment by fmeili [ 05/May/11 ]

If it would help you, I can provide you more cpu profiling data, stack traces or something else, please let me know.

Thanks,
Frank

Comment by Hong Zhang [ 05/May/11 ]

Looking at the code, I kind of understand why there will be so many addScanURI calls now.

For each module inside the ear, when we process annotations for that module, we will include the library jars as if the library jars were packaged directly in that module.

So for 152 library jars and 19 wars, you would get 152 x 19 = 2888 from the WarScanner.
And for 18 ejb jars, you would get 152 x 18 = 2736 from the EjbJarScanner.
And then as both classes call its super class ModuleScanner, the ModuleScanner.addScanURI should get called total 5624.

The numbers don't exactly match with your numbers yet, but I guess we know why there could be so many calls.

I still need to figure out why this addScanURI call is expensive, but certainly any method with this many number of calls will take a significant of time.

When we wrote the code, we did not think too much about this type of scenario with so many library jars and module jars. We will think about how to optimize for this type of scenario. Maybe as you said, we can try to cache the results of the library jar matching.

Comment by Hong Zhang [ 05/May/11 ]

I think I understand why the addScanURI is expensive now. It still have references to some old code where we used to scan the class again.

I have seen significant time improvement with a test case I created after I changed this part. I will do more testing and then check in the change to 3.1.1. As the 3.1 has FCSed, any bug fixes can only be made into 3.1.1 or 3.2. I can send you a patch for you to install locally and try too.

You can download 3.1.1 from here http://dlc.sun.com.edgesuite.net/glassfish/3.1.1/
once I check in my change.

Comment by fmeili [ 06/May/11 ]

Ok, good to hear that you've found the problem. I think, it will be helpful for you when I also test the patch locally on my system with our EAR file. Can I download the patch somewhere? Til now, the newest version, at the link you provided in your last message, is glassfish-3.1.1-b04.zip (form 4th May). Will the patch fit to this version?

Comment by Hong Zhang [ 06/May/11 ]

After you install the 3.1.1 build, replace the dol jar in the glassfish3/glassfish/modules directory with this patch dol.jar. Then try to deploy your application to see how much difference it makes.

Comment by Hong Zhang [ 06/May/11 ]

I just attached the patch in the issue. I think it should match with that 3.1.1 build, but if you see any problem, I can provide a patch for the 3.2 too (I plan to backport the change there too). You could do a baseline measurement before you install the patch. And then reinstall the build, and install the patch and see what difference it makes.

Comment by fmeili [ 09/May/11 ]

I've done some tests with the patch you've provided. The deployment time with the dol patch was shrinking from 400 seconds to 170 seconds, which is a big improvement.

Glassfish 3.1.1 b04 original: 400 s
Glassfish 3.1.1 with dol patch: 170 s
Glassfish 2.1.1 b31g-fcs: 40 s

Now the EAR deployment is not longer 10 times slower compared with GF 2.1.1, but is still 4 times slower. I've done some profiling with the dol patch, but sadly I couldn't find an additional single CPU hot spot (like in the version without the dol patch). As far as I can see, the most CPU time get consumed in annotation processing, but not at in a single method. There are a bunch of methods involved. I've attached a profiler snapshot with dol patch active. Maybe you can find something else which may be problematic while deploying.

Thank for your fast response and patch.
Greetings, Frank

Comment by Hong Zhang [ 09/May/11 ]

Frank thanks for verifying the patch! Glad this patch had made big improvement (and thanks again for reporting this and providing the profiling data pointing us to where we could improve significantly). I have checked in the changes into both 3.1.1 branch and the trunk (3.2) now.

For the next step, I will probably take a look to see if we can save the processed results for the libraries and re-use it for each module instead of doing this for each module. But please keep in mind, as we are now additionally processing these library jars while we didn't in 2.1, there will be always time differences compared to 2.1 (especially when the application contains large amount of library jars).

Comment by Hong Zhang [ 18/Oct/11 ]

Could not find any more simple set of the changes which could improve significantly. I am keeping this as a RFE for improvement in future release.

Comment by Hong Zhang [ 10/Oct/12 ]

Scrubbing RFEs for GlassFish 4.0.





[GLASSFISH-15366] Annotation StatefulTimeout dose not work properly when set the value as 0 Created: 28/Dec/10  Updated: 21/Mar/11  Resolved: 21/Mar/11

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: LeonLi Assignee: Cheng Fang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows x86 xp,eclipse+glassfish3


Tags: Annotation, StatefulTimeout

 Description   

F.Y.I
@Remote
public interface StatefulTimeoutRemote {
public String sayHi();
}

/**

  • Session Bean implementation class StatefulTimeoutBean
    */
    @Stateful
    @StatefulTimeout(0)
    public class StatefulTimeoutBean implements StatefulTimeoutRemote {
    public String sayHi() { return "Hello Wolrd!"; }

    }

public class ClientTest {
public static void main(String[] args) {
try

{ Context context = new InitialContext(); StatefulTimeoutRemote s = (StatefulTimeoutRemote) context .lookup("java:global/StatefulTimeout/StatefulTimeoutBean"); System.out.println(s.sayHi()); Thread.sleep(1000); System.out.println(s.sayHi()); }

catch (Exception e)

{ e.printStackTrace(); }

}
}

Expected result:throw a exception.
Acctual result:print two strings"Hello Wolrd!"

As the jee6 spec "A value of 0 means the bean is immediately eligible for removal." so that if I invoke the method in the stateful session bean ,it should throw a exception told can't find the ejb.



 Comments   
Comment by LeonLi [ 28/Dec/10 ]

By the way ,when I set the value as -2, the stateful session bean should not deploy successful, but the result is the same as -1 or 0.

Comment by marina vatkina [ 17/Mar/11 ]

Cheng, please check if we are not spec compliant

Comment by Cheng Fang [ 21/Mar/11 ]

A value of 0 means the bean is immediately eligible for removal, and it is a hint to the container. When and how it is actually removed is up to the container implementation.

-2 is not valid, and it may cause deployment to fail, or a failure at runtime.

Comment by Cheng Fang [ 21/Mar/11 ]

Sending deployment/dol/src/main/java/com/sun/enterprise/deployment/util/EjbBundleValidator.java
Sending deployment/dol/src/main/java/com/sun/enterprise/deployment/util/LocalStrings.properties

Committed revision 45644.





[FABAN-13] Incorrect pre-run delay when parallel thread start is set true Created: 15/May/11  Updated: 17/May/11  Due: 31/May/11  Resolved: 17/May/11

Status: Resolved
Project: faban
Component/s: None
Affects Version/s: None
Fix Version/s: None

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

Solaris 11, JDK 1.6.0_24


Tags: annotation, faban, preprocessing

 Description   

In config.xml, enable parallel thread start <fd:parallel>true</fd:parallel>. Configure number of agents equal to scale (the number of threads). This causes close to infinite long delay before Faban to invoke run() method of driver. In fact, the workload never got to run.

SPECSIPASDriverAgent[0].0: Delay set to 1,302,273,336,957,175,537 nanosecs.

And the following exception would be triggered.

SPECSIPASDriverAgent[0].0: Sleep interrupted. Run terminating.

By contrast, if scale is greater than the number agent, the delay amount is reasonable.

SPECSIPASDriverAgent[0].0: Delay set to 2,998,212,082 nanosecs.

Or if scale equals to the number of agent, but parallel thread start is set to false,

<fd:threadStart>
<fd:delay>1000</fd:delay>
<fd:simultaneous>true</fd:simultaneous>
<fd:parallel>false</fd:parallel>
</fd:threadStart>

the delay amount is right.

SPECSIPASDriverAgent[0].0: Delay set to 2,999,708,046 nanosecs.



 Comments   
Comment by yaominchen [ 17/May/11 ]

commit 734ec744c66fac4c53442b2f08e1c16188930797
Author: Super-User <root@swu4200-3.(none)>
Date: Tue May 17 01:18:40 2011 -0700

Basically, parallel thread start only makes sense when there are more than one thread in an agent. We fix the bug by checking the number of threads associated with an agent. If the number is one, we fold back to the code path without parallel thread start.





[FABAN-7]  Need @BenchmarkPostprocessing annotation Created: 05/Apr/11  Updated: 15/May/11  Due: 29/Apr/11  Resolved: 11/Apr/11

Status: Closed
Project: faban
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: yaominchen Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Solaris and Linux


Tags: Faban, annotation, post-processing

 Description   

There are tasks commonly performed after the end of benchmark run, such as cleaning up temp files and resetting system resources, etc. It is good to have a post-processing annotation to cleanly separate out code related to post-processing.



 Comments   
Comment by yaominchen [ 11/Apr/11 ]

@OnceAfter annotation should be able to serve the purpose.

Comment by yaominchen [ 15/May/11 ]

While @OnceAfter is done at per-run (global) level. A new annotation @AgentFinal was implemented to support post-processing at the per-agent (local) level.

Comment by yaominchen [ 15/May/11 ]

Use per-run @OnceAfter and per-agent @AgentFinal annotations.





[FABAN-6] Need @BenchmarkPreprocessing annotation Created: 05/Apr/11  Updated: 15/May/11  Due: 29/Apr/11  Resolved: 11/Apr/11

Status: Closed
Project: faban
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: yaominchen Assignee: yaominchen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Solaris and Linux


Tags: Faban, annotation, preprocessing

 Description   

There are tasks that are more suitable implemented in the pre-processing stage, such as variable and data initialization. It is good to have a annotation for pre-processing to have clean cut between run-time code and initialization code.



 Comments   
Comment by yaominchen [ 11/Apr/11 ]

@OnceBefore should be able to serve this purpose.

/**

  • Designates a method to be called only once, just before the start of the
  • benchmark run. It is always called from global thread 0 for the given driver.
  • No other thread will be started until this method finishes. Note that only
  • one method is allowed for the OnceBefore designation. If Faban finds more
  • than one method with the OnceBefore annotation, it will throw a
  • DefinitionException at startup.<p/>
    */
    @Retention(RetentionPolicy.RUNTIME)
    @Target(ElementType.METHOD)
    public @interface OnceBefore { // marker attribute }
Comment by yaominchen [ 15/May/11 ]

While @OnceBefore is done at per-run (global) level. A new annotation @AgentInit was implemented to support pre-processing at the per-agent (local) level.





Generated at Sat Jan 21 18:29:25 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.