JBoss Unified I18N Infrastructure
by Caius Carlos Chance
>> Another advantage of using gettext is, there is an existing localization
>> team in Red Hat could be leveraged for the all JBoss modules when the
>> I18N infrastructure on JBoss could be integrated with current workflow
>> (e.g. tools, work file formats, etc.) of them. They have done the
>> translation for JBoss Installer and they are very familiar on working
>> with .po files that are used by gettext.
>>
> Sure, but requiring the projects to add an additional 3rd party jar is
> wrong (especially one I've never seen used in java)
> Would be relevant to know how the java properties support would work...
>
It will be good idea if all modules could unify their I18N
infrastructure. If so, also there would be only 1 convertor needed to be
developed for the translation team. The development of the convertor may
allow both translation team and current jboss developer keep minimal
changes on workflow/code.
--
CAIUS CHANCE | CCHANCE AT REDHAT DOT COM
X8116 | SW ENG | ENG-I18N | RED HAT APAC
APAC DOT REDHAT DOT COM SLASH DISCLAIMER
17 years, 4 months
WARN: Changed bootstrap in jboss-head
by Adrian
This is just a warning that I've factored out the bootstrap
into two new projects.
main - this project is for bin/run.jar and related files
bootstrap - a "minimal" MC based bootstrap
If you have an existing jboss-head checkout then doing
an svn update should get you the projects
otherwise you'll need to check them out individually.
The biggest change is to move a lot of the bootstrap
so it is not hardwired in ServerLoader
and instead can be found in bootstrap-beans.xml
(including the classloader definition).
There's more work needs to be done on this
particulary around the aop integrations
(currently hacked)
and making this more "modular".
i.e. so you can more easily choose
the core bootstrap services:
* classloader implementation
* profile service implementation
* aop instrumention
* whether you want jmx
* etc.
but those will come later.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years, 4 months
JBoss Cache SVN conversion
by Tom Benninger
All,
We will be converting the JBoss Cache project source repository from CVS
to Subversion tomorrow morning at 9:00 am EST. At this time the JBoss
Cache cvs module will be locked down. Once the conversion is complete,
the CVS repository will be available as a read only archive and
Subversion will be used for all new changes.
Instructions for accessing the new Subversion repository and related
services will be send out once the conversion is complete.
Thanks,
Tom Benninger
Senior Information System Engineer
tbenning(a)redhat.com
17 years, 4 months
JBoss-integration Hudson or CC?
by Carlo de Wolf
Do we have a Hudson or CC on jboss-integration?
I get the following compile failure:
[INFO] Compilation failure
/home/carlo/work/integration/build/../jboss-classloading-spi/src/main/org/jboss/classloading/spi/RealClassLoader.java:[28,30] package org.jboss.util.loading does not exist
/home/carlo/work/integration/build/../jboss-classloading-spi/src/main/org/jboss/classloading/spi/RealClassLoader.java:[38,41] cannot find symbol
symbol: class Translatable
public interface RealClassLoader extends Translatable
Carlo
17 years, 4 months
Localization, Resource.properties
by Thomas Heute
I'm looking for best practice concerning the keys you use for your
resource bundles properties keys. And advantages/drawbacks you know
about what you are using.
First i used some context prefixed English strings like:
Registration_AskLogin = Please enter a login
Connection_AskLogin = Your login
The main advantage not seen on this example, is that it gives a bit of
context for the translator, it helps sometimes.
I could use:
Please_enter_a_login = Please enter a login
Your_login = Your login
But in some language and certain scenario, "Your login" could be said in
a different manner depending on the context.
I could also use:
Please\ enter\ a\ login = Please enter a login
Your\ login = Your login
But that would suck ;) JSF EL wouldn't like it.
Thanks if you can help.
17 years, 4 months
Re: jboss-development Digest, Vol 13, Issue 94
by Caius Carlos Chance
Hi,
>> The advantages i could notice:
>> - possibility to 'mark' keys as dirty (need rework)
>> - possibility to add bookmarks if i remember well
>> - easy to see what is not yet translated
>>
>> But i'm pretty relectant to use gettext for JBoss Portal localization.
>>
> exactly ;)
>
> In eclipse it would be against everything else so at runtime it should
> be properties.
>
Another advantage of using gettext is, there is an existing localization
team in Red Hat could be leveraged for the all JBoss modules when the
I18N infrastructure on JBoss could be integrated with current workflow
(e.g. tools, work file formats, etc.) of them. They have done the
translation for JBoss Installer and they are very familiar on working
with .po files that are used by gettext.
Caius.
17 years, 4 months
Server on trunk broken?
by Clebert Suconic
I just built trunk, after rebuilding thirdpary (rm -r thirdpary), and I
get this.. and nothing works after that:
Anyone seeing the same thing?
19:42:05,524 INFO [Catalina] Server startup in 116 ms
19:42:05,817 ERROR [AbstractKernelController] Error installing to
PreInstall: name=WSKernelLocator state=Real
java.lang.ClassNotFoundException: No ClassLoaders found for:
org.jboss.wsf.spi.util.KernelLocator
at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:306)
at
org.jboss.mx.loading.UnifiedClassLoader.loadClassImpl(UnifiedClassLoader.java:290)
at
org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:431)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.resolveComplexTypeInfo(IntrospectionTypeInfoFactoryImpl.java:349)
at
org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getTypeInfo(IntrospectionTypeInfoFactoryImpl.java:340)
at
org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactory.getTypeInfo(IntrospectionTypeInfoFactory.java:49)
at
org.jboss.classadapter.plugins.BasicClassAdapterFactory.getClassAdapter(BasicClassAdapterFactory.java:61)
at
org.jboss.config.plugins.AbstractConfiguration.getBeanInfo(AbstractConfiguration.java:70)
at
org.jboss.kernel.plugins.config.AbstractKernelConfig.getBeanInfo(AbstractKernelConfig.java:55)
at
org.jboss.kernel.plugins.config.AbstractKernelConfigurator.getBeanInfo(AbstractKernelConfigurator.java:65)
at
org.jboss.kernel.plugins.config.AbstractKernelConfigurator.getBeanInfo(AbstractKernelConfigurator.java:84)
at
org.jboss.kernel.plugins.dependency.PreInstallAction.installActionInternal(PreInstallAction.java:63)
at
org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:147)
at
org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:53)
at
org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at
org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at
org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:304)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1257)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:685)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:813)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:735)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:525)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:361)
at
org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:68)
at
org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:42)
at
org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:65)
at
org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:164)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:661)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:674)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:624)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:588)
at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:304)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1257)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:685)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:813)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:735)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:573)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:374)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:427)
at
org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:340)
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:372)
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:247)
at
org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
at
org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
at
org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
at org.jboss.Main.boot(Main.java:210)
at org.jboss.Main$1.run(Main.java:523)
at java.lang.Thread.run(Thread.java:595)
19:42:05,878 ERROR [AbstractKernelController] Error installing to
PreInstall: name=WSHTTPServer state=Real
java.lang.NoClassDefFoundError:
org/jboss/wsf/spi/deployment/AbstractExtensible
at java.lang.ClassLoader.defineClass1(Native Method)
17 years, 4 months
Multiple classLoaders for a single WAR file on Tomcat
by Clebert Suconic
This is probably a question for Remy:
Why Tomcat creates multiple ClassLoaders for every deployment?
Is this by design or this is a leak?
For a single WAR, I'm seeing 4 classLoaders deployed just wasting
PermGeneration memory.
For example, I deployed a single WAR, and I've got this Servlet loaded
by 4 distinct classLoaders. and this is a standard behavior I have seen
on Tomcat for a long time already.
org.jboss.on.plugins.servlet.test.Counter:
- java.net.URLClassLoader@10891966
- org.jboss.web.tomcat.tc5.WebAppClassLoader@18775238
- java.net.URLClassLoader@22498184
- org.jboss.web.tomcat.tc5.WebAppClassLoader@8238932
Also... if you use any other profiler (besides the ClassLoader analysis
I've written on JBossProfiler) you could be foolished by them as those
classes won't have any instances... Just the classDef loaded on the heap.
Clebert
17 years, 4 months
