I am currently going through the console, preparing it for i18n.
Basically making sure everything is properly placed into bundles that can be translated.
There is one thing I need your feedback on:
How are we going to treat strings that reflect technical terms?
I.e. a log handler has an editable field name (speaking of the UI here) called "Auto Flush".
To me this represent a technical term that corresponds with other places like the XML schema, the CLI and the actual XML configuration files. As such, I objecting to translate those. "Log Level" is another good example.
Now, to many native english speaking people, this might not be obvious, but once you start translating those things get pretty awkward. IMO technical terms should stay untouched and I expect people to incorporate those easily into their own language. As a result the web management interface would keep english terms for elements that derive from the XML schema or other API and provide localized description and help texts for anything else.
What are you thoughts on this?
Senior Software Engineer
JBoss by Red Hat
I started working on a way to modularize the product name and version in
the startup/shutdown logs of AS7 . There is a new module called
"product" which contains the product name and version. However this
approach doesn't seem good to me because the "host-controller",
"process-controller", and "server" modules all now have dependencies on
this new module.
Ideally, I want to set this up so that there is sort of a placeholder
product name/version used during the build or these modules, but then
this can be overridden by the product module later in the build. Anyone
have suggestions about how to do this?
currently there are a number of OSGi bundles in the distro that we don't
want to support (e.g Jetty HttpService, Aries Blueprint). Generally I
assume that every jar we ship must also potentially be supported. Is
that still true?
If so, I would remove these bundles
<https://issues.jboss.org/browse/AS7-3036> from the distro and move test
coverage to the jbosgi project. AS7 would then only contain basic OSGi
core support and 3rd party bundles would not be shipped any more.
An alternative could be to label all OSGi functionality (that relies on
3rd party bundles) as tech preview and leave the bundles and test
coverage in the project source.
JBoss OSGi Lead
JBoss, a division of Red Hat
I'd like to get rid of the current arquillian/container-managed-domain
module in the AS7 source tree and move the couple classes there to the
testsuite/domain module. That's the only place they are used, and their
current location implies they are a proper arquillian container
implementation, which isn't the case. They're just some utilities that I
hoped someday to turn into a proper container implementation.
Principal Software Engineer
JBoss by Red Hat
I've got a war ( org.apache.sling.launchpad-6.war from
http://sling.apache.org/site/downloads.cgi) that deploys and functions
properly in EAP5, but fails in AS7. In AS7, the war deploys without
error but when accessing
http://localhost:8080/org.apache.sling.launchpad-6 the web app fails
with an NPE (stacktrace below). Looks like a resource bundle is not
being loaded in AS7. This issue originally came up with an Express user,
but is recreatable outside of Express.
Do I need to explicitly list the resource bundle jar in AS7?
17:13:07,607 INFO [org.jboss.as.server.controller]
(DeploymentScanner-threads - 2) Deployed "org.apache.sling.launchpad-6.war"
17:13:08,740 ERROR [stderr] (FelixStartLevel) 2012-01-02 22:13:08.739
GMT Thread[FelixStartLevel,5,main] java.io.FileNotFoundException:
derby.log (Permission denied)
I have noticed the error on the last line, but that should not, by my
experience, cause the app to fail completely. However, when attempting
to request http://appname-namespace.rhcloud.com, the following is logged:
17:15:26,654 ERROR [org.apache.catalina.connector.CoyoteAdapter]
(http--127.1.0.129-8080-1) An exception or error occurred in the
container during the request processing: java.lang.NullPointerException
Principal Software Engineer, Red Hat
I'm writing up the documentation for invoking remote EJBs from a
(really) remote application like standalone Java applications. One of
the things that we have to decide about is how we want the users to
access some of our public API jars (I'm not calling this "client" jars
since one of the previous discussions around this suggested that it
would confuse things). Right now we don't have a way where users can
*easily* add these public API jars to their classpath. Some of the
requirements that I can think of are:
1) These jars must be available at a well known location within the AS
distribution. i.e. the users shouldn't have to drill down into
individual module path to find the jars.
2) The jar names shouldn't contain the version names (since that will
require changes to client scripts if some API jar version changes)
3) Modular environment on the client side is not a requirement. i.e. the
client application should just be able add these jars to their classpath
and use them
4) IDE and build tool requirements should be taken into account
separately. i.e. a "bom" or some other IDE specific way of getting
access to these API jars _shouldn't_ be the only way of referencing
5) Identifying the public API jars
Thoughts? Is this something that we could target for 7.1 Beta1?
The quickstarts currently have some possibly incorrect dependencies.
For example, using "mvn dependency:analyze" against the helloworld
quickstart reports the following dependency warnings. Should these be
fixed, or is there a reason to keep it as is?
[WARNING] Used undeclared dependencies found:
[WARNING] Unused declared dependencies found: