generic collection item type
by Alexey Loubyansky
Is there a way to find out the item type of a generic collection at
runtime using introspection or org.jboss.reflect?
Thanks,
Alexey
18 years, 3 months
Need help to figure out why jboss-head testsuite SSO tests are failing
by Hany Mesha
tomcat SSO tests are failing on trunk
http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-testsuite-sun-1.5
.
The failure message is :
<failure message="Get OK"
type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError:
Get OK
at
org.jboss.test.web.test.SSOBaseCase.checkAccessDenied(SSOBaseCase.java:157)
at
org.jboss.test.web.test.SSOBaseCase.executeFormAuthSingleSignOnTest(SSOBaseCase.java:60)
at
org.jboss.test.web.test.SingleSignOnUnitTestCase.testFormAuthSingleSignOn(SingleSignOnUnitTestCase.java:57)
at
junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
Looking at the server log, It seems the failure due to error during war
deployment. I tried to figure out where the failure might be coming from
but couldn't.
Thanks for your help in advance!!
Hany
Hany M. Mesha
Sr. Software Engineer, Consultant
Novell Identity Management Engineering
Toronto, Canada
hmesha(a)novell.com
Mobile: 416-456-6945
skype: hanymesha
Novell, Inc.
SUSE® Linux Enterprise 10
Your Linux is ready
http://www.novell.com/linux
18 years, 3 months
Help with a deployment XML on the testsuite...
by Clebert Suconic
I need some help understanding this ejb-jar.xml
http://anonsvn.jboss.org/repos/jbossas/trunk/testsuite/src/resources/mess...
This ejb-jar.xml has a reference to what seems to be a variable
${test.messagedriven.transactionType}
I did a file search on the entire project, and nothing but the xml
references test.messagedriven.transactionType. I have never seem such
thing on ejb-jar.xmls... Any help how this thing works? It looks a
mistake to me, but the JBossMQ test doesn't complain about it, and an
equivalent JBossMessaging test is complaining.
Thanks,
Clebert
18 years, 3 months
jboss i18n and localization (l10n)
by Jens Petersen
Hi,
I would like to ask about and start some discussion about localization
(translation) of JBoss projects.
I think there is going to be an increasing need for localization of
JBoss projects, so probably it is a good time to start thinking about
how to do internationalization of projects in a way that is optimal for
developers, translators and users. I think there are two sides to this:
(1) the process of getting translations done and integrated into svn and
releases and (2) the java library used to substitute the translations at
runtime.
For (1), the translation process, in the Open Source world a lot of
translation is done using .po files. First the strings that need to be
translated are extracted from the source using xgettext to generate a
so-called POT file, which is the skeleton used to generate the .po files
for each language that is to be translated. Finally the translated .po
files are committed in the version control system along with the
ResourceBundles generated from them.
(2) would then require using Gettext in the Java modules that require
translations and marking the strings to be translated appropriately so
that they can be extracted automatically for translation.
That is a brief sketch of how would could use Gettext to handle the
translations. It might also be possible to use XLiff later to generate
the ResourceBundles for translations directly.
How does that idea sound?
Ideas, comments, other suggestions and feedback are most welcome.
Jens Petersen
Internationalization Team
Red Hat
18 years, 3 months
Re: [jboss-dev] generic collection item type
by Ales Justin
You're right.
You need superclass.
I had a superclass/interface reference, but the instance was similar to
yours. That's why it worked for me.
>> configuration.getTypeInfo(...) may be a wrong way to load a generic
type
but even if I declare a field of type JBossEnterpriseBeansMetaData and
But I don't understand this.
Cheers,
Ales
>>>>>>>>>>
No, it won't.
This
ClassInfo classInfo = (ClassInfo)
configuration.getTypeInfo(JBossEnterpriseBeansMetaData.class);
System.out.println("isCollection: " + classInfo.isCollection());
System.out.println("type args: " +
classInfo.getActualTypeArguments());
System.out.println("superclass args: " +
Arrays.asList(classInfo.getGenericSuperclass().getActualTypeArguments()));
results in
isCollection: true
type args: null
superclass args:
[ReflectClassInfoImpl(a)f38798{name=org.jboss.ejb.metadata.spec.EnterpriseBeanMetaData},
ReflectClassInfoImpl(a)4b222f{name=org.jboss.ejb.metadata.jboss.JBossEnterpriseBeanMetaData},
ReflectClassInfoImpl(a)b169f8{name=org.jboss.ejb.metadata.spec.EnterpriseBeansMetaData}]
18 years, 3 months
Re: [jboss-dev] generic collection item type
by Ales Justin
This is not just Collection specific.
Doing this (TypeInfo[] types = typeInfo.getActualTypeArguments();) on
JBossEnterpriseBeansMetaData would return you those 3 types:
(pseudo code ;-)
types[] = {EnterpriseBeanMetaData, JBossEnterpriseBeanMetaData,
EnterpriseBeansMetaData};
Rgds, Ales
>>>
This approach assumes that the component type can be determined with
TypeInfo[] types = typeInfo.getActualTypeArguments();
if (types != null)
elementType = types[0];
This won't work for this class
https://svn.jboss.org/repos/common/jbossxb-builder/trunk/src/test/java/or...
for which its super class should be checked for type arguments and the
component type is the second argument.
I guess I'll need to specify the component type with an annotation. But
it would be nice to have something like Class.getComponentType() to work
for generic collections too.
Alexey
18 years, 3 months
JAXB Generated Classes with target 2.0
by Anil Saldhana
If any of the projects are exploring JAXB2 generated classes, then I
think it is advisable to set the target to be "2.0" such that the
generated classes can be usable with JAXB2.0.x and none of the JAXB2.1
leakages occur. I think JDK6 includes JAXB2.0.x
I am no expert on JAXB2. But saw this while using the xjc command line
tool.
18 years, 3 months
Zip sources as artifacts
by Dimitris Andreadis
Do we really need to include the .zip sources as artifacts in the component-info's ?
It takes long to download and it's not used.
(or, it doesn't matter now if we move to maven2?)
https://svn.jboss.org/repos/repository.jboss.org/jbpm/3.1.2/component-inf...
<project name="jbpm-component-info">
<component id="jbpm"
licenseType="lgpl"
version="3.1.2"
projectHome="http://jbpm.org/"
description="Powerfull BPM and workflow engine in Java">
<artifact id="jbpm.zip"/>
<artifact id="jbpm-3.1.2.jar"/>
<artifact id="jbpm-identity-3.1.2.jar"/>
<export>
<include input="jbpm.zip"/>
<include input="jbpm-3.1.2.jar"/>
<include input="jbpm-identity-3.1.2.jar"/>
</export>
</component>
</project>
18 years, 3 months
How can a project run in both AS 4.2.0 and AS 5.0?
by Tim Fox
A posted something similar on this some time ago, but we didn't get to
any conclusions so I'm bringing it up again.
JBoss Messaging has all its dependencies aligned with JBAS 4.2.0 - i.e.
we use all the same versons of libraries as AS 4.2.0.
This means all the testing we did is valid when we install inside AS
4.2.0 since we know we're still using all the same libraries.
However, JBAS 5.0 uses different versions of libraries to AS 4.2.0 - so
we can't guarantee that the version of our project that runs in 4.2 will
run in AS 5.0 - since we don't test against the versions of the
libraries used by AS 5.0.
The only way around this AFAICT is for us to keep two versions of JBM
(or at least to have two sets of dependencie)- one with a set of
dependencies mirroring AS 4.2.0, and another with a set of dependencies
mirroring AS 5.0.
But this is a big maintenance hassle - and will mean double the test
runs. Our test runs already take forever.
How do other projects deal with this? Surely we are not the only ones.
Or perhaps other projects don't worry about it and "hope for the best"
when installed in AS 5.0?
18 years, 3 months
