VFS3 (in AS trunk) - Non .jar file handling
by Jaikiran Pai
I see a new behaviour with VFS3 in JBoss AS. Earlier in AS-5/6 (with
VFS2) and AS-4 (without any VFS), to try out some quick fixes, i used to
rename existing jar files to end with .bak name and replace them with
the new patched jar file. So for example, if i had a fix in
jboss-ejb3-core.jar, i would:
1) Rename the JBOSS_HOME/common/lib/jboss-ejb3-core.jar to
JBOSS_HOME/common/lib/jboss-ejb3-core.jar.orig.bak
2) Place a patched jboss-ejb3-core.jar in JBOSS_HOME/common/lib
3) Restart the server
The server would then pickup the new patched jar file and ignore the
.bak file. After testing the fix, i would then revert back to the
original jar file by renaming it back to its original name.
However, with the recent upgrade to VFS3 in AS trunk, i notice that even
the .bak is used for classloading (following is the output from
-verbose:class JVM argument):
[Loaded org.jboss.ejb3.EJBContainer from
file:/NotBackedUp/jpai/business/jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/lib/jboss-ejb3-core.jar.orig.bak/]
Looks like VFS3 picks up this non .jar suffix file for classloading. Is
this expected? Shouldn't it be looking for only .jar files (atleast in
this context)?
regards,
-Jaikiran
13 years, 7 months
Small boottime improvement
by Kabir Khan
I have been doing some work on profiling and optimizing the jboss-dependency project [1] for kernel 2.2.0.Alpha6 and it seems to have had a small, but still measurable impact :-)
I did a few startups of AS with jboss kernel 2.2.0.Alpha5 and with a local snapshot. This snapshot contains the work done for Alpha6 with the addition of removing the break in the resolveContexts loop as mentioned in the forum thread.
The startups were done on a freshly rebooted machine with nothing else running. The startup orders are given in brackets, so I started Alpha5 twice, then SNAPSHOT twice and so on.
2.2.0-Alpha5
----------------------
37s:247ms (1)
20s:573ms (2)
20s:275ms (5)
20s:127ms (7)
20s:433ms (9)
20s:329ms (10)
20s:890ms (13)
2.2.0-SNAPSHOT
------------------------
29s:563ms (3)
19s:965ms (4)
19s:821ms (6)
20s:332ms (8)
19s:618ms (10)
19s:905ms (12)
19s:900ms (14)
One strange thing is that the first time I started each server they took loads longer than the other times, does somebody know the reason for that?
Ignoring those initial times leaves me with average start times of:
Alpha5: 20s437ms
SNAPSHOT: 19s923ms
I'm going to have a final look at jboss-dependency to see if there are any other obvious and easy fixes before moving on to have a look at jboss-kernel.
[1] http://community.jboss.org/message/525047#525047
14 years, 1 month
Re: [jboss-dev] Public IP address used by JBoss AS
by Bela Ban
Brian Stansberry wrote:
> Putting this on jboss-dev, as my guess is 3/4 of the work is
> discussing a bit. Particularly interested in hearing from Mr. Boot, ALR.
>
> What we're talking about is https://jira.jboss.org/browse/JBAS-8001
> which is a proposal to allow some standard aliases for IP addresses
> that the AS would resolve to something meaningful on the local
> machine. The purpose is to make it easier to use the AS in a cloud
> environment where the user can't know addresses in advance. Proposed
> aliases are:
>
> - GLOBAL: picks a global (public) address
> - SITE_LOCAL: an address starting with 192.168.x.x or 10.0.x.x
> - LINK_LOCAL: a link local address, ie. starting with 169.x.x.x or
> 254.x.x.x
> - NON_LOOPBACK: picks any non-loopback address
> - LOOPBACK: picks a loopback address
>
> My current take on this is if we did it for AS 6 we'd implement it in
> the org.jboss.Main class.[1] Basically we'd alter the command line
> processing for -b, -Djboss.bind.address and -Djgroups.bind_addr to
> detect the above aliases and replace with the appropriate value.
>
> IMO we would *not* allow these values as a general configuration
> option, e.g. in a -jboss-beans.xml:
>
> <!-- Not supported -->
> <property name="bindAddress">PUBLIC</property>
-100 IMO: a user may want to define an address based on some criteria,
so the above makes perfect sense ! I can even envisage that we support
something like this later:
<property name="bindAddress">192.168.*,274.2.*,SITE_LOCAL</property>,
which means that we should try to pick a site local address starting
with 192.168, if not found a global IP address starting with 274.*, and
if still not found, go and grab any site local address.
All of this logic can be centralized (in JGroups it is in 1 place) and
used everywhere.
> That would be too much work, since as soon as you allow it one
> configuration document you should allow it everywhere.
Yes, but again, if this is centralized, this should be simple. In
JGroups, processing of all IP addresses (IpAddress, InetAddress, or
lists thereof) is done in 1 place (via annotations).
> The weakness of only using it via Main's command line processing is if
> people only want to use, for example, PUBLIC, in one spot, not as a
> global value like -b. If we want to help with that, perhaps we could
> use a system property namespace, and have Main check for properties in
> that namespace and resolve them. For example:
>
> -Djboss.bind.address.myfoosocket=PUBLIC
>
> My instinct though is to *not* support that. First, to me there is no
> clear use case. Second, in AS 7 I'm pretty sure we are going to want
> to move away from system properties as a core way of configuring the
> AS, so let's not add new system property-based features in 6.
IMO, GLOBAL, SITE_LOCAL, LOOPBACK etc are *IP addresses*, as good as the
dotted decimal notation (192.168.1.5) ! They are simply resolved at boot
time, versus statically.
If we allow for these keywords to be used with -b, then it would be
weird for users not to be able to use them in XML config files or as
system properties !
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
14 years, 2 months
Re: [jboss-dev] Public IP address used by JBoss AS
by Brian Stansberry
On 05/26/2010 10:51 AM, Bela Ban wrote:
>
>
> Brian Stansberry wrote:
>> Putting this on jboss-dev, as my guess is 3/4 of the work is
>> discussing a bit. Particularly interested in hearing from Mr. Boot, ALR.
>>
>> What we're talking about is https://jira.jboss.org/browse/JBAS-8001
>> which is a proposal to allow some standard aliases for IP addresses
>> that the AS would resolve to something meaningful on the local
>> machine. The purpose is to make it easier to use the AS in a cloud
>> environment where the user can't know addresses in advance. Proposed
>> aliases are:
>>
>> - GLOBAL: picks a global (public) address
>> - SITE_LOCAL: an address starting with 192.168.x.x or 10.0.x.x
>> - LINK_LOCAL: a link local address, ie. starting with 169.x.x.x or
>> 254.x.x.x
>> - NON_LOOPBACK: picks any non-loopback address
>> - LOOPBACK: picks a loopback address
>>
>> My current take on this is if we did it for AS 6 we'd implement it in
>> the org.jboss.Main class.[1] Basically we'd alter the command line
>> processing for -b, -Djboss.bind.address and -Djgroups.bind_addr to
>> detect the above aliases and replace with the appropriate value.
>>
>> IMO we would *not* allow these values as a general configuration
>> option, e.g. in a -jboss-beans.xml:
>>
>> <!-- Not supported -->
>> <property name="bindAddress">PUBLIC</property>
>
> -100 IMO: a user may want to define an address based on some criteria,
> so the above makes perfect sense ! I can even envisage that we support
> something like this later:
>
> <property name="bindAddress">192.168.*,274.2.*,SITE_LOCAL</property>,
>
> which means that we should try to pick a site local address starting
> with 192.168, if not found a global IP address starting with 274.*, and
> if still not found, go and grab any site local address.
>
> All of this logic can be centralized (in JGroups it is in 1 place) and
> used everywhere.
>
If there is a single place where such configuration is allowed (e.g. an
AS 7 domain configuration document) and all services that need to
consume the value must get it from the domain model, fine. But that
ain't how AS 6 works. And this discussion started with a request to get
something in M4, so that's what I'm talking about. :)
In AS 6, this kind of logic cannot be centralized in a single place.
Just in clustering alone, the AS deals with 4 separate projects that
each have their own configuration parsers.
>
>> That would be too much work, since as soon as you allow it one
>> configuration document you should allow it everywhere.
>
> Yes, but again, if this is centralized, this should be simple. In
> JGroups, processing of all IP addresses (IpAddress, InetAddress, or
> lists thereof) is done in 1 place (via annotations).
>
>> The weakness of only using it via Main's command line processing is if
>> people only want to use, for example, PUBLIC, in one spot, not as a
>> global value like -b. If we want to help with that, perhaps we could
>> use a system property namespace, and have Main check for properties in
>> that namespace and resolve them. For example:
>>
>> -Djboss.bind.address.myfoosocket=PUBLIC
>>
>> My instinct though is to *not* support that. First, to me there is no
>> clear use case. Second, in AS 7 I'm pretty sure we are going to want
>> to move away from system properties as a core way of configuring the
>> AS, so let's not add new system property-based features in 6.
>
> IMO, GLOBAL, SITE_LOCAL, LOOPBACK etc are *IP addresses*, as good as the
> dotted decimal notation (192.168.1.5) ! They are simply resolved at boot
> time, versus statically.
>
> If we allow for these keywords to be used with -b, then it would be
> weird for users not to be able to use them in XML config files or as
> system properties !
>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
14 years, 2 months
Re: [jboss-dev] Public IP address used by JBoss AS
by Brian Stansberry
OK, this time I'll actually send it to the list...
On 05/26/2010 07:38 AM, Brian Stansberry wrote:
> Putting this on jboss-dev, as my guess is 3/4 of the work is discussing
> a bit. Particularly interested in hearing from Mr. Boot, ALR.
>
> What we're talking about is https://jira.jboss.org/browse/JBAS-8001
> which is a proposal to allow some standard aliases for IP addresses that
> the AS would resolve to something meaningful on the local machine. The
> purpose is to make it easier to use the AS in a cloud environment where
> the user can't know addresses in advance. Proposed aliases are:
>
> - GLOBAL: picks a global (public) address
> - SITE_LOCAL: an address starting with 192.168.x.x or 10.0.x.x
> - LINK_LOCAL: a link local address, ie. starting with 169.x.x.x or
> 254.x.x.x
> - NON_LOOPBACK: picks any non-loopback address
> - LOOPBACK: picks a loopback address
>
> My current take on this is if we did it for AS 6 we'd implement it in
> the org.jboss.Main class.[1] Basically we'd alter the command line
> processing for -b, -Djboss.bind.address and -Djgroups.bind_addr to
> detect the above aliases and replace with the appropriate value.
>
> IMO we would *not* allow these values as a general configuration option,
> e.g. in a -jboss-beans.xml:
>
> <!-- Not supported -->
> <property name="bindAddress">PUBLIC</property>
>
> That would be too much work, since as soon as you allow it one
> configuration document you should allow it everywhere.
>
> The weakness of only using it via Main's command line processing is if
> people only want to use, for example, PUBLIC, in one spot, not as a
> global value like -b. If we want to help with that, perhaps we could use
> a system property namespace, and have Main check for properties in that
> namespace and resolve them. For example:
>
> -Djboss.bind.address.myfoosocket=PUBLIC
>
> My instinct though is to *not* support that. First, to me there is no
> clear use case. Second, in AS 7 I'm pretty sure we are going to want to
> move away from system properties as a core way of configuring the AS, so
> let's not add new system property-based features in 6.
>
> Thoughts?
>
> [1]
> https://svn.jboss.org/repos/jbossas/trunk/main/src/main/java/org/jboss/Ma...
>
>
> On 05/26/2010 07:07 AM, Bela Ban wrote:
>> In my mod-cluster demo, every JBoss instance needs to set the IP address
>> used by its AJP connector to a *public* IP address, regardless what
>> jboss.bind.address is set to. The reason is that the httpd's mod-cluster
>> will connect back to the JBoss instance via AJP, and if httpd runs in a
>> different cloud, then a randomly chosen IP address may or may not work.
>> For example, it wouldn't work if JBoss picked a site-local (e.g.
>> 192.168.x.x.x) IP address...
>>
>> However, since I don't know the public IP addresses available on the
>> NICs provided by a virtualized instance in the cloud to a JBoss
>> instance, I would have to come up with complicated scripts which find
>> out the public IP address(es) and set -Djboss.bind.address to it.
>>
>> On top of that, I don't really need to set jboss.bind.address, I really
>> only want to set the IP address from the AJP connector (in server.xml).
>>
>> So I was wondering whether (when ! :-)) something like [1] will be
>> available in JBoss AS: I could then simply set
>> -Djboss.bind.address=PUBLIC and JBoss AS would pick any suitable public
>> IP address on any interface that's not down...
>>
>> I know there's a JIRA around for this somewhere, and I was wondering if
>> there's a chance to get this into M4, so I don't have to write crappy
>> scripts to set jboss.bind.address... :-)
>>
>>
>> [1] https://jira.jboss.org/browse/JGRP-1204
>>
>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
14 years, 2 months
RESTEasy 1.x deployment issue in AS trunk
by Galder Zamarreno
Hi,
Last week I was testing deploying a war file with RESTEasy on 1.2.1.GA in the war archive's WEB-INF/lib directory and I was getting a CCE like the one below.
12:39:58,448 ERROR [[/infinispan-server-rest]] Exception starting filter Resteasy: java.lang.ClassCastException: org.jboss.resteasy.spi.ResteasyProviderFactory cannot be cast to org.jboss.resteasy.spi.ResteasyProviderFactory
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:55) [:]
at org.jboss.resteasy.plugins.server.servlet.FilterDispatcher.init(FilterDispatcher.java:39) [:]
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:462) [:]
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3286) [:]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3887) [:]
AS ships with a different version of RESTEasy library which would explain this issue (latest AS ships 2.0-beta-2). However, AFAIR in the past WEB-INF/lib was deployed under a different classloader and hence this shouldn't be a problem, should it?
FilterDispatcher is a class that's only in REST 2.0, so somehow tomcat's ApplicationFilterConfig loads a 2.0 filter class (this is probably configured in some web.xml somewhere) but when this 2.0 class tries to load ResteasyProviderFactory, this is loaded from the war's lib directory (1.x).
providerFactory = (ResteasyProviderFactory) servletContext.getAttribute(ResteasyProviderFactory.class.getName());
So, the underlying issue might be related to a change in initialisation or deployment from RESTEasy 1.x to 2.x.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 2 months
Fwd: [infinispan-dev] Infinispan GUI demo not building after maven repo changes
by Galder Zamarreno
FAO jboss-dev list: Why wasn't apache-log4j/log4j group ported to new nexus repo? What are other projects depending on log4j 1.2.15 doing about this?
----- Forwarded Message -----
From: galder(a)redhat.com
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>, "JBoss.org development list" <jboss-development(a)lists.jboss.org>
Sent: Wednesday, May 19, 2010 7:05:50 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: [infinispan-dev] Infinispan GUI demo not building after maven repo changes
Hi,
FAO jboss-dev list: Why wasn't apache-log4j/log4j group ported to new nexus repo? What are other projects depending on log4j 1.2.15 doing about this?
If you wipe your maven2 repo, you'll find that GUI demo does not build and this is related to the maven repo changes. Basically, the GUI demo depends on log4j 1.2.15 but we're not using the default one. Instead we're depending on http://repository.jboss.org/maven2/apache-log4j/log4j/1.2.15/
Now, the reason for that I suspect is the fact that if you depend on the standard log4j 1.2.15, you get dependency failures like this:
Missing:
----------
1) com.sun.jdmk:jmxtools:jar:1.2.1
Try downloading the file manually from:
http://java.sun.com/products/JavaManagement/download.html
Then, install it using the command:
mvn install:install-file -DgroupId=com.sun.jdmk -DartifactId=jmxtools -Dversion=1.2.1 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=com.sun.jdmk -DartifactId=jmxtools -Dversion=1.2.1 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.infinispan:infinispan-gui-demo:jar:4.1.0-SNAPSHOT
2) log4j:log4j:jar:1.2.15
3) com.sun.jdmk:jmxtools:jar:1.2.1
2) com.sun.jmx:jmxri:jar:1.2.1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=com.sun.jmx -DartifactId=jmxri -Dversion=1.2.1 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=com.sun.jmx -DartifactId=jmxri -Dversion=1.2.1 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.infinispan:infinispan-gui-demo:jar:4.1.0-SNAPSHOT
2) log4j:log4j:jar:1.2.15
3) com.sun.jmx:jmxri:jar:1.2.1
----------
2 required artifacts are missing.
for artifact:
org.infinispan:infinispan-gui-demo:jar:4.1.0-SNAPSHOT
----------
As http://unitstep.net/blog/2009/05/18/resolving-log4j-1215-dependency-probl... explains, these appear to be optional dependencies that log4j should have set. Issues like this might explain why we ended up building and putting our own 1.2.15 version in the old repository.
The point is, what do we do about it? Any particular reason why the demo depends on version 1.2.15?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
14 years, 2 months
Another mvn release issue
by Ales Justin
While I'm "mvn release:prepare" I get another weird mvn issue.
It fails to find the artifact I just built;
* jboss-cl is made from classloader <-- classloading <-- classloading-vfs
[INFO] [INFO] Building JBoss ClassLoading VFS
[INFO] [INFO] task-segment: [clean, verify]
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] [clean:clean {execution: default-clean}]
[INFO] [INFO] Deleting file set: /Users/alesj/projects/branches/mc/classloading/Branch_2_0/classloading-vfs/target (included: [**], excluded: [])
[INFO] [INFO] [enforcer:enforce {execution: enforce-plugin-versions}]
[INFO] Downloading: https://repository.jboss.org/nexus/content/groups/developer/org/jboss/cl/...
[INFO] [INFO] Unable to find resource 'org.jboss.cl:jboss-cl:pom:2.0.9.GA' in repository jboss-releases (http://repository.jboss.org/maven2)
[INFO] Downloading: https://repository.jboss.org/nexus/content/groups/developer/org/jboss/cl/...
[INFO] [INFO] Unable to find resource 'org.jboss.cl:jboss-cl:pom:2.0.9.GA' in repository central (http://central)
[INFO] Downloading: https://repository.jboss.org/nexus/content/groups/developer/org/jboss/cl/...
[INFO] [INFO] Unable to find resource 'org.jboss.cl:jboss-cl:pom:2.0.9.GA' in repository repository.jboss.org (http://repository.jboss.org/maven2/)
[INFO] Downloading: https://repository.jboss.org/nexus/content/groups/developer/org/jboss/cl/...
[INFO] [INFO] Unable to find resource 'org.jboss.cl:jboss-cl:pom:2.0.9.GA' in repository apiviz.release (http://apiviz.googlecode.com/svn/site/repo/mvn/release)
[INFO] [WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequirePluginVersions failed with message:
[INFO] Unable to download the artifact from any repository
[INFO]
[INFO] org.jboss.cl:jboss-cl:pom:2.0.9.GA
[INFO]
[INFO] from the specified remote repositories:
[INFO] jboss-developer-repository-group (https://repository.jboss.org/nexus/content/groups/developer)
[INFO]
[INFO]
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [ERROR] BUILD ERROR
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Some Enforcer rules have failed. Look above for specific messages explaining why the rule failed.
>From "mvn dependency:tree"
Missing:
----------
1) org.jboss.cl:jboss-classloader:jar:2.0.9.GA
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.jboss.cl -DartifactId=jboss-classloader -Dversion=2.0.9.GA -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.jboss.cl -DartifactId=jboss-classloader -Dversion=2.0.9.GA -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.jboss.cl:jboss-classloading:jar:2.0.9.GA
2) org.jboss.cl:jboss-classloader:jar:2.0.9.GA
This used to work.
Any other-than-manual-release workaround or know fix?
-Ales
14 years, 2 months
