[JBoss Microcontainer Development] New message: "Re: JBREFLECT-5 - Implementing generics in JavassistClassInfo"
by Kabir Khan
JBoss development,
A new message was posted in the thread "JBREFLECT-5 - Implementing generics in JavassistClassInfo":
http://community.jboss.org/message/529601#529601
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
> alesj wrote:
>
> 1) It should be easy to add some tests for this, right?
> Perhaps we use some on-the-fly generics creation (which Javassist has, afaik), and test this for some reasonable depth.
Yes
> alesj wrote:
> 3) How do you get the generic Type then?
>
>
Not sure I understand the question. I've just worked with what was provided, but we need some tests testing the scenario I outlined. We would need to check the Signature attribute of the method and then construct the parameterized ClassInfo as was done for getGenericSuperClass().
> alesj wrote:
>
> 4) What are the issues / pitfalls here?
The main thing is knowing the index of the type parameter we are looking for in the parent class, then getting the type argument using that index used when extending that class and matching that up with the type parameters of the child class. This needs doing for the whole hierarchy. This has been done, but needs some better tests
> alesj wrote:
>
> Like I said, while implementing this, other depending projects are the best test env.
> e.g. Kernel, CL, Deployers and of course the whole AS
> * -Dorg.jboss.reflect.spi.TypeInfoFactory=org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactory
>
I'll try that
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529601#529601
16 years, 1 month
[jBPM Development] New message: "Swimlane clarification"
by john britto
JBoss development,
A new message was posted in the thread "Swimlane clarification":
http://community.jboss.org/message/529583#529583
Author : john britto
Profile : http://community.jboss.org/people/brittobics
Message:
--------------------------------------------------------------
i have situation
In which i have two roles of swimlane Buyer and Seller
The problem is can i assign two swimlane in one task as i have done it below my code
i think it is right to use
as it is
"
<task-node name="Fill F6">
<task name="trcwf:fillApplicationF6" swimlane="Seller,Buyer"></task>
"
please tell me if i am worng of assigning task to swimlane as Seller and Buyer in comma seperated values.
<swimlane name="Buyer">
<assignment class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
<actor>#{bpm_assignee}</actor>
</assignment>
</swimlane>
<swimlane name="Seller">
<assignment class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
<actor>#{bpm_assignee}</actor>
</assignment>
</swimlane>
<task-node name="Fill F6">
<task name="trcwf:fillApplicationF6" swimlane="Seller,Buyer"></task>
<transition to="NegotaionDecision" name="Negoation"></transition>
<transition to="Print & Upload Signed F6" name="Accepted"></transition>
</task-node>
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529583#529583
16 years, 1 month
[JBoss Portal Development] New message: "trying out a portlet from the reference guide"
by Eli Galicia
JBoss development,
A new message was posted in the thread "trying out a portlet from the reference guide":
http://community.jboss.org/message/529505#529505
Author : Eli Galicia
Profile : http://community.jboss.org/people/superdepor
Message:
--------------------------------------------------------------
I'm trying out the JSF portlet example a user types in her name and pushes the submit button and a new jsp page displays her name!
A JSPHelloUserPortlet checks if the name parameter is set, and based on this one of the jsp pages will be shown for the user.
And here is where my problem raise!
The thing is once the request parameter is set in the first JSP then it will be cashed for all subsequent requests. So the User will see the second JSP page every time after submitting her name once.
Im wondering how I could erase the request parameter...
I didn't find any method for it in the API for example request.removeParameter(String string).
How can I overcome this problem?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529505#529505
16 years, 1 month
[JBoss Microcontainer Development] New message: "Re: ClassLoadingAdmin"
by Ales Justin
JBoss development,
A new message was posted in the thread "ClassLoadingAdmin":
http://community.jboss.org/message/529482#529482
Author : Ales Justin
Profile : http://community.jboss.org/people/alesj
Message:
--------------------------------------------------------------
Found a potential NPE -- see Module class:
public static boolean resolveModules(Module... modules) throws Exception
{
if (modules == null || modules.length == 0)
return true;
LifeCycle[] lifeCycles = new LifeCycle[modules.length];
for (int i = 0; i < modules.length; ++i)
{
Module module = modules[i];
if (module == null)
throw new IllegalArgumentException("Null module");
LifeCycle lifeCycle = module.getLifeCycle();
if (lifeCycle == null)
log.warn(module + " has no lifecycle, don't know how to resolve it.");
lifeCycles[i] = lifeCycle; // HERE -- we allow null
}
lifeCycles[0].resolve(lifeCycles); // NPE #1
for (LifeCycle lifeCycle : lifeCycles)
{
if (lifeCycle.isResolved() == false) // NPE#2
return false;
}
return true;
}
And the code in #1 and #2 looks a lot the same -- could be made into one?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529482#529482
16 years, 1 month
[Clustering Development] New message: "Re: Partition and Node identities"
by Brian Stansberry
JBoss development,
A new message was posted in the thread "Partition and Node identities":
http://community.jboss.org/message/529470#529470
Author : Brian Stansberry
Profile : http://community.jboss.org/people/bstansberry@jboss.com
Message:
--------------------------------------------------------------
IMHO what you've laid out makes sense and is the way to move forward. I posted a link back to this thread on the other one, in case anyone following that forum wants to weigh in.
Re: JBossTS, I really just linked that because you're a smart guy and I wanted you to be aware of the entire problem domain; i.e. we've got use cases that need ints and others that need strings.
For the JBossTS case there's no need to come up with a port, just an int. The only reason that particular socket exists is to generate a unique-on-the-host int. They create the socket bound to 127.0.0.1 and then they can use the port number as a unique id because they know no other process could concurrently do the same thing. The whole thing is pluggable, and if another technique were available the whole socket would go away.
But hashing the name would still leave the chance of collisions.
Re: HornetQ, yeah, I hope the need for an int goes away, and my guess is it does. We can find out quickly enough; either when those guys get back from meetings or in a day or so when I get a minute to poke around in their AS integration branch to see.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529470#529470
16 years, 1 month
[JBoss Microcontainer Development] New message: "JBREFLECT-5 - Implementing generics in JavassistClassInfo"
by Kabir Khan
JBoss development,
A new message was posted in the thread "JBREFLECT-5 - Implementing generics in JavassistClassInfo":
http://community.jboss.org/message/529467#529467
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
I have had a first stab at implementing generics in the Javassist version of ClassInfo and committed it against http://jira.jboss.org/jira/browse/JBREFLECT-5.
I have created Javassist versions of the tests that were not there before: JavassistGenericClassUnitTestCase and JavassistGenericInterfaceUnitTestCase. They are just subclasses of the abstract base classes used by the Introspection versions of these tests. They pass, but I don't think that they are good enough for the following reasons:
1) They only test plain generics such as Collection<String>, while more complex things such as Collection<Map<String, List<V>>> are not tested.
2) Wildcards and bounds are not tested, but I am not sure if we should support those or not?
3) When accessing generics from the return type of a method, e.g.
Collection<String> getStringCollection(){}
we get hold of this method using normal reflection (A) and construct the TypeInfo for that using the ParameterizedType (B1+2) for which I extended the Javassist TypeInfo factory:
private void assertComponentType(String methodName, Class<?> expected) throws Exception
{
Method method = ClassInfoGenericClassTest.class.getMethod(methodName, (Class[]) null); //A
Type type = method.getGenericReturnType(); //B1
assertComponentType(type, expected);
}
private void assertComponentType(Type type, Class<?> expected) throws Exception
{
TypeInfoFactory factory = getTypeInfoFactory();
TypeInfo typeInfo = factory.getTypeInfo(type); //B2
ClassInfo classInfo = assertInstanceOf(typeInfo, ClassInfo.class);
assertTrue(classInfo.isCollection());
TypeInfo expectedInfo = factory.getTypeInfo(expected);
assertEquals(expectedInfo, classInfo.getComponentType());
}
However, that is probably not what will happen in real life, we would have a ClassInfo, get hold of the MethodInfo in question, and then get the return type which should contain the actualTypeArguments. This needs implementing and is not being tested at the moment, and the same goes for parameters and field types.
4) Flavia mentioned that for the component type tests we might have something like
interface WeirdMap<V, K> implements WeirdMap<K, V>
This is kind of tested but needs fleshing out more
What I have do so far satisfies what the tests require, but in case somebody looks at this while I look at the aop failures in AS trunk, feel free to rework and change what I have done, it is by no means the final solution although I think it proves that the stuff Chiba did for the Signature attribute works well and we can figure out things from that.
A few points worth remembering:
a) I have implemented a JavassistParameterizedClassInfo (stolen from the introspection implementation) which handles things like Collection<String>. This basically delegates to the "raw" ClassInfo for Collection, augmented with extra information regarding the <String> bit. These are currently not cached and are created on every access.
b) JavassistClassInfo should cache the values of isMap() and isCollection()
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529467#529467
16 years, 1 month