Re: [jboss-dev] Reorganizing Javaee Spec Projects
by Shelly McGowan
Taking longer than anticipated. Working on the last couple of modules -
mvn release plugin not consistently cooperating.
Shelly
----- Original Message -----
From: "Paul Gier" <pgier(a)redhat.com>
To: "JBoss.org development list" <jboss-development(a)lists.jboss.org>
Sent: Friday, March 5, 2010 3:40:09 PM GMT -05:00 US/Canada Eastern
Subject: Re: [jboss-dev] Reorganizing Javaee Spec Projects
We've finished the refactoring and Shelly is releasing the spec jars and POMs today.
Paul Gier wrote:
> Hey Guys,
>
> Shelly and I are reorganizing the javaee spec projects in svn. I'll send out an
> update later today after we are finished with some wiki docs about how things
> are organized, how to do releases, etc..
>
> Thanks!
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
16 years, 1 month
javax.annotations into separate module in javaee
by Anil Saldhana
Hi,
the tomcat annotations-api.jar has the following annotations:
=================
anil@localhost:~/apache-tomcat-6.0.18/lib$ jar tvf annotations-api.jar
0 Tue Jul 22 02:00:40 CDT 2008 META-INF/
106 Tue Jul 22 02:00:38 CDT 2008 META-INF/MANIFEST.MF
0 Tue Jul 22 02:00:32 CDT 2008 javax/
0 Tue Jul 22 02:00:30 CDT 2008 javax/annotation/
0 Tue Jul 22 02:00:30 CDT 2008 javax/annotation/security/
637 Tue Jul 22 02:00:30 CDT 2008 javax/annotation/Generated.class
396 Tue Jul 22 02:00:30 CDT 2008 javax/annotation/PostConstruct.class
390 Tue Jul 22 02:00:30 CDT 2008 javax/annotation/PreDestroy.class
1179 Tue Jul 22 02:00:30 CDT 2008
javax/annotation/Resource$AuthenticationType.class
903 Tue Jul 22 02:00:30 CDT 2008 javax/annotation/Resource.class
427 Tue Jul 22 02:00:30 CDT 2008 javax/annotation/Resources.class
433 Tue Jul 22 02:00:30 CDT 2008
javax/annotation/security/DeclareRoles.class
393 Tue Jul 22 02:00:30 CDT 2008 javax/annotation/security/DenyAll.class
409 Tue Jul 22 02:00:30 CDT 2008
javax/annotation/security/PermitAll.class
447 Tue Jul 22 02:00:30 CDT 2008
javax/annotation/security/RolesAllowed.class
418 Tue Jul 22 02:00:30 CDT 2008 javax/annotation/security/RunAs.class
0 Tue Jul 22 02:00:30 CDT 2008 javax/ejb/
629 Tue Jul 22 02:00:30 CDT 2008 javax/ejb/EJB.class
398 Tue Jul 22 02:00:30 CDT 2008 javax/ejb/EJBs.class
0 Tue Jul 22 02:00:30 CDT 2008 javax/persistence/
737 Tue Jul 22 02:00:30 CDT 2008
javax/persistence/PersistenceContext.class
1085 Tue Jul 22 02:00:30 CDT 2008
javax/persistence/PersistenceContextType.class
459 Tue Jul 22 02:00:30 CDT 2008
javax/persistence/PersistenceContexts.class
404 Tue Jul 22 02:00:30 CDT 2008
javax/persistence/PersistenceProperty.class
524 Tue Jul 22 02:00:30 CDT 2008 javax/persistence/PersistenceUnit.class
450 Tue Jul 22 02:00:30 CDT 2008
javax/persistence/PersistenceUnits.class
0 Tue Jul 22 02:00:32 CDT 2008 javax/xml/
0 Tue Jul 22 02:00:32 CDT 2008 javax/xml/ws/
633 Tue Jul 22 02:00:32 CDT 2008 javax/xml/ws/WebServiceRef.class
434 Tue Jul 22 02:00:32 CDT 2008 javax/xml/ws/WebServiceRefs.class
=============================================
Some of these are generic cross cutting annotations that should not
reside in for example, the jboss ejb3 jars.
Carlo had mentioned sometime back that he intends to pull out the
annotations from ejb3 into a separate module
under javaee project.
I created https://jira.jboss.org/jira/browse/JBEE-32 for this.
Regards,
Anil
16 years, 1 month
Boot problem
by Dimitris Andreadis
I've just cleaned/updated/rebuild trunk and it doesn't boot cleanly.
Is it me?
16 years, 1 month
VFS3 Integration in JBoss AS Trunk
by John Bailey
As discusses previously, the VFS3 integration in JBoss AS is planned for for Monday, March 1st. At this point we have all the dependent projects released with the necessary VFS3 changes integrated. So we should be all set to start the integration on Monday.
There will be a lot of changes to merge in, so I ask that all commits to AS trunk be suspended durning the integration. So if you could please have all outstanding changes committed by 4PM UTC on Monday. The goal is to have changes to the trunk suspended no more than 48 hours. I will send out a notice as soon as it is available, which hopefully will be earlier than planned.
Also, I have created a job on the hudson server to run the AS testsuite against the VFS3 integration branch. There are currently around 30 test failures. I will get the job results published to the hudson.jboss.org site so all can see the failures. I have identified the root cause of several of the failures, but I would appreciate it if everyone can take a look and see if anything jumps out.
Let me know if you have any questions or concerns.
Thanks,
--
John Bailey
JBoss by Red Hat
--
16 years, 1 month
Host and Node name feature
by David M. Lloyd
In case you haven't followed the discussion [1], I've recently added a
concept of a "node name" to JBossAS trunk [2]. This name will initially be
used to identify the Remoting 3 Endpoint which is created for the JBossAS
instance, and could also be reused by other things for similar purposes.
The node name can be found in the "jboss.node.name" system property, and
can be set on the command line with the "-N" or "--nodename" switch.
Because we want to have sensible default for this name, I've also
introduced a pair of properties which may be used to retrieve the system
host name (not to be confused with DNS name; this is the answer you get
back when you run the "hostname" command). The algorithm I use is
purported to work on all major OSes, but feel free to test that if you
like. The properties are "jboss.host.name" and
"jboss.qualified.host.name"; you may manually set the host name at boot via
the command line "-H" or "--hostname" switch.
It should be pretty easy to verify the host name detection by checking out
the newly sorted [3] system properties.
One last thing. A server's host name, while not exactly the Colonel's
secret recipe, still technically represents inside information about the
system, and thus the node name (which may be derived from it) should not be
used directly in anything that might make it out to untrusted systems by
default (read: HTTP cookie values for example) (though there's no reason
why our users/administrators couldn't opt into it).
Have fun.
[1] http://community.jboss.org/message/529257#529257
[2] https://jira.jboss.org/jira/browse/JBAS-7779
[3] https://jira.jboss.org/jira/browse/JBAS-7776
--
- DML ☍
16 years, 1 month
Documenting the MC codebase
by Thomas Diesler
There is an effort that started in May-2009 which is about providing
better API docs for the MC code base
https://jira.jboss.org/jira/browse/JBMICROCONT-442
Recently, I came across an open source project that takes a radically
different (read opposite) approach to API docs than we have with the MC
code base. Mockito says: "all docs are in javadoc"
http://mockito.googlecode.com/svn/tags/latest/javadoc/org/mockito/Mockito...
Providing documentation in that way is easy for the consumer because it
can always up to date and available online. For the provider of the docs
it's also easy because docs can be changed in the same place were code
changes happen.
As you might guess, improving the docs of the MC code base is important
and dear to me because it represents a significant non-trivial portion
of our infrastructure. New comers can only make qualified changes
effectively when the docs are good.
views?
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
16 years, 1 month
Refactoring packaging/packages to reduce "signed jar groups"
by Mike Clark
Hey folks,
The general purpose of this note is to explore refactoring some of our
jars to reduce some problems that have come about due to our signing of
jars.
So, let me start with a description of the problem. Essentially, the
core issue is around the simple replacement of an EAP signed jar with an
unsigned jar. While we have a system in place to have QE get one-off
patches signed in a relatively responsive manner, we are still left with
cases such as a diagnostic jar created by support to track down
problems, or a customer that, understanding that it would not be
supported, wishes to make a change for their system (one of the
advantages of OSS, of course).
The problem with such a substitution is the fact that a classloader will
not load classes from a packages that appear in differently signed
jars. So, for example, even though class org.jboss.A may only occur in
an unsigned A.jar, loading it will cause a security exception if class
org.jboss.B was loaded from a signed B.jar. Now, the first step to
resolve this would be to replace both A.jar and B.jar with unsigned
versions. But, we then often run into a transitive entanglement. B.jar
may contain classes from package org.jboss, but also org.hibernate. So,
you have to have unsigned versions of C.jar and D.jar that contain the
hibernate packages. But, they have an org.apache package, and so on.
Using TattleTale with some custom reports, I generated "signed jar
groups" identifying clusters of jars that would need to all be replaced
as unsigned if any one is unsigned. For the largest group, I created a
graph of the dependencies shown in
http://community.jboss.org/wiki/SignedJarDependenciesExample
(getopt_jar_Group.png, named by the first jar listed in the group from
the report.)
The figure shows the jars with a line connecting them if they have one
or more packages in common (I also generate detailed plots with a
labelled line for each package in common if anyone wants to see them,
but for the "getopt" group, the detailed plot is quite large and hard to
read.) Clearly, lots of unrelated jars are wound up in this group.
But, we can chip away at this with a bit of analysis. I'll give three
examples.
First, consider the set of jar files just to the right of the center
grouped around jboss-ejb3-core.jar. This set of jars is tied into the
rest of the graph through the connection between
jboss-as-ejb3-deployer.jar and jboss.jar. The package that ties them is
org.jboss.as.javaee. In this case there appears to be only two classes
involved. In jboss.jar there is
org.jboss.as.javaee.SimpleJavaEEModuleIdentifier and in
jboss-as-ejb3-deployer.jar there is
org.jboss.as.javaee.SimpleJavaEEModuleInformer (which has an inner
class). So, in this case, we can break off a chunk of the signed jar
group by, for example, changing a package name:
org.jboss.as.javaee.ejb3.SimpleJavaEEModuleInformer
Next, from the graph, we can see that there is a group of jar files on
the far left that is tied in by a connection between the
jboss-system-jmx.jar and the jboss.jar. In this case, the package is
org.jboss.deployment. There are several classes in jboss.jar and a
handful in jboss-system-jmx.jar that are in this package. So, options
might include renaming the package for the classes in the
jboss-system-jmx.jar, moving them to jboss.jar, or separating the
org.jboss.deployment classes between them into a new jar:
jboss-deployment.jar.
Finally, staying on the far left of the graph we see that run.jar and
shutdown.jar are tied into some third party jars such as getopt.jar,
hsqldb.jar and jdom-1.0.jar. These are due to use of classes in the
default package. Further, the default package is included because the
contents of the getopt.jar are incorporated into run.jar and
shutdown.jar. So, this connection to third party jars can be broken out
by removing the GetOpt related classes from run.jar and shutdown.jar and
relying on the Class-Path: attribute in their manifests.
So, in the end, it would seem to be beneficial to refactor package
locations such that there is not such widespread entanglement. From the
signed jar perspective, it would be best if each package only appeared
in one jar. Of course, there are often engineering reasons to separate
classes in the same package into different jars. However, I think it's
not unreasonable that these should be relatively small in number and
they should be functionally coherent. At any rate, it would appear to
be something we could attack incrementally as indicated by the three
examples above.
Originally, when discussing this with other folks, we thought perhaps we
should just open jiras to address the problem. But, on considering
that, it seemed that perhaps a discussion on a larger game plan would be
a better approach, even if it just ended up with the original plan of
opening some jiras to "chip away" at the problem.
So, I apologize for a long, dense note. For those of you that made it
through, any thoughts, suggestions?
Cheers,
Mike C.
16 years, 1 month
